Long-term success, not methodological orthodoxy, is the measure of analytic methods' fitness
|
Nearly 25 years have passed since Peter Chen introduced the entity-relationship diagram. Yet, many data management organizations still struggle for acceptance as a valued partner of any project team. There was a time when the word “enterprise” was always followed with “model” instead of “resource planning” or “application integration.”
But how can you achieve enterprise application integration without an enterprise model? In the meantime, the proponents of object-oriented and dimensional modeling approaches declare that they don’t need no stinkin’ data models!
After all this time, why does it seem that as many organizations are still trying to come to grips with managing their information resources as there are success stories?
Data analysts have often been at odds with their counterparts in process analysis. In the past, business analysts would exclude data analysts from analysis sessions, under the guise of protecting their subject matter experts (SMEs) from interactions with too many people from IT. So, we were provided with data flow diagrams as the starting point for developing the data models.
Not much has changed. Now, we get object models, use cases, state transition diagrams, or one of the many other diagrams supported by unified modeling language (UML) with the caveat that there is no need for data modelers to participate in the analysis sessions. The object modelers say that they will take care of interpreting the SMEs’ data needs into the appropriate object classes. We just have to get the object model into a format that a relational database can support. Amazingly, I’ve encountered similar resistance from data warehouse mod- elers in including data modelers in their projects.
The result is often friction on the team. Object modelers complain that the data modelers are trying to normalize their object classes. Data modelers raise concerns about the quality of the object modelers’ object class and attribute specifications that are not precise enough to meet any data analyst’s standard.
Although the models closely reflect the language of the business, the object modelers don’t always probe for hidden meanings behind that language. Consequently, data analysts have fuzzy object class models thrust upon them with little opportunity to work with the SMEs to validate and enhance the model and its data specifications.
If we question why an object class has a specific configuration, the answer is often “I know how to code this object class this way” or “that’s how the data comes from the source application.” It is often dismaying to see classes and attributes in the business-object class model that are really wrappers for legacy data, with no analysis conducted to determine whether the existing data designs still met the needs of the future enterprise.
So why has this schism evolved between data and process analysts? Because we are working to different agendas.
The problem is not with the methodology people use, but in the different objectives of the players involved. Ultimately, object analysts must provide models that an object-oriented programming language supports. A data mart architect needs a database design that is easy for its users to use while still delivering the necessary performance. These analysts are narrowly focused on the specific problem space as presented by their SMEs. As the project data analysts, we want to fulfill this same objective, but we also want the application to use data designed for sharing across the enterprise.
Data analysts bring several things to the table that I’ve yet to encounter in object and dimensional modelers: precision of thought, ability to probe beyond the SMEs’ words to find the hidden meaning lurking behind and an enterprise perspective. We are all too aware that every project with data designed from an understanding of the SMEs’ words alone will probably become another stovepipe application, another source of disparate data, another legacy application.
So what must we do to be welcomed to the project team during the business analysis phase, rather than avoided? I plan to become more flexible. I understand the role each type of model has in managing data and how those models can meld together. I embrace UML as the closest thing available to a modeling standard. I’m willing to use whatever notation is necessary to effectively communicate with my project team members, as well as with the SMEs.
I believe it takes no longer to implement an application using well-formed data than without. The trick is getting the enterprise perspective into the analysis process early enough. If we can step in to support business analysis using any methodology the project team chooses, then I’m willing to be an object or a dimensional modeler.
So, for me, data models are dead! Long live data modelers!
Data management from an enterprise perspective has always been a challenge. We’ve always struggled for acceptance from our business management, right down to the application development team. I’d like to hear your stories. Tell me if you have been successful in developing an enterprise model that is recognized as such across your organization and whether applications have been built to that model. What was the key in making enterprisewide data sharing a reality? What have you learned from any of the less successful efforts? Email your stories to me so I can compile them into an article of first-hand experiences that we can share with one another.
Terry Moriarty (terry@inastrol.com), president of Inastrol, a San Francisco-based information management consultancy, specializes in customer relationship information and metadata management.
|
|
|
|