Data Integration Blog -

In my last posting I discussed the data centric and process centric view of IT. Let’s now take this a little further and put these two views of the IT world on an equal footing. If we do that, then just as there is a Service Oriented Architecture (SOA), there also needs to be an Information Oriented Architecture (IOA). So what would that be?

Proceeding By Analogy

There will be similarities between an IOA and SOA. The goal of a SOA is to provide an architecture that makes it possible to integrate all the IT processes we use. The goal of an IOA is fairly similar – to provide an archi
tecture that enables the integration of a wide variety of data stores and data sources so that a global data service can be provided.

So let’s take a look at the following diagram which deliberately juxtaposes an IOA and SOA:

So for the sake of simplicity, let’s think of all the applications an organization uses, including any applications housed externally, as being simple siloed applications. A SOA enables their integration so that one application can use a Service (some program logic) provided by other applications. Thus whole new applications can be written by writing some new code and bolting in some older code.

The IOA

So imagine something similar for the data side, an IOA, which allows a user to integrate together data taken from many applications for the sake of analysis. Then we might have the following components:

Data Governance: This would be a component that imposed rules of usage on data. In a SOA, SOA Governance is about imposing corporate governance upon all corporate systems. So it means enabling only those who have the correct security level to have access to specific functionality. It means ensuring quality of service. It usually means coherent change management and the imposition of agreed standards. There needs to be something comparable in an IOA. This too would store governance rules which it either imposed or delegated to other software components which managed their implementation.

One specific area of activity associated with IOA governance would be data quality, which is a much larger issue for information oriented applications than it is within SOA. In any attempt at data governance, there really should be practical rules of data quality imposed upon the use of data. One could say that data quality software would be a component of data governance in an IOA.

MDM: If we are going to provide a data service, there needs to be a “registry” of the data available via the service. In SOA, the equivalent is the SOA Registry, which holds a catalog of all SOA services that are available. MDM software could be said to provide this capability, although depending on which MDM products you look at, it can be broader in scope than a SOA Registry, as it may carry out (or delegate) many processes such as; data quality, collection, matching and even data distribution. Nevertheless, it is MDM that has the full map of the organization’s information and hence it is also an Information Registry.

Data Hubs: The MDM software can and should define a single logical data hub. But for performance reasons there could be one or more physical data hubs which serve up data to users that request it, and serve it up on a scheduled basis to programs that need it. We can think of this aspect of an IOA as in some ways as similar to the work flow components that are often part of a SOA, which serve up data to users at specific times for well-defined purposes.

Service Manager: The service brokering and service management aspects of SOA are primarily there to ensure adequate performance. Within the data architectures that currently exist in commercial organizations there is nothing that corresponds to this function. However, with the advent of data streaming and the move, closer and closer, to real-time BI, there is clearly an emerging need for performance to be managed globally by a service management component.

ESB: The use of ESBs were never mandatory within a SOA, but the simple fact was that the message and data traffic were often such that it made sense to have one or more physical components managing the traffic. There’s no reason to believe that the same issue would not arise within an IOA and be solved in a similar manner.

Other components: Aside from what I have described here, all the tools that are normally thought of and referred to as BI tools would be components of an IOA. This means data warehouses (and associated software), data marts, OLAP tools, reporting tools, dashboards, analysis and data mining tools, CEP tools and so on. It is, indeed, the users of these tools that the IOA serves.

Finally, we have the simple fact that it wouldn’t make any sense for a SOA and an IOA to be completely independent of each other. Practically this means having standards that span both architectures. It also means all data services that the IOA delivers being listed in that SOA Registry and all the SOA services that can deliver information being defined as data sources (or alternative data sources) within the MDM.