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 Information Effective 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 way to start a conversation “How may I help you?” But not “Wha’d’ya want??”

Agenda Data Management Definitions, 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 Modeling Gathering / documenting data requirements Organizing & 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 of detail Scope of model 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 process Ask questions like “What is this?”, “Where does it come from?”, “Who provides this?”

The Conceptual Data Model History Peter Chen’s Entity-Relationship Diagram Typical ERD

The Conceptual Data Model Can be “read” Why use just boxes and lines?

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

The Conceptual Data Model ER is most common, but it has failings Cyclic relationships Must decide Entity or Attribute too early Other methods out there Object 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 IT Should 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 conventions Physical options Audience is DBA and Developer

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 IT Project Manager Business Analyst Requirements Analyst Architect – System, Data, Infrastructure Developer – Tech lead, Coder Data Analyst Database Administrator What is our collective goal?

Roles and Responsibilities In Business Executive Project Champion Business Liaison Subject Matter Expert Data Steward / Owner Not 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 us Can you say “outsource”? I knew you could They had a business process before they came to us They might be coming to IT because they were told to, not because they wanted to Be a participant in solving their problems Add value to their business (easy, huh)

Effective Communication Finally, educate yourself Basic communication skills – presenting, organizing, researching, etc Know 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 Management There are a number of styles and notations Establish corporate standards Pick appropriate style/form Need tools that can “tie it all together” Roles and Responsibilities Enable, assist, support, add value Communicate, don’t just talk

Discussion What do you think?