News

Perspective on XML: Enterprise data goes high-fashion

• By Uche Ogbuji
• September 1, 2004

Data modeling is fashionable. It used to be that all the effort that went into rationalizing software development was focused on code and routines. Of course, database developers worked on low-level DBMS models, but these never became prominent as a general way of looking at the data a business managed. This is because systems architecture and programming have always been in the spotlight more than database management.

Trends in UML and the success of XML signal an increasing respect for data models. But with appreciation sometimes comes gigantism. If data models are good, then isn't bigger better?

There is temptation to develop what I call the supermodel: a single data model that aims to capture all the data managed in an organization. Some consultants who work on moving organizations toward UML end up pushing for supermodels. Certainly, the idea of the OMG's Common Warehouse Model implies a supermodel. In my consulting on XML adoption, I have been tempted to recommend supermodels, and I sometimes have found my clients looking for XML-driven supermodels.

The problem with supermodels is that they share characteristics with supermodels in fashion: they are glamorous and in demand, but they can also be mercurial and expensive to maintain.

With demand comes the desire for close executive control, in the same way it did for ERP. Vendors sold these systems in the recent boom by showing CEOs cockpit views of integrated data feeds from finance in New York to warehouses in Shanghai to call centers in Dublin. The lure of executive decision support was too enticing to resist, despite the many tales from colleagues who sustained enormous losses in ERP adoption because of the costs of business process reengineering and the risks of large-scale software development and deployment.

XML initiatives also look to encode all aspects of organizational information. These include Universal Business Language (UBL), electronic business XML (ebXML) and the Open Applications Group Interoperability Standard (OAGIS).

The main goal of these initiatives is to provide formats for commerce between businesses (as successors to EDI), but this inevitably involves the development of comprehensive models of enterprise information. ebXML and UBL are closely allied and there are moves toward coordination with OAGIS. There is a lot of buzz about binding the worlds of XML business exchange, Web services and data warehousing. At first glance, consolidation is a great idea, but everyone shakes his or her head at how daunting a task it would be.

Within an enterprise there are two approaches to building a supermodel: the top-down approach and the bottom-up approach. In the top-down approach, BPR consultants chase down and lasso data from the far corners of the organization and beat it into a cohesive model.

In the bottom-up approach, groups within the organization work together to align the data they control into a unified model, while setting up bridge business rules where there is no practical consensus on aspects of the data.

The top-down approach costs more, but is usually quicker and has a high profile. The bottom-up approach is scrappier and can be achieved on a shoestring budget, but it requires a strong leader typically working in the lower ranks. Because it's low-key, it can miss important angles on the data and can run into political obstructions.

Having seen projects develop supermodels in both ways, I think the bottom-up approach is superior. It has lower risk and causes less bruising to business operations. Regardless of how they are built, I have seen problems refitting the burnished data models into the gray cubicles of everyday business operations.

Departments are still left with their specialized needs, which remain even after the data they rely on has been shaped into enterprise-wide conformity. New exceptions come up every day. Big data models do not easily adapt to inevitable change, and errors and omissions can magnify problems across organizations.

Consider whether supermodels are worth the effort and cost. A proliferation of small models customized to each application or departmental database may seem chaotic at first, but this needn't be the case. The trick is to ensure that each model is thoroughly documented and maintenance plans provide for cross-functional meetings between groups.

The key to success with multiple, small data models is to trust departmental staff to take interoperability seriously, and to trust in knowledge sharing so inevitable personnel changes cause minimal disruption.

Supermodels represent more of a translation of responsibility from individualized concerns into centralized machines that executives can keep an eye on. Trusting people can be risky, but trusting mechanisms can be even more so. In the end, whether supermodels work better than smaller, specialized models depends on the characteristics of the organization.

The most important initiative any organization can take in improving its information systems is to pay attention to data models in the first place. Luckily, this is becoming common wisdom. The question then becomes: What scale works best for data modeling?

Supermodels may look good in magazines, but can you live with them day in and day out? Thinking clearly and analytically about this question, rather than succumbing to fashion, can be the key to building a healthy relationship between business interest and the data that nourishes it.