BeyeNETWORK - The Global Vision for BI and Beyond

Products and Architecture

Published: November 13, 2008

An architecture for information for a company is hard to define because it has so many facets. Bill Inmon describes some of the elements an architecture would surely include.

The other day, I was in a meeting with my good friend David Marco at a client site. The client brought up the issue of architecture. The discussion then went on to address what was an architecture? One of the clients added his two cents' worth by stating, “Our architecture is Microsoft.”

Immediately, everyone in the room began to debate whether or not a product was an architecture. The point was made that a product – any product – is not an architecture.

So the questions are:

• What constitutes an architecture?
  
  
• Is a product ever an architecture?

An architecture for information for a company is hard to define because it has so many facets. However, some of the elements of an architecture surely include:

An architectural blueprint of where the organization is now and where the organization is heading. The blueprint – often containing a data model – provides an abstraction of data. Many times, the information systems of a corporation contain many applications and many stores of data. All too often, there is great overlap between these applications and stores of data. There needs to be an abstraction that recognizes this overlap.

An architecture contains different levels of data (e.g., data, metadata, enterprise metadata). There needs to be an understanding of data at many different levels within an architecture.

Processes belong in an architecture. There are all sorts of processes, from the simple capture of information to the interactive processing of that information to the transformation of the information from an application case to an enterprise case.

Technology is an integral part of an architecture. Ultimately, an architecture must go from plan to implementation. Otherwise, the application is just pie in the sky. And there are many facets of technology that belong in an architecture. There is the raw form of storage and its costs and capabilities. There are processors, communications devices, operating systems, archival processes and ETL technology – and this short list just scratches the surface.
 
There is the implementation plan. In general, architectures are too large to be implemented all at once. So, there needs to be a rational plan for the implementation of the architecture. The implementation plan needs to include what part of the system is in place now, how that part of the system will be transitioned, what new parts will be added, the order in which new parts will be added, the benchmarks for knowing when an architectural component is complete, and so forth.

End user requirements are essential as well. No information technology exists in a self-contained vacuum. An important part of any architecture is a statement of why the architecture exists and what purpose is served. Some requirements are notional and some requirements are complete. (It is the nature of requirements that some requirements can be known before anything is built, and other requirements are not known until the user has had the opportunity for discovery and exploration. Both types of requirements belong in an architecture.)

Financing is an often forgotten aspect of an architecture, but it is important. Stated differently, an architecture cannot exist until it is established who is paying for the architecture, how much they are paying, when they are paying for it, and why they are paying for it. The expectations for the architecture are ultimately expressed by the financing for the architecture.

A statement of who the end users are. Usually, there are many different classes of end users from different countries, occupations, disciplines, etc.

Parametric measurements are an essential part of an architecture. In some cases, these measurements are made formally and regularly. In other cases, these measurements are made informally and irregularly. One form of these types of measurements are called service-level agreements. Service level agreements are important as a statement of expectations.

An interesting issue associated with architecture is how the architecture should be expressed. In some cases, the architecture is expressed very formally. For example, data models are usually expressed in a very formal way. Other aspects of the architecture are expressed informally. Usually, the sponsorship of the architecture is expressed informally.

Getting back to the question of whether or not a product can ever be an architecture, around the room, it was agreed that an architecture is not a product. But it is worthwhile to note that the mention of a product may spur notions as to what else needs to be in the architecture but may not have been addressed. For example, someone may bring up Ascential as an architecture. Ascential is no architecture, but the mere mention of Ascential brings up the point that ETL is indeed part of the architecture. Or, someone mentions Microsoft’s Excel. Excel is not an architecture, but the mention of its name spurs on conversations about business intelligence, which indeed is a part of an architecture.

If you found this article helpful and would like to receive the latest insights each week from the experts featured on the BeyeNETWORK, please subscribe to the Bill Inmon Newsletter.