Most organizations today see data as being at the very core of their computing. Data provides an organization’s memory of customers, products, orders, employees, costs, revenue and profit. Data gives organizations the ability to service day-to-day needs and analyze their business. But in order to achieve these results, data must be properly organized, consistently managed and carefully vetted.

For the past several years, United Kingdom financial software vendor Avelo has been working to unify data, functionality and presentation across applications. At the nucleus of this effort is an enterprise model and integration architecture.

 

The integration opportunity

In the past, organizations regarded data management as a back-office overhead cost that should be minimized. That is not the situation today. Data is no longer a cost to be controlled, but a strategic initiative in which to invest. The important data isn’t locked within individual applications, it transcends applications and reaches throughout the enterprise.

“As business has gone global, teams are often virtual, with communication impeded by time zones, language and national and organizational culture,” explains Robert Hillard in his 2010 book, Information-Driven Business. “This means that information is the glue that holds the organization together.”

Hillard estimates that about half of a company’s value derives from its data. This means that a company with a market value of $10 billion has $5 billion in information and knowledge assets. The value of data depreciates 20 percent a year for a variety of reasons (such as data that is out of date or difficult to find), according to Hillard. For that reason, he recommends that organizations invest time and money to keep information current.

Weak data management can cause severe business problems. Conversely, there are significant opportunities for organizations that can get a tight grip on their data and integrate applications.

Software vendors have compelling business reasons for integrating applications. Applications in a problem domain often share concepts and behaviors; vendors can reduce cost by building code once and reusing it. There are also marketing cross-selling benefits, as customers of one vendor application are prospects for another. A suite of quality applications strengthens the vendor’s brand, which can lead to further sales and stronger pricing.

Customers can also benefit from integration. A clean product architecture can reduce vendor cost, leading to better pricing and greater vendor viability. Successful vendors are better positioned to respond to customer product suggestions and build quality software.

 

What is an enterprise data model?

A model is a representation of some aspect of a problem that helps you thoroughly understand that problem. A data model describes how data is stored and accessed, usually for a database. Developers must understand a problem before attempting a solution. Most database models are expressed as graphical diagrams and by their form appeal to human intuition.

An enterprise data model describes the essence of an entire organization or some major aspect of an organization. An enterprise model abstracts multiple applications, combining and reconciling their logical content. Enterprise modeling is an important topic, as conflicting data across applications is a problem for almost every organization. Stove-pipe applications have much less value than a coherent suite of applications that plug and play together. Enterprise modeling does not try to standardize every piece of data. Instead, the focus is on the most important concepts that are widely distributed and can serve as integration touch points.

Application data models are much different than enterprise data models. They differ in four key ways:

  1. Scope. An application model covers a single application. An enterprise model encompasses multiple applications, for all or part of an organization.
  2. Purpose. An application data model specifies data structure for building a database and the subsequent application. In contrast, the purpose of an enterprise model is mostly definitional and does not introduce any new data. An enterprise model provides a basis for reconciling applications and building them in a consistent manner.
  3. Abstraction. Most application models are straightforward and directly express business concepts. By its nature, an enterprise model is more abstract. With abstraction, an enterprise model can rise above the detail of individual applications and reconcile differences. An enterprise model focuses on unifying the deep, underlying concepts.
  4. Level of detail. An application model must be complete before an application can be built. An enterprise model, by definition, is not complete. Rather, an enterprise model provides an overarching approach for driving consistency across the major concepts of various applications. It is not practical to try to reconcile minor concepts – major concepts are difficult enough and are sufficient to obtain most of the business benefit. If an enterprise model includes too much detail, it will be subject to continual rework as constituent applications change.

Ideally, all new applications will incorporate the enterprise model as their starting point. There may be situations where a new application must deviate, but that is not desirable and may, in fact, reflect flaws in the enterprise model that should be fixed. If application developers feel they must deviate, they should first talk to enterprise architects. Enterprise architects can ensure such a deviation is justified, understand the reasons and have the opportunity to suggest alternatives.

Legacy applications and external applications will, of course, deviate from the enterprise model. As part of routine maintenance and in line with their own product roadmaps and strategy, legacy applications should gradually be brought into compliance. External applications should be interfaced to the enterprise model.