|Sign-Up for Free Exclusive Services:||Portals|||||eNewsletters|||||Web Seminars|||||dataWarehouse.com|||||DM Review Magazine|
|Covering Business Intelligence, Integration & Analytics||Advanced Search|
Beyond the Data Warehouse:
Many thanks to Michael Patterson of Chicago Public Schools Technology Services for his assistance with this article.
One obstacle with getting the business side of the equation to embrace information management is to convince them how important models are. Semantics and standards usually do not require much convincing these days. Recently, I was meeting with a client and this topic surfaced. (Well, we were in a pub actually, but the topic did surface)
We both agreed that models are, of course, necessary. Strangely, we both agreed that models are also suffering from overexposure. Too many business users go into "deer in the head lights" mode in model walk-though sessions. In fact, we both agreed, and I am happy to debate anyone on this, that a model walk-through has minimal value. Reviewing the business rules and keys definitions are useful, but the model itself rarely needs to be printed for the meeting; Models are a tool. In fact, I now believe models should not be primarily derived from meetings with business users but via other types of analysis. (Documents, standard industry models a la Len Silverston, etc.) Therefore, the model becomes a true tool for engineering the solution versus an end deliverable. When my own firm does assessments, for example, we always get nervous when we hear the big goal for a data management group for next year is to "deliver an enterprise data model." This is a sure sign of minimal business interest of engagement. And it follows that we are often asked to explain what the are models and why are we spending time on them to the business areas.
We also observed is that there is not one model. The same results can be derived with models done differently, appearing differently and being put together differently. The model itself is a path to understanding. My client and I struggled for the metaphor or analogy that we could use to present this concept to businesspeople. Since I was one pint up on my client, he came up with the answer. Poetry.
Poetry comes in many forms. Remember how we studied couplets and iambic pentameter in school? The key to poetry (to me anyway) is that beautiful elegant things can be said in many different forms. Here as some examples of poems speaking to data related topics.
There once was a modeler from Midwest
Who put technique ahead of the business
And took tools too seriously
Was terminated quite abruptly
With echoes in his head of "substance before finesse"
the nature of the standard is irrelevant
if governance is like eating the elephant
so focus on the model incremental
and standards evolve from local to governmental
I guess at this point it should be noted that these all say similar things about modeling, albeit differently. That is, modeling it is important, needs to be done but can have different styles. However, models are also used for projects and can describe what is correct, current state or future state. They are versatile tools. Means, and not the ends. Again, some poetry to make a point (or two).
Rarely seen by modelers
While designing rules
There once was a manager of data
Whose new warehouse never left beta
The money ran out
And so did his clout
And the users were left with raw data
Finance and sales had a need for good data
Modelers promised the ability
To slice and dice, patiently they waited
Paid invoice after invoice eagerly
The new architecture was cutting edge
A warehouse of enterprise proportion
The design split IT, halved with a wedge
The requirements filled with distortion
From data quality to conversion
New hardware, software, and middleware too
Less of a process, and more excursion
Release after release, still no value
Though stars and snowflakes, marts and cubes were built
Still less a warehouse, more a patchwork quilt
OK, we had some fun with this article. The model, to be effective must flow smoothly and evenly like the stanzas of a poem. It must obey certain principles of structure. While there are several types of models or architectures (service-oriented, object-oriented, traditional ER) they all have a place and work well when used appropriately. Businesses are diverse with many needs, complex rules and processes. It is often a proper combination of several models that make a business work. It is important when using models as a tool to ensure that you are using the right tool for the job.
Graeme Simsion in a January 2005 TDAN article compares the modern day architect to more of an urban planner than an architect starting from scratch. This is why modern companies often integrate multiple architectures to provide business value.
However, let's not overlook the main point. There is a lot of erroneous emphasis on modeling. From the IT side, there are too many "project models" done - and we fail to leverage the wonderful benefits of building an enterprise model, albeit bottom up. Face it; lots of so-called data architectures departments just do project models. There is nothing wrong with developing an enterprise view of data without a project to support it. Just do it. Do it with the same "tongue-in-cheek" approach. Do it on lunch hours, during informal brown bag sessions. It is YOUR TOOL as the data modeler or architect. YOU DON'T NEED PERMISSION.
Conversely, the business side of data management should view models as a value added tool versus a money and time-grabbing deliverable or end product. While the model does not have to be the end deliverable, the data project team has to use them, and the model is a perfect tool to resolve enterprise data issues. When approaching the business sponsor, please present the models as tools, not end products. Present the results of modeling, not the models themselves. To reiterate, the customer appreciates a job well done, not the tools you used to do it.
Michael Patterson is a director for Chicago Public Schools (CPS) Office of Technology Services responsible for enterprise architecture and information management. CPS is the third largest school district in the nation, serving over 430,000 students in 637 schools. Patterson also serves as a technical board member for the Schools Interoperability Framework Association (SIFA) , an organization committed to development of standards for educational technology. Previously he served in architecture and information management roles for both the airline and logistics industries. He can be reached at email@example.com.
The contents of this article are Copyright 2005 by DM Review and Navigant Consulting. Any use, quotation, repurpose, duplication or replication of the diagrams, concepts or content without permission of DM Review, Navigant or the author is prohibited.
When John is not writing poetry as a hobby, he is a director for Navigant Consulting, which recently acquired KI Solutions, a management consulting firm specializing in knowledge and information asset management and strategic business intelligence planning and delivery. Ladley is an internationally recognized speaker and, more importantly, hands-on practitioner, of information and knowledge management solutions. He can be reached at firstname.lastname@example.org. Comments, ideas, questions and corroborating or contradictory examples are welcomed.
|E-Mail This Column|