Levels of abstraction in architecture

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), the reports 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.

Tagged with: ,
Posted in Enterprise Architecture
4 comments on “Levels of abstraction in architecture
  1. Rob Mol says:

    Nice blog Wouter,
    There has been discussion about combining IAF and BI for several years now.
    Just describing it in a simple way, as you did, is a great step forward.

  2. With havin so much content do you ever run into any issues of plagorism or
    copyright violation? My website has a lot of completely unique
    content I’ve either written myself or outsourced but it appears a lot of it is popping it up all over the web without my permission. Do you know any ways to help reduce content from being stolen? I’d genuinely appreciate

    • sanford cairns says:

      When you find out, how to deal with plagiarism, let me know because two of my articles (together about 15 pages) were cut and pasted by another author as two chapters in his book on data architecture.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: