The Importance of Communication

Effective communication techniques for data management professionals

A presentation by Mike Nicewarner

Важная Информация

Управление данных - важный компонент здоровой организации IT

Администраторы базы данных очень интеллектуальны

Хороший модельер данных может упростить сложные деловые требования

Без хороших данных, будут терпеть неудачу все усилия по IT

Data management is an important component of a healthy IT organization

Database administrators are very intelligent

A good data modeler can simplify complex business requirements

Without good data, all IT efforts will fail

It is more than excellent presentation skills

It requires understanding, and change, so that the involved parties are impacted

So, for today, my goal is to effectively communicate with you

Important InformationEffective communication is more than just having good information

Introduction

Who am I? Who are you? Why are we here? What can we learn today?

Questions are the best wayto start a conversation

“How may I help you?”But not “Wha’d’ya want??”

Agenda

Data ManagementDefinitions, discussion

Various Roles and Responsibilities Bridging the Gap Discussion of topics, tools and techniques Conclusion

What is Data Management?

Encompasses data storage, manipulation, migration, security, etc

Data ModelingGathering / documenting data requirementsOrganizing & structuring data storage

Development project must consider data concerns at an early phase

Data requirements must be captured and communicated during and after the project

What is Data Modeling?

Time

Level o

f detail

Sco

pe

of

mo

del

Database Implementation

Conceptual Data Model

Logical Data Model

Physical Data Model

Business Requirements

What are Data Requirements

Conversational, narrative, business-oriented

Might start as a list of “things” Describe relationships between things Capture metadata within context of

business processAsk questions like “What is this?”,

“Where does it come from?”, “Who provides this?”

The Conceptual Data Model

HistoryPeter Chen’s Entity-Relationship

Diagram

Typical ERD

Customer Places Order

PlacesCustomer Order

The Conceptual Data Model

Can be “read”

Why use just boxes and lines?

PlacesCustomer Order

Places

Customer

The Conceptual Data Model

Value in simplicity Additional metadata “under the covers” Can show more or less detail Audience is Business and Architects

Customer CustomerCustomer IdentifierSalutationFirst NameMiddle NameLast NameName SuffixPhone Number

<pi>

<ai>

<ai>

IntegerCharacters (10)Characters (80)Characters (80)Characters (80)Characters (10)Characters (10)

<M>

<M>

<M>

<M>PrimaryName&Phone

<pi><ai>

CustomerCustomer IdentifierCustomer NamePhone Number

The Conceptual Data Model

ER is most common, but it has failingsCyclic relationshipsMust decide Entity or Attribute too early

Other methods out thereObject Role Modeling

Do not be religious about notations Use whatever works to communicate

With the Business!

Logical Data Model

Data structure starting to have structure Additional details

Foreign keys, surrogate keys, indexes, data types

IT standards and conventions Audience is IT

Architects, Business Analysts , Developers, etc.

Logical Data Model

Consider the other modeling notations Again, communication is critical

Yes, within ITShould I force everyone to learn my

language?Can I adapt my presentation to them?What would make the communication more

effective?Should know their “language”

Physical Data Model

Database-specific details Very technical DBA heavily involved

Typical hand-off situation (DA -> DBA)Naming conventionsPhysical options

Audience is DBA and Developer

PLACES

CUSTOMERCUST_IDSALUTATIONFIRST_NAMEMIDDLE_NAMELAST_NAMENAME_SUFFIXPHONE_NO

INTEGERCHAR(10)CHAR(80)CHAR(80)CHAR(80)CHAR(10)CHAR(10)

<pk>

<ak>

<ak>

<i1>

<i2>

<i2>

not nullnullnot nullnullnot nullnullnot null

PRIMARYNAME_PHONE

<pk><ak>

CUST_PKCUST_AK

<i1><i2>

ORDERORDER_IDCUST_IDORDER_DTORDER_TYPDELIVERY_CMT

INTEGERINTEGERDATECHAR(10)CHAR(1000)

<pk><fk>

<i1><i2>

not nullnot nullnullnullnull

PRIMARY <pk>

ORDER_PKCUST_ORDER_FK1

<i1><i2>

Physical Data Model

How many of us spend all our time in the physical model?

Is this the right “language” to use for everyone?

How about this one:Sure, we use data models to initially design

the database, but from that point the DBA handles all the maintenance.

YIKES!

Roles and Responsibilities

In ITProject ManagerBusiness AnalystRequirements AnalystArchitect – System, Data, InfrastructureDeveloper – Tech lead, CoderData AnalystDatabase Administrator

What is our collective goal?

Roles and Responsibilities

In BusinessExecutiveProject ChampionBusiness LiaisonSubject Matter ExpertData Steward / OwnerNot a “user” to be found

What “languages” do they “speak”?

Effective Communication

(All that to get to this, it had better be good)Unfortunately, this is pretty simple stuff,

but often overlooked First, our job in IT is to support the business

If we get caught up in being “gate keepers”, the business will jump the fence

Saying “NO” without something positive causes frustration

Focus on enabling, not on “disabling”

Effective Communication

Second, the business can get along just fine without usCan you say “outsource”? I knew you couldThey had a business process before they

came to usThey might be coming to IT because they

were told to, not because they wanted toBe a participant in solving their problemsAdd value to their business (easy, huh)

Effective Communication

Finally, educate yourselfBasic communication skills – presenting,

organizing, researching, etcKnow the business – not just the IT part;

get to know as much as you can (immersion)Know your job – data management trends,

data modeling techniques, corporate decisions, etc

Summary

Data ManagementThere are a number of styles and notationsEstablish corporate standardsPick appropriate style/formNeed tools that can “tie it all together”

Roles and ResponsibilitiesEnable, assist, support, add value

Communicate, don’t just talk

Discussion

What do you think?