Practical Data Architecture

Random thoughts on data modeling and database design, by Bruce Worobec

A Guide for Participants of Facilitated Sessions

Posted by Bruce Worobec on August 12, 2008

 

What follows is a document I have been using since the early 1990’s.  The terminology may need some updating, but for the most part the core techniques have proven themselves timeless.

 

WHAT IS A FACILITATED SESSION?

 

In many ways a facilitated session is simply a meeting.  It involves a group of people brought together to accomplish a specific agenda.  However, unlike a typical meeting, a facilitated session utilizes an individual trained in techniques for conducting such sessions in order to insure completion of the agenda.  Also, a facilitated session is longer than most meetings, often with a duration of several days.

 

Facilitated sessions can be used for many purposes, from strategic planning to building consensus among a group in conflict.  When used for data modeling, the approach followed during the session is based on the Information Engineering approach to systems development.  In this approach, systems are developed based on several models.  Of all the models, the two of interest at the beginning of a project are the Business Function Model and the Conceptual Data Model.

 

The reason these two models are important is that the Business Function Model serves as the basis for application functional design while the Conceptual Data Model serves as the basis for database design.  Also, through the building of these models, the project will have the potential to gain efficiency by identifying data and processes that have crept into systems over time but are unrelated to true business functions. 

 

The first model to be produced during the facilitated session will be the Business Function Model.  This model will capture “what” your business does in plain English, but will ignore “how” things are done.  The distinction between what and how will be a theme repeated throughout the session.  By focusing on what the business needs to do, the group will not be limited by any individual’s perception of how thing work today or how things ought to work in the future.

 

Once the Business Function Model is mostly complete, the focus will turn towards producing the Conceptual Data Model.  The technique used is to ask the following question for each of the lowest level functions in the Business Function Model:  “What data is needed to perform this function?”   The results are captured in an Entity-Relationship (E-R) diagram.  The E-R diagram, along with text descriptions for the entities, attributes, and relationships, then forms the completed Conceptual Data Model.

 

Because the data questions will usually uncover some changes or additions to the Business Function Model, considerable time can be spent refining both the models simultaneously.  Once complete, the two models can then be used as tools to address scope issues, examine technical alternatives, and to assure common understanding between Business Experts and Technical Experts from the beginning of a project.  The models also provide a solid foundation for physical data design.

 

PARTICIPANT ROLES

 

In order for a facilitated session to be successful, the participants all must understand and adhere to their respective roles in the process.  The roles of Business Expert, Technical Expert, and Facilitator are defined as follows:

 

Business Expert:  The Business Expert participants are the experts for the part of the business under analysis.  They must have the knowledge and authority to define what the business needs to do in order to operate efficiently.  Their responses during the session will impact database and process design.  If questions are raised that cannot be answered with the expertise in the room, a Business Expert will be assigned responsibility for researching the issue within their organization.  Most importantly, a Business Expert must not withhold information because they assume the resulting technical implementation would not be feasible.

 

Technical Expert:  The Technical Expert participants are mainly observers during the modeling process.  They should only offer clarifying comments, not proposed solutions.  Even if the information gathered points towards an implementation that is not technically feasible, the Technical Experts must hold their comments.  Once the models are complete, the Technical Experts can then address scope and feasibility issues and explore technical alternatives in conjunction with the Business Experts.

 

Facilitator:  The Facilitator is the leader of the session and is ultimately responsible for delivering what the session set out to accomplish.  Unlike a neutral “Consensus” facilitator, the Facilitator role is biased towards modeling objectives.  The Facilitator will influence the format, but not the content, of the deliverables so that the data modeling objectives can be met and the subsequent physical data designs can be optimized.

 

GUIDELINES FOR BUSINESS FUNCTION MODELING

 

The business function modeling part of the session will be conducted using a set of guidelines designed to keep the session focused on delivering a quality Business Function Model.  The guidelines that follow will be explained in more detail at the beginning of the session:

 

     Functions define WHAT, not HOW

     Functions start with a precise verb

     Functions are defined in plain English–no jargon

     Functions deliver something

     Order of functions is not important

     Functions may be optional

     Functions usually break into 4-8 sub-functions

     Sub-functions must completely define the parent function


GUIDELINES FOR DATA MODELING

 

The Data Modeling part of the session will be conducted using a set of guidelines designed to insure delivery of a quality Data Model.  Depending on the experience of the group, a brief training session on data modeling will be included.  Also, some new terminology will be introduced which is briefly defined below:

 

Entity:

Something the business has the will and means to keep information about

Attribute:

A single piece of information about an entity

Relationship:

An association of two entities for a business purpose

 

Some of the guidelines that will be further explained at the beginning of the logical data modeling are as follows:

 

     Entities must have a unique identifier

     All entities, attributes, and relationships should be fully documented

     The model should only contain data needed to support the business functions

     The underlying relational model should be in third normal form

 

FACILITIES

 

Because of the duration and intensity of the sessions, comfortable surroundings are essential for success.  Also, the session will require the complete and undivided attention of all participants.  In order to accomplish this, a location away from the normal workplace is preferred.  The ideal session location would contain the following:

 

     Lots of whiteboard space

     Easels with lots of paper, marking pens, and masking tape

     A laptop computer with word processing software

     Toys and frequent snacks

     People in casual clothing

 

FINAL CAVEATS

 

Depending upon which consultants, methodologies, and tools you have been exposed to, the definitions and notations used in the session may vary from what you have seen in the past.  Experience has shown that the choice of definitions or notations has had little impact on the quality of the session.  If in doubt, please ask for clarification so that all participants can all be working from the same definitions.  Also, be prepared for times when things are going well, and other times when things fall flat.  It will be critical that everyone police themselves with regard to placing one’s own needs and biases on hold for the good of the session.  Most of all, in some sort of bizarre way, you will need to view the session as fun.

Leave a Reply

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <pre> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>