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
Top Related