jump to navigation

BPMI featured article: Closing the Business-IT Gap Once And For All January 8, 2009

Posted by wrivkin in Enterprise Architecture & Business Transformation.
1 comment so far

Please find on:


Please react, criticize, make fun of :-).

Do we even want to have an objective conceptual description of Enterprise Architecture? And if not, why? What does it tell about us? (Full vesion) January 6, 2009

Posted by wrivkin in Enterprise Architecture & Business Transformation.
add a comment

Our sister discipline – Constructional Architecture is defined in Wikipedia in this way: “[CA] definition … includes the design of the total built environment, from the macro level of how a building integrates with its surrounding landscape (see town planning, urban design, and landscape architecture) to the micro level of architectural or construction details and, sometimes, furniture. ”

It defines the Constructional Architect profession as” “Architects have as their primary object providing for the spatial and shelter needs of people in groups of some kind (families, schools, churches, businesses, etc.) by the creative organization of materials and components in a land- or city-scape, dealing with mass, space, form, volume, texture, structure, light, shadow, materials, program, and pragmatic elements such as cost, construction limitations and technology…” As you see, this definition is very elaborate and defines also the major entities and processes of the discipline. The discipline and the profession are very tight in this definition, because the latter is based on the former.

Of course, Constructional Architecture is much older, more developed, and better understood than the Enterprise one. it has 3000 years instead of 30. However, shouldn’t we expect more from the intellectual potential of
today’s EA thought leaders, considering that they have a very good systematic example to follow?

Wouldn’t you agree that the term ‘architecture’ is not random but is applying to the systems with certain level(s) of complexity? Then it is very much possible to translate this definition into EA’s one.

Instead for EA from Wiki we have: “The term Enterprise Architecture refers to many things”(?!). The ‘definition’ continues as “To some, “Enterprise Architecture” refers either to the …., or the …. To others, “Enterprise Architecture” refers to …” Once again, it is understandable. But is it satisfactory?

Why are many of us so resistant to even an attempt to raise the level of EA to, at least, the level of CA? I say, at least, because in my opinion, EA is much more suitable to exact, scientific description for it lacks this human aesthetic component that is so important for CA and not at all for EA.

We started so well with J.Zachman’s ZAF, Spewak’s and other early framework. But look what we have now. Several government (read bureaucratic) frameworks, which serve completely  bureaucratic needs, contradict to each other in their very foundations, and concentrate on the Current, imperfect Enterprise Architectural State without any attempt to describe the Enterprise’s transformation towards the Desired one.

One of the participants of a LinkedIn discussion on EA has recently seriously offered to apply the Chaos Theory to it. Yep, chaos is what EA has currently plenty of.

State Of Enterprise IT Architecture 2008 Annual Address. January 3, 2009

Posted by wrivkin in Enterprise Architecture & Business Transformation.
add a comment

It is not accidental that the usual EA (Enterprise Architecture) abbreviation is replaced in the header of this post by IT EA. 2008 was the year when the paths of EA, which will be more and more represented by Enterprise Business Architecture (EBA), and its computing counterpart started to split . IT EA is slowly but steadily migrating to Cloud, where it hopes to feel much better. Whether these hopes are to be fulfilled, remains to be seen.

It is pointless to analyze a development in any of the major EA frameworks in 2008. In their current state, all of them constitute nothing but attempts to apply an arbitrary set of methods to an arbitrary set of entities. Without an exact and unambiguous definition of EA as a discipline these attempts will remain, well, arbitrary and fruitless. Some of them represent bureaucratic responses to legal bureaucratic requests, and all of them just concentrate on the Enterprise Current State with no or almost no attempts to predict or direct the development of the target structure – IT based Enterprise.

Lacking this definition, IT EA in 2008 remained more an art than a scientific or engineering discipline, unable to help business and IT leaders to find objective goals in IT development and corresponding methods to achieve them.

Plenty of examples of such a discontent can be found in the interviews with the best CIOs of 2007 published by “CIO Magazine” in the beginning of 2008. These interviews revealed one quite stunning detail: All of these most successful CIOs used absolutely different terms and concepts in describing their different objectives and methods! Sometimes it was on the edge of being ridiculous. For example, one CIO told the magazine how she arbitrarily set a goal of decreasing her IT budget from 2% of the company’s revenue to 1.5% just because she heard that some other CIO did that. So, she achieved it by relentlessly and senselessly cutting projects and jobs. Questions like: ”How much overall profit does my IT and each part of it generates?” or “Maybe I can quadruple the company’s profit while increasing IT’s budget up to 2.5% by introducing some groundbreaking technology or methodology advances?” seemed to slip her bright mind. It is hard to imagine the CEOs or CFOs of these or any other companies describing their goals and methods in completely arbitrary terms. It would be considered absolutely unprofessional, because they must follow the terms and laws of Economics and Business Science, no matter how different their decisions are.

It is not the same for CIOs: they just do not have an exact concept to follow, so their success or failure depends more on their individual managerial and technical talents and, thus, varies. Let us also say that none of them mentioned Enterprise Architecture as their guide in the improvements they made.

In the absence of an objective, widely accepted and approved Enterprise Architectural Transformation Framework, it is logical that more and more Business leaders in 2008 just appointed former CFOs or other financial gurus as CIOs with this sole task: to cut IT costs no matter where and how. These people, like their bosses, do not see any value in internal IT, do not understand it, and just want to get rid of it by outsourcing to the cheapest Cloud bidder. The clearest example of this is Chrysler.

What is even more stunning is that a survey, made by the same journal, revealed that CIOs see enterprise architects as the most valuable and hard to fill positions in IT. It means that they feel the necessity of EA ‘in their guts’ but cannot obtain any real help from it.

The ‘objectifying’ of ES could have changed this picture, but as the author’s experience with the EA community in 2008 shows, the majority of it does not feel the obligation to turn EA into the precise, necessary tool for Enterprise IT/Business Transformation, which their leaders are in desperate need of. Many EA thought leaders and practitioners feel very comfortable having their field in a ‘descriptive art’ state.

However, this ‘comfort’, which has lasted for almost 30 years now, is about to end. As IT reached the current state of complexity about 10 years ago, this complexity initiated an internal conflict between its level and the methods IT used to handle it. Put simply, it was (and is) the conflict between the Architectural level of the modern enterprise IT’s entities and processes, and the Design level of their creation/management. The complexity of IT’s structure is such that the inter-operation of its Design-level parts (applications) is more important than the design of each individual part. When this complexity is being handled with the same design-level methodology as in the 80s and 90s, it inevitably (objectively!) creates rigid, unmanageable structures, known as ‘spaghetti ‘architectures. The next inevitable step is creating the infamous gap between Business expectations and IT possibilities.

This gap could be easily closed if new EA approaches (BPM/ESB/SOA) were implemented in a proper, timely manner. However, as in previous years, in 2008 EA professionals were too busy creating and implementing existing and new meta-models and matrices, i.e. different ‘snapshots’ or ‘portraits’ of the current, inefficient Enterprise Architectural State. They can be proud: they now have tens more ways to describe how bad things are!

This happy lifestyle is going to end, though. The ‘writing on the wall’ was quite visible in 2008. The widening ‘gap’ has become a ‘break’. Business has, at last, lost its patience. It ‘conspires’ now with vendors (and all of them, starting with IBM, MS, HP, SAP, Oracle, are trampling each other to answer this call) to outsource its in-house IT operations to what is the ‘hype’-word of 2008 – the Cloud. IT operations and, hence, Architecture exit Enterprise, leaving its in-house ‘architects’ behind.

So, let us summarized what happened to Enterprise Architecture in 2008:

  • As IT’s complexity has continued to grow, the gap between Business and IT has reached its critical value;
  • Enterprise Architecture could help to close this gap, but its current ‘descriptive art’ state prevented it;
  • EA community did little to provide CIOs with an objective proven tool to transform the enterprise IT and satisfy Business needs;
  • Finally, Business leaders have lost their believe in the capability of in-house IT to transform; instead they accepted the policy of outsourcing internal IT operations to third-party vendors-owned structures, known now as Cloud;
  • While not happenning overnight, this process in the long term means full migration of enterprise internal operations (and their Architecture)  into Cloud.

In-house Enterprise Architecture is dying. Long live Global Cloud IT Architecture!