A basic architecture framework & some first implications for BI

In order to start our discussion on enterprise architecture and its implications on BI and data warehousing, we’ll need a basic framework. Let’s start with that. Below is a picture of such a basic framework. It is adapted from the content framework of TOGAF (The Open Group Architecture Framework) and Capgemini’s Integrated Architecture Framework (IAF). Other frames of reference like Archimate and DyA will show a similar structure. I won’t go into all the similarities and differences; they are important to a certain extent but I will save that kind of detail until later. So, let’s look at the framework:

Basic EA architecture

This basic framework distinguishes 4 layers or aspects (I deliberately do not use the term domain or view). The business architecture describes business concepts like business processes, organisational structures and business goals. The information architecture describes the information the business uses and their interrelationships. The information architecture typically is NOT a (conceptual) data model. The application architecture describes the information systems that will be used to deliver the information defined in the layer above. Finally, the technology architecture (NOT technical architecture) describes infrastructural components, like hardware, DBMS’s, networking and so on.

If we use this framework to look at an entire enterprise, the business layer would describe the enterprise’s entire business (i.e. all its business processes, roles etcetera), the information layer all the information that is used within the enterprise, the application layer would describe all the applications and the technology layer the entire infrastructure. For example, the application layer would typically be visualized or represented like an application landscape, denoting families or clusters of systems.

As I said, such an enterprise perspective would include everything, including for example at the application layer BI-systems like a data warehouse, an analysis application or a dashboard. This whole notion of a BI-system (or rather family of systems) and how typical BI-components like a data warehouse, staging areas, cubes, reports etcetera fit into this conceptualization also needs elaboration but that’s for later. For now, I propose to adopt a information system view. At the application layer – when adopting an enterprise-wide perspective – such BI-systems would be modeled next to all other systems within the enterprise, most notably primary transactional systems like order processing, inventory management, pricing systems etc. Similarly, the technology layer would show all the infrastructure used within the company: the data warehouse appliance next to ‘operational’ infrastructure like RDBMS’s and an enterprise service bus. Note that if we look from an enterprise perspective, we don’t see the distinction between BI and non-BI (or OLTP for that matter anymore): we simply see everything!

So, what’s the importance of all this? I would like to hear your answers to this question. To give you a heads up: adopting this layered and integrated views support discussions around ‘operational BI’, the use of your BI-tool as an enterprise-wide reporting platform (from a technology architecture point of view) and the role of the data warehouse in the enterprise application landscape to name a few. More to come up in my next post!

Posted in Uncategorized
3 comments on “A basic architecture framework & some first implications for BI
  1. Martijn evers says:

    “The information architecture describes the information the business uses and their interrelationships. The information architecture typically is NOT a (conceptual) data model”

    IMO a language driven conceptual data modelling technique like FCO-IM could form a substantial part of an Information architecture. From such a model you could generate descriptions, ontologies, identification taxonomy and business glossary.

    I agree that ER conceptual models are not very helpful within an IA.

  2. Wouter says:

    Nice thinking! The additional definition in IAF (sorry, not yet publicly available but upcoming) describes the output of an information architecture as “business information components that describe what and how information is used and how it flows around the business”. As far as my knowledge goes (the last time I used it was in ’98, does it still exists??), FCO-IM does exactly that.

    However, I also experienced that FCO-IM leads rather quickly to a high level of detail, whereas an information architecture initially requires an low level of detail (i.e. ‘large building blocks’)

  3. […] 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, […]

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: