This is a continuation of the post “Prepare for the unknown I”.

Architectural debt

Architectural debt is the price you pay today for all your previous shortcuts you took when you expanded your portfolio of business applications. You “pay interest” in form of slow and cumbersome change processes. You allowed applications to own its data. You allowed the data model for every application you bought off the shelf to diverge from your business information model – or maybe you just did not check? So now you have architectural debt in form of redundant applications, redundant data and a spaghetti of integrations. Consequences are bad data quality, unnecessary high cost and risk, and most of all: business change is inhibited. You have positioned yourself badly for the future.

You need a clean-up

If you only aim for goals and strategies, you will just add more architectural debt. What you need is a real clean-up. This is similar to dealing with a technical debt. The difference is that you must approach the problem with architecture – not just application design and programming. Many firms understand they need a clean-up. But they end up with continuous cleanup of data and information, that never finishes. That is because they do not evaluate and redesign their architecture, and the growing need for cleanup does not go away.

Attack the root cause

The root cause is the tight coupling between data and application. And the solution is the other side of the coin: a lose coupling between data and application. This will of course affect your application architecture. In a target architecture you will be able to build small applications that reuse existing data. Data will be acquired only once – from the source. And there will be only one set of implemented business rules governing data and securing data integrity.

The rate of change

Products, business processes, and business applications need to change according to change in the business environment. Data definitions and data structures, represented by our ontology, may also change. But data do not change as frequently and so radically as processes and applications. They are much more stable as long as their implementation is based on the business ontology and a quality information architecture.

No silver bullet

There is no silver bullet to solve high architectural debt. Your main weapon will be a quality information architecture. From this architecture you will be able to identify and design your data bases including their data models. Applications will be offered information services by a REST API. Applications do not see data bases. This means that technologies for applications and data bases are independent of each other.

Quality information architecture

At the core of information architecture, you will find information models. We should say business information models – models that are derived from business ontology. This in contrast to data models that are used to design data bases. (Data models must of course fulfill the semantics of the business information model). Many have given up the attempt to build one big information model that covers the whole enterprise. Of course, even if you managed, it would not serve our need.

OBIM

We develop an Overall Business Information Model (OBIM). This is a collection of 30-50 information groups, each is derived from core business concepts. Examples are Product, Material, Site, Person, Party etc. There are both master data and event data.

DBIM

Each information group in the OBIM are modeled. A basic ER (entity-relationship) diagram will do. The important rule is that one entity can only be member of one information group. But in the diagram, we also represent entities outside the group that have relationships to entities inside the group. In this way all entities are set in context and the models remain small enough to give overview.

Dependency matrix

Information groups are building blocks for data bases. This matrix shows relationships between information groups that we must be aware of in order to design appropriate information services and control data integrity. From the dependency matrix we can do several analyses. One example is the preferred (or optimal) technical build sequence (to prevent architectural debt).

Check your value creation

Even if you do not manage to design and build a loosely coupled application architecture, you will need an architecture to clean-up and remove redundancy and complexity in your application portfolio. If you just add on new applications to the existing portfolio, we will question your value creation as an architect.

You may hesitate

Maybe you are afraid of going this new route. You may think that this will expose your previous decisions – that seemed to be right back then, but appeared to be sub-optimal in the long run. Just calm down! You are in the same seat as 99% of all architects or CIOs in this world. The future starts today – and there is no time to lose. Even if this is a change that will take time.