Gartner and Forrester on Information Architecture

Both Gartner and Forrester have recently put a spotlight on information architecture. In a prediction for most important IT-roles for 2010, Gartner selected Enterprise Information Architecture as one of them. Two weeks ago, Forrester published a topic overview on information architecture.

With the ever growing amount of structured and unstructured data, increasing emphasis on information architecture is relevant and right. While cloud computing, appliances and SaaS-solutions to name a few, address the technical challenges in handling all this data, information architecture focusses on determining what information is there in the first place, what information is required in the future, how all information assets relate to each other, and how they connect to both business processes, functions and goals and applications and technology. Recall the basic framework for enterprise architecture and one can easily plot the four architecture layers on the above description (business, information, application and technology architecture). Information architecture, in the definition used by Forrester, aligns with this basic framework.

Both identify structured and unstructured data in scope of information architecture. Although conceptually not necessary – IA deals with information in a general sense, regardless of its structure – it’s good to point to both types of data, as unstructered data in the BI-space is still often left out of scope.

Interestingly, as Gartner points out, people fulfilling the role of information architect will increasingly originate from outside IT, bringing in more business experience. I think this would be a welcome development and enhances an organization’s ability to truly focus on the added value of information, regardless of the technology used.

Yet, despite its increasing role and importance, IA is still in an early stage according to Forrester, mainly because of the horizontal approach (which crosses vertical boundaries) IA requires, the pre-requisite of business – IT-alignment and the wealth of corporate data and information that needs to be ‘architected’. To face these challenges, a new breed of information architect is required, one with strong skills and savvyness, as Gartner points out.

One word of caution though. As with nearly any concept within IT, there’s a tendency to include the whole world and make any new concept THE new thing to do. Forrester’s account of IA touches upon adjacent concepts like information management, data governance and MDM. Let’s be vigilant about this kind of scope creep and clear about the primary of (information) architecture which is design. Architecture is “the art and discipline of creating an actual, or inferring an implied or apparent plan of any complex object or system” as Capgemini’s IAF manual puts it. The primary focus of such a plan is on structure and relationships with reference to a set of governing principles that provide guidance and support for direction and decisions. Other disciplines, like information management and governance processes use architecture artifacts to make these decisions and provide this direction.

Tagged with: , ,
Posted in Enterprise Architecture

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

Response to ‘A case of don’t kill the messenger’

This is a response to Neil Raden’s post on B-eye network – I was unable to submit a reply on the BEN-site.

Hello Neil,

I’m happy to see that you have taken the initiative to follow-up on this controversy. What bothers me the most is the unwillingness (by Evelson in this case) to engage in a real and critical discussion regarding the topic in question. Every such discussion is a new opportunity to further our knowledge and improve our collective understanding. One can argue whether a tone of voice like Few used in his reply encourages such a discussion but while doing so we omit the fact that Few is trying to make a real argument (he’s not solely ranting, far from it). I even suspect that Few’s wording is not only triggered by Evelson’s post but has been fed by more inaccurate statements regarding his topic of interest, published in other media and by other people.

I have too little knowledge about the business models of analyst’s firms to comment on your explanation in detail. But your general observation that analyst firms seem to lack true in-depth insight has also crossed my mind. Moreover, the lack of critical discussion and more factual insight is IMHO a more fundamental problem that endangers our profession in general. As you twittered yourself: know what you’re talking about and challenge the facts. Keep spreading the word.

Posted in Uncategorized

Bill Inmon’s versions of the truth

Recently Bill Inmon made a post on his B-eye channel about what the data warehouse is not. It immediately led to a storm of discussion on Twitter between several analysts, among them Colin White, Claudia Imhoff and Seth Grimes. Bottom-line of their reaction: Bill’s definition is a traditional one and does not reflect current industry practices. Moreover, Inmon initially stated that SAP was the only company offering a true data warehouse solution (see Colin White’s tweets) but in the current version of his article this statement has been left out. Another version of his truth?

With the risk of initiating another fierce discussion, I react to Bill’s following statement: “Data warehouses exist for the purpose of supporting management, not operations”. Five years ago I would have concurred but now I simply disagree. It’s like having a word processor but restricting its use to only writing memos. The roots of ERP date back to MRP, Material Requirements Planning. Obviously, its current scope is much broader. I used to dislike the idea of using a data warehouse to support operations, but have come to a different insight. What is the use of a sound data warehouse when it’s use is restricted to only one business function? Data (or information or knowledge for that matter) is to share, not to sit on top it. As Colin White points out: there’s theory and there’s practice and the industry simply evolves.

Ok, that said, I need to say that I’m also allergic to people redefining and misinterpreting originally sound defined concepts. To that end, I support Bill’s plea. Take for example the concept of a core competence, defined by Prahalad & Hamel. Does anybody still knows the three distinguishing characteristics of a core competence? Guess not (it’s: provide entry to new markets, difficult to imitate, support customer’s needs). Take any declared core competence and I bet hardly any instance complies with these criteria.

But, I’m not going into the discussion regarding the (sound) definition of a data warehouse (again). Instead, I like to approach the issue of operational use from a different perspective, yep the architectural one. One key question we need to ask is whether there’s a fundamental architectural principle that inhibits the use of a data warehouse for operational purposes. Or rather, a universal principle. My answer to that question would be no, there’s not. There’s no principle like ‘Thou shall not use a data warehouse operationally, ever”. Architectural principles that do guide this trade-off are for example reducing dependencies, reusability, business responsiveness etc. But it is up to each invididual organization how they want to trade this off and what its implications are for the data warehouse. Second, we need to bear in mind that the way the application architecture is realized (i.e. physically implemented), is driven to a large extent by the capabilities of the technology architecture (i.e. infrastructure). Nowadays, new data warehouse-technologies are capable of dealing with operational service levels (real-time integration, split-second response, failover etc.) at an affordable cost level making it practically and economically feasible to use a data warehouse for operational purposes. Again, this should be a trade-off driven by architecture principles and constraints. Then there’s the question whether the data warehouse is a logical or a physical construct. If it is seen logically, operational use of a data warehouse at the physical level may imply for example a seperate datastore in order to avoid direct physical access to the (physical) data warehouse.

It’s a difficult discussion and not one that will likely be settled after this post. What I wanted to make clear is that there are multiple considerations and viewpoints – principles, logical vs. physical, application vs. infrastructure – that need to be considered when operational use of a data warehouse is being discussed.

Very much like to hear your comments on this one!

wouter

Tagged with: , ,
Posted in Enterprise Architecture

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

Enterprise architecture and BI: the prequel

For long I’ve been wanting to start this post and finally got to it! You may have noticed the tag line I’ve added to my site: it emphasizes my desire to blog and write more and deeply about enterprise architecture and BI. To get to the bottom-line of my argument right away: BI and enterprise architecture are not 2 seperate worlds. When enterprise architecture is viewed in a broad sense as a holistic approach to conceptualize and (re)design an enterprise, BI is simply part of that. And to throw in another one: architecture is not the same as data modeling. Rather, they are two completely different things. So, in a sense this post is a sequel to the “BI is the same, not different” post. My mind is exploding with ideas and insights I want to share with you, so the next blogs will be used by me to deepdive into this matter (hopefully on a more frequent basis). To give you some idea, I will blog about the different type of architectures (enterprise, domain, reference, solution), architectural frameworks (IAF, TOGAF, DyA), architecture modeling language (Archimate) and denote the relevance and application for the BI-field.

By deepdiving into some of these theories and providing practical examples, the application of these concepts for BI can be made clear. This adds to understanding between BI-professionals and enterprise architects. Unfortunately, this understanding is often obscured in practice because of misunderstanding, misconception or misinterpretation of each other’s profession and area of interest, hence my motivation to try to improve this understanding a bit.

I’ll try to follow-up on short notice with a next post, which will start the deepdive. It’s my intention to discuss one topic a time, so each blogpost will address one particular issue. Stay tuned!

Tagged with:
Posted in Enterprise Architecture, Our profession

Next generation front-end architecture published in DB/M

DB/M 5 features my article on next generation front-end architecture. It uses TOGAF as a frame of reference to introduce the BI Triangle, distinghuishing between a business, application and technology layer for defining the front-end architecture.

Posted in Enterprise Architecture
Categories
Archives