Does it still matter what matters in Enterprise IT? Even before the current harsh times the field seemed to be a land of confusions and illusions, from CIOs greatly overestimating their departments' and their own role in the eyes of their CEOs, to business analysts continuously unable to get exactly what they need when they need it from their IT counterparts. And to a respectful analytical firm putting as much confusion as possible in one sentence: "Although the word 'SOA' is dead, the requirement for service-oriented architecture is stronger than ever" (sic!). It is a 'twilight zone' where no one seems to speak the same language, where the same things are called by different names and different things are called by the same names. Moreover, these 'things' themselves seem to change their appearance and meaning depending on who is trying to name and use them. Dear colleagues, it is not the word 'SOA' that is 'dead' wrong, it is our interpretation of it! Do we, inhabitants of this land even need an objective light of truth to get rid of these ghosts and chimeras, or are we too comfortable dreaming in its twilights? This article is for those who would still appreciate some light.
It is very tempting to start right with SOA. However, this would mean just scratching the surface. The ontological and methodological problems have been accumulating in our "Augias' stables" for almost a decade now, so we need to start the 'Herculean labor' of cleaning them from the very foundation.

We used to think of an Enterprise as consisting of two parts: Business and Information Technology. Even when we say 'IT', we mean first and foremost Technology. However, as we all have learned lately, these two parts do not align easy with each other. We still have this infamous Business-IT gap, which cannot be filled either by business or technological means. It shows us that there is some other substance that should glue them together. We have already identified some parts of this missing 'substance' in the form of different Enterprise frameworks such as Enterprise Architecture (EA), SOA, BPM, ESB, etc. However, to this day we have different opinions about what they really are, what their relationships are to each other, and what we need them for. We lack profound knowledge of what underlies and unifies them and puts them in the right places in the 'big picture' of the Enterprise Business-IT Alignment.

It might seem nothing but a purely 'theoretical' issue, far from being important in these difficult times. On the contrary, it is in these times that we really need the deepest knowledge to make critical decisions quickly and correctly. Without this kind of understanding, all terms and methods of the modern Enterprise Business and IT Management seem arbitrary and vague. It has come to the point, where some of us, to avoid endless confusion, have decided that every Enterprise has its own definition of, for example, EA and SOA, thus mixing up conception and realization, a class and its instance. If the concept of SOA is different for different Enterprises then it is not a concept at all!

This conceptual confusion leads to very practical and unfortunate results: being unable to determine what is what in the Enterprise, what does matter and what does not, the decision makers blindly cut off vital parts of the Enterprise's organism, sometimes killing it rather than helping it to survive. So, what does matter in the Enterprise? And what do we mean by 'matter'?

Our goal is the Enterprise's survival and success. Those things, which must be better, understood and improved to ensure a company's survival and those, which might create a competitive edge for its success matter for us.

First, does Technology matter? This part is easy: it should already be clear to any IT professional and most business leaders that Technology itself is a level playing-field now and cannot bring a competitive edge to a company. The technology standards and solutions are stable and proven, the proposals from major technology providers are all based on them, very similar, and priced very much alike. So, the choice of technology becomes more an issue of a company's legacy and culture.

Moreover, the emergence of Cloud computing promises to spare Enterprise this choice altogether, making technology an entirely uniform commodity service, which could be bought like power from a power company or phone services from a phone provider. It is not that simple yet, but it is very close and becoming even closer very rapidly.

It is HOW we use Technology and WHAT FOR that makes all the difference. The notion of Methodology, which is defined by Encarta as "the methods or organizing principles underlying a particular art, science, or other area of study" might help us to provide the conceptual answer to these questions.

Our 'area' or 'object of study' is IT-based Enterprise. From OOA&D we know that we can fully describe an object if we know its Features and Behaviors. The 'organizing principles', offered by Methodology, are represented in the case of Enterprise by its Architecture. It allows us to uncover Enterprise's Features: a hierarchical structure of its entities. Likewise, the Methodology's 'methods', or behaviors, immanent to an Enterprise, are understood as various Processes, by which these entities interact with each other, and with the outside world.

So, we have an important result: In order to fully understand Enterprise in its entirety and to be able to organize it and to predict, or even better, to direct its evolution, we need to properly comprehend two things: Enterprise Architecture and Enterprise Processes, which have a common denominator--Enterprise Development Methodology.

Enterprise is a dynamic object. It is not 'fluid' or 'chaotic', however. It has a firm, well-defined structure (architecture) at any time. This structure might (and should) evolve under the influence of its processes but not become completely different overnight. Methodologically, it is possible to differentiate three kinds of the 'organizing' processes that describe Enterprise's behavior:

1. External and Internal Enterprise Business Processes (EBP) that constitute its current Business Model (EBM), also called the Mission. These processes provide a desired business result to either an external Enterprise's business client or an internal business unit.

2. A Unified Internal Process of understanding and formalizing of EBPs and then creating their exact informational (including computational) simulation in a way that brings the most value to Enterprise. It is an improved version of the former Software Development Life Cycle (SDLC), which is now called Business Process Development Life Cycle (BPDLC). It represents a seamless, well-defined, detailed cycle of internal Enterprise Activities from the formulation of the business strategy, to its realization as business processes, to their analysis and optimization, to the provision of a feedback for the improvement of the strategy.

3. The process of the evolution of the Enterprise as a whole through time from the current Mission to the desired future EBM, called the Vision. This process defines how Enterprise Architecture and Processes must evolve over Enterprise's lifespan to provide a smooth, predictable, business-safe path from the Enterprise's Mission to its Vision.

Again, EA and the aforementioned triad of Enterprise-related Processes constitute Enterprise Development Methodology (EDM)--the missing part of the Business-IT equation. It is right or wrong, objective or subjective, well-defined or vague Methodology that differentiates an aligned, agile, and efficient Enterprise from divided, non-responsive, and inefficient one.

EDM finds its practical realization in Enterprise Architectural Transformation Frameworks (EATF) that identify the ways in which Enterprise's Architecture and Processes should be defined, interact with each other, and evolve over time to provide a smooth, business-safe transformation of the current 'Legacy Enterprise' into the future 'Elegant' one.

'Legacy' and 'Elegant' Enterprise are the terms of one such a framework: Enterprise Service Orchestration Framework (ESOAF). It is entirely founded upon concepts of BPM/ESB/ SOA-based EA, and BPDLC, thus being methodologically coherent and complete, which has a direct practical impact. It allows Enterprise Business Management to apply just enough financial and managerial effort to the right points of the Enterprise at the right time to achieve the desired results, thus avoiding overspending or cutting vital functions, which are the usual consequences of following methodologically blind, empirical, error-prone, arbitrary criteria and methods of dealing with this extremely complex system.

We start by laying a methodological foundation for a better understanding of 'all things Enterprise'. We will build our objective understanding of these 'things' on this foundation in future articles.

It was Nicolas Carr who first said: "IT Does Not Matter". He was right about the 'T' but not the 'I'. Then, Howard Smith and Peter Fingar said: "IT Doesn't Matter-Business Processes Do". They were also right about BP, but as we have seen, there are other things that matter, besides EBP. So let us elaborate upon this again:

About the Author: Wolf Rivkin has a master's degree in applied mathematics and 20+ years of IT experience, including 15 years as a senior level architect and manager. He is an expert in Enterprise Business Transformation (EBT) Frameworks/Roadmaps and author of the Enterprise Service Orchestration Architecture Framework (ESOAF). As a Principal/Chief Architect he led EBT efforts for industry leaders in telecomm, financial, media, utilities and hospitality industry verticals. He is the founder and Chief Architect of B-Wave Software LLC, an analytic and consulting firm in the field of EBT.
SOA Institute