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.

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.

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.

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

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!

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!

Now, let’s get to the article. An argument is made to readdress our attention to executive users and renew the EIS-concept. Next to that, Dan argues that system concepts like EIS, BI, datawarehousing etc. are converging. Here’s my response.

First of all, it’s good to know that EIS’s have been covered widely in scientific research which has resulted in a significant body of knowledge. Next to that, the EIS-concept resembles our current and most common understanding of BI (i.e. management reporting in its broadest sense). BI on the other hand, has hardly been investigated yet; datawarehousing has, but BI has not. So EIS research is our most recent resource of scientific knowledge. Therefore it’s logical to revert to these theories.

I agree with Dan’s final premise that the executive is an important target group and we should focus special attention to them. In order to do so, I’d like to add two refinements. To begin with, we need a clear definition  of who the executive is. Is it limited to the CxO’s, is the 2^nd management level included etc.? What characterizes his role and his way of working? I personally experienced a situation were the board of directors insisted on receiving a printed version of the monthly performance review. No strong reporting and drill-down capabilities here… So, to target this user group, we need to define it more precisely.

Secondly, we need to separate te executive user (support) from executive process (support). Executive processes resembles processes like strategic decision making, negotiating and monitoring market trends. These kind of processes require different BI-support than tactical management processes for example. Executive usage defines usability requirements (e.g. no training required, PDA-support) whereas the required process support determines required functionality.

Current BI-platforms provide powerful capabilities to both consolidate the different kind of systems and technologies and at the same time provide the targeted support the executive needs.

First, we all know the success stories of successful BI-implementations, especially those that were put on the stand by Davenport’s book “Competing on analytics”. Harrah’s,  a casino and hotel chain is one of those examples; the CEO wrote the foreword of Davenport’s book. However, Harrah’s is also used as an example of a successful implementation of IT Portfolio Management (MIT Sloan Management Review, spring 2004, Vol.45, no.3) with corresponding net effects on Harrah’s performance. I won’t deny a priori the positive effects of both a portfolio management approach and the extensive use of analytics. But available publications gives us to little insight into the real net-effects and the causal relationships (instead of positive correlations).

This leads me to the second example. Even in scientific research we often read about the same succesful companies (sorry, no reference here). Amazon, Google, Dell you name them are always in the spotlights. In the ’80′s it was Sabre, American Hospital Supply (AHS) and Otis Elevator to name some earlier examples.

Why is that, I ask myself…