Enterprise Architecture and the Elegant Enterprise

First, let us agree on the meanings of our terms. We see enterprise architecture (EA) as a scientific sub-discipline both of computer science and business management. The twice mentioned word “science” here emphasizes our certainty that EA is an exact discipline able to produce precise approaches and solutions. We also see computer science as the underlying scientific discipline that governs the progress of IT as an industry. We define architecture as a concept that organizes and describes the lower, design level, artifacts; the nature of such artifacts may vary depending on type of architecture (systems or processes for enterprise, spaces for construction, etc.). We define enterprise as an IT-based organization having reached the architectural level of complexity of inter-relations of its design artifacts when the description and optimization of these inter-relations become more important than the design of each individual artifact.

The goal of an enterprise is to overcome its inefficiencies and to move from its imperfect initial state to a desired perfect one. The goal of EA is to create Enterprise Architecture Frameworks (EAFs), which are supposed to be complete practical guides for Enterprise Business Transformation (EBT) from the initial to the desired state.

An enterprise, while growing, creates its architecture naturally, no matter whether we pay attention to it or not. The difference, though, is in the results: an ignored architecture grows chaotically like a jungle or a slum, creating structures known as “spaghetti” architectures, while a nurtured architecture becomes orderly like a garden or a skyscraper.

All EA specialists (I hope) are convinced now that spaghetti architectures lead to enterprise business ineffectiveness and inefficiency—and inevitably suffocate the enterprise through the infamous “ripple effect,” if allowed to grow unmanaged. It means that any spaghetti EA-based (legacy) enterprise must transform itself, not just to succeed but to merely survive (some already have not). It also means that a valid methodology of such a transformation is not just an issue of fashion or bureaucratic compliance but the most crucial element of the current enterprise’s success or failure.

All the major EAFs, starting with TOGAF, expended enormous effort and have achieved equally enormous success in describing the initial state of enterprise through numerous models, meta-models, matrices, etc. They are equally capable of capturing what TOGAF calls business motivations (a.k.a. business drivers) that push enterprise out of its initial state. However, even having identified all business drivers, nothing is said about how they should be implemented architecturally. It is quite possible to add a new functionality required by business drivers just by enhancing existing applications or adding new ones, thereby preserving or even enhancing existing legacy EA. This is evidently not a right way, but how do you find the right one if its final destination is unknown? There is no answer, neither in TOGAF, nor FEAF or DoDAF.

These frameworks are missing architectural drivers (AD). Indeed, if we declare a kind of architecture bad and harmful, this declaration is still useless, unless we specify a different kind of EA state, the target state that is good and useful. The existence of ADs means that regardless of business drivers, a legacy enterprise must undergo an architectural transformation to improve its ability to support the company’s business model on its way from the current mission to the future vision. Moreover, the business drivers must be implemented in a way compliant with this architectural transformation.

However, what is this target architecture? How do we define it in an objective, scientific, unambiguous, and useful way? Is it even possible? We say, yes.

The formulation of an objective solution demands the discovery of objective problems that necessitated the search for the solution. To build our case for science-based IT EA, let us state that:

1. The main problem that IT has been facing during its progress is increasing complexity of underlying artifacts. However, IT had until recently succeeded in managing this complexity by applying the right CS methods for each historical period/level of complexity:
   
   Accumulation/Development Period: 1950s–1970s; main entities: business functionality, code, data, host; CS methods: business specs, programming languages, files.
   
   Design Period: 1980s–1990s; main entities: meta-functionality (business requirements), meta-code (e.g., UML diagrams), meta-data (e.g., RDBMS), meta-host (network); CS methods: OOA&D, relational databases, network protocols.
   
   Architectural Period: 2000–present; main entities: business processes, services, data storages, Internet; CS methods: EA frameworks based on BPM/ESB/SOA.
    
2. IT as an industry successfully adopted at the corresponding times the methods for the first two periods and en masse failed to do so during the third one, thus developing the following common business problems:
   
   High total cost of ownership (TCO).
   
   Low business agility.
   
   High cost of exit from legacy technologies (applications).
    
3. Computer science had proposed a timely, adequate solution for the architectural phase of enterprise development: event-driven, just-in-time enterprise based on the concepts of business process management (BPM), Enterprise Service Bus (ESB), and Service Orchestration Architecture. However, these concepts were not connected into a consistent and cohesive new enterprise architecture.

So, this desired target architecture should satisfy only two requirements:

1. Be based on the CS approaches for the Architectural Phase.
    
2. Be able to solve the problems mentioned above.

The reverse statement is equally true: if the proposed architecture satisfies the aforementioned requirements, it can be considered as desired target architecture. This allows us to jump directly to the static model of such EA shown in figure 1.

Figure 1

It represents the target architectural state of the Enterprise Service Orchestration Framework (ESOAF) called Elegant Enterprise.

This enterprise consists of a number of homogeneous domains interoperating in the following way:

1. External or internal actors placing requests for service in different formats.
    
2. Channels that receive these requests and preprocess them into a standard (usually XML-based) format.
    
3. XML gateways, which validate (or not) these standardized requests and place them as standard request messages to the ESB.
    
4. Enterprise Service Bus, which propagates these requests among service subscribers.
    
5. Business Process Domain, which activates the BP corresponding to the request’s type.
    
6. Business Rules Domain, which acts as a service provider when needed.
    
7. Business and Data Service Domains, which provide the request processing, update the data, and respond with corresponding reply messages containing the information requested by the actor.

It can be seen that the enterprise static and dynamic picture is solely based on BPM/ESB/SOA principles of CS. It is formulated on the purely architectural level and is of a completely reference nature. That means that this architecture does not contain any concrete-enterprise-specific design level artifacts but instead formulates each and every type of them that is used by any enterprise and explicitly describes how they interoperate with each other. It describes all the elements and the processes in the enterprise in a uniform manner, which is why it is called elegant. This reference EA can and should be mapped to a concrete enterprise to create its implementation EA.

Now, let’s look at the second criteria: how this architecture helps to resolve the business problems of IT mentioned above:

1. HIGH TCO:

a. Reuseability: This architecture places an emphasis on the creation of reusable artifacts (services, process subflows, master data, etc.); their reuse enables a substantial reduction of the projects’ time-to-market and, hence, cost.

b. Replaceability: Being totally uncoupled, all domains and their particular artifacts are easily replaceable, which naturally decreases the cost of their replacement.

c. Consolidation: Business Process Orientation allows for the exact identification and unification of the services and data that enterprise really uses; hence, the cost of maintaining and updating unused artifacts is eliminated.

2. LOW BUSINESS AGILITY: As can be seen from paragraphs (a) and (b), the architecture significantly decreases the time-to-market of any functional change or enhancement, thus addressing the issue.

3. HIGH COST OF EXIT FROM LEGACY TECHNOLOGIES:

Paragraph (b) shows how this architecture is built for replacement. It can be added that it facilitates service-by-service rather than application-by-application replacement, thus decreasing the possible business trauma of such replacement. Moreover, this architecture assures business and IT that this problem will never occur again. When the current technology becomes obsolete, the uncoupled nature of the artifacts’ interoperation will make the replacement of some of them much less expensive and practically transparent for the business.

Thus, the adequacy of this EA target state is proven. It cannot, of course, be reached overnight, as a result of a Big Bang-like architectural revolution. It requires a well-defined, steady, business-safe approach to the architectural transformation of an enterprise from its arbitrary initial state via well-described intermediate states to the desired elegant state.

Elegant Enterprise might be considered as the perfect visible target state of in-house IT architecture. It can be shown that it simultaneously is a perfect initial state of the cloud-oriented enterprise architectural transformation. The target state of such a transformation might be defined using an approach similar to presented above. ESOAF calls it Heavenly Enterprise. However, that is a topic for another day.

by Wolf Rivkin, who has a master’s degree in applied mathematics and 20+ years of IT experience. He is an expert in Enterprise Business Transformation (EBT) frameworks/road maps and author of the Enterprise Service Orchestration Architecture Framework (ESOAF). He is the founder and chief architect of B-Wave Software LLC, an analytic and consulting firm in the field of EBT.