Levels of abstraction in architecture

[Latest News Headlines]

It is remarkable how often is written about a ‘BI architecture’ or ‘DWH architecture’ without a proper frame of reference to architectural concepts. For example, I recently came across a BI ToBe-landscape proposition that completely mixed up architectural layers as well abstraction levels (more on that later). The proposition raised more questions than it answered…

I’m the first to admit that I contributed to this practice as well and have learned in the past year that this seriously hampers efficient and effective design. Or, to be more positive, using generic (enterprise) architecture concepts can greatly enhance the quality of our architectural work. Note that I’m not talking about data modeling. In a previous post I introduced a common architectural model, consisting of 4 layers: business, information, application and technology architecture.

Thinking in layers helps in positioning what were talking about. When we talk about ‘reporting’, do we mean the reporting tool (technology layer), thereports themselves (application layer), the information in it (information architecture) or the manager reporting to his superior or using the information in a report in his work (business architecture)? By now, you should have gotten a feeling how the architecture layers work.

There’s a second dimension to the architecture framework and this one deals with abstraction levels. Using different levels of abstraction is a means of dealing with complexity and completeness. IAF, Capgemini’s architecture framework, distinghuishes 4 levels of detail: contextual, conceptual, logical and physical. By and large, TOGAF uses the same level although is less strict. The contextual level is generic and focusses on the WHY-question. Why is there a need for architecture in the first place, what are the business objectives, constraint and architecture principles. The remaining three abstraction levels pertain to each architecture layer. Conceptual deals with the WHAT-question: ‘What is needed?’. Logical deals with the HOW-question: how can the architecture best be optimized and structured to achieve stated objectives. Physical is concerned about the ‘WITH WHAT’-question: it prescribes an implementation specific structure.

So, where and how does this distinction helps us?* Take for example the recurring discussion about layers in the datawarehouse (pre-staging, staging, data warehouse, staging out etc.). This discussion can be positioned in the application architecture-layer, at both the logical and physical level. Layering has to do with structuring and optimizing, and is therefore in the first place positioned at the logical level. Provided that we know the answer to the WHAT-question (conceptual) and contextual requirements (required lifespan, easy of maintainability, interoperability, etc.etc.) we need to think about the optimal structure. Next comes the question how this structure can best be physically implemented. For example, on the one hand all the layers can be physically implemented as database tables within the same database scheme of the same database instance, on the other hand every layer can be physically implemented seperately. The choice depends on architectural requirements and contextual factors.

Obviously, there’s also a great dependency on the technology architecture that is needed or to be used for implementation. The architectural framework supports the discussion about the optimal solution. Moreover, defining the solution is not a one-way street: an architectural framework does not prescribe a mandatory sequence (from business –> technology or from conceptual –> physical). Rather it is typically an iterative process: architectural work can commence at any layer and at any level of abstraction. From there, other layers and levels can be defined or analysed. Thinking about where you are in the framework helps in understanding what aspects you’re talking about at which level of abstraction.




More from the Wouter on Business Intelligence Blog...