Intelligent Enterprise

I had the pleasure the other day of listing to a Webinar from Embarcadero that featured the Global Data Architect for a very large, global energy company, and I feel compelled to share three points that struck me as particularly sapient.

Enterprise data modeling is a formidable task, as those who have attempted or witnessed it will vouch. Difficulties begin right from the outset: what, exactly, do we mean by Enterprise Data Model (and Modeling)? Is it one large model, or a set of models? If the latter, are these models required to conform/share (entities, standards etc.)? Is it another name for the canonical data model? Who is responsible for building the model(s) — is it one person, one central team, or diverse project teams all contributing to it? Where do we start? How do we start? How do we maintain momentum?

In this context, the three very sound suggestions presented (shown in italics) were as follows:

• Choose what to model: Modeling the enterprise (in terms of data) is easier said than done. Any mid-sized business will have dozens if not hundreds of data models, representing legacy environments, custom development, off-the-shelf software, enterprise software implementations, external data interaction, etc. Large companies could easily have thousands of data models, each containing from a few dozen to a few thousand entities. The wise data architect will be very selective about which model(s) to pick for a start. An excellent suggestion made in the presentation: Focus on strategic and essential ("core") data that runs your business. It's the standard "Essential – Desirable – Optional" classification applied to data models. For example, choosing between a legacy customer information system and an employee perquisites management system? Easy – choose the former.

• Look for the "golden opportunities," such as new projects, where data modeling can contribute positively. Chances are you will not be given the resources you need to build out the enterprise data model (if you could convince management of the need for the data model in the first place). Fortunately, there are opportunities galore in new projects that come up, whether OLTP or DSS; a normalized data model is an essential component of both types of projects (yes, even for data warehousing… but that's probably a topic for another discussion). Besides, business intelligence initiatives offer a chance to trace origins and transformations of data, prepare and decide on clear definitions, and improve data quality. Stay alert for opportunities to "piggy back" on other projects. There is usually enough leeway in the project plan up front to insert activities related to creating the enterprise data model, and resources can be made available (or you can apportion your resources to the project).

• Maintain the model post-deployment. Again, easier said than done. Data models, once deployed, are often at risk of being completely neglected — subsequent changes to the data model are applied directly to the database. This is a terrible practice and, unfortunately, equally widespread. Application change control procedures should necessarily route all database changes through the data model — no changes should go through to the database unless they are first applied to the data model.

There were many other nuggets of insight presented, and credit is due to Embarcadero (and Greg Keller, chief evangelist for Embarcader, who led the session) for producing a Webinar where, to my surprise and delight, the focus was on vendor-independent insight rather than on a sales pitch.

E-MAIL  |