Two Tips for a Data Centric Architecture

data tips
Two Tips for a Data Centric Architecture

For decades the IT industry has been pursuing an application centric architecture while leading organizations are pursuing a data centric approach. This post offers two insider tips for making the switch.

Historically, applications were the primary structural element that formed the system-of-systems to serve the enterprise. The approach served us well in the 80’s when silo business operations had little need for integration and we made it work through the 90’s with the advent of middleware to glue all the system together. But as applications swelled to gargantuan size (see my blog about The ERP Data Trap) and the complexity of business operations grew exponentially, major cracks have been appearing the strategy. The problem is that we’re focusing on the wrong structural element. In the end, it is the data in the application which delivers the business value – not the application itself. Anyone can buy SAP – but no-one else has data about what your customers purchased from you, the results of your internal product quality tests, or financial data about your performance. It’s the data, and not the applications, that provide competitive advantage.

How can you make the switch to a data-centric architecture? It’s a challenging task since applications are easy to put your arms around while data is a more intangible asset. The first tip is to start is with an Information Model for the enterprise. Note that I didn’t call it a “data model” which is about data entities, relationships, cardinality, and other characteristics necessary for effective computer processing. The Information Model is different in that it reflects not how data is processed, but how business functions create and use it in the context of day-to-day operations. This is key to Connecting Architecture to Business Strategy.

To develop an Information Model, start by decomposing the enterprise into a set of functions that describe what the organization does. Next, model the interaction of the functions (including external interactions with customers, suppliers and stakeholders) to show the service flows or “who is serving who”. Add to that the information subjects that are created by each function (and for architectural correctness, each information subject must be unique since if two functions are creating the same information then they really aren’t different) and which functions use the information (many functions may use the information).

The collection of information subjects, grouped into functional domains, is your enterprise Information Model. It describes how information is created, for what purpose, and who uses it. With this model you can now assign organizational responsibility for the subject areas and drive requirements for systems and technology to support it. As I said in one of my prior articles, If you Want Business to “Own” the Data, You Need to Build An Architecture For the Business.

.The second tip is to ensure that you have a data model for all application data-bases.  This is harder than it sounds since many application vendors don’t want to share their data model because it is intellectual property that they want to keep secret. If you never want to take the data out of the application it wouldn’t be a problem, but if you want to truly maximize the value of your data you need to get it out of the system and combine it with other data for strategic analysis or share it with other operational functions in order to optimize the end-to-end value stream. So if your policy is to “buy rather than build” application systems, you must insist that the software vendor make the data model available – or just don’t buy system.

Both of these techniques are not trivial, but if you truly see value in data as an asset, you need to make the switch. To get started, check out this whitepaper.

Comments