EA state

Is Enterprise Architecture going anywhere? It is, albeit slowly in the absence of an agreed practical framework and clear proof of its business case. The reason is straightforward: EA is a necessary "evil". Any system needs a blueprint enabling proper operation, maintenance, planning... To fulfill the expectations, EA needs to satisfy its many stakeholders in top management, business, technology/IT and organization. Here are a few trends, I can see, Enterprise Architecture progressing, in no particular order: 

• • The EA evolves to increasingly cover business architecture rather than IT alone; the Enterprise Architecture will be the result of the fusion of IT, Business and Organization/People architectures; what is the the value of an applications architecture, without the process it implements or the people operating it? EA will finally be recognized as a business discipline as well, having incorporated Value Chains, Business Models, Strategic Planning... 

  • The governance for EA will be more & more business and top management heavy; this is because it would be used in mapping the strategy to components, to derive the enterprise transformation portfolio, make investments and take strategic and tactical decisions. 

  • The EA development will be increasingly triggered by Mergers & Acquisitions and outsourcing activities; IT BPO, SaaS(ASP) outsourcing is riding a strong current right now. 

  • The Enterprise Architect would be more and more called in the business decision making process; that is because the EA architect deals with the business logic, technology operation and strategy, is able to understand both worlds and use both business and IT vocabularies. 

  • A combined EA framework emerges to take advantage of the strengths of various frameworks, such as Zachman, TOGAF, FEA and others. 

  • SOA is recognized as part of the EA program as the target EA style of architecture and technology, rather than executed in isolation as it often happens 

  • EA would be increasingly required by shareholders/owners/investors to provide the blueprint of the business operation to describe assets, provide proof of regulatory compliance, map costs and profits on various operations and align strategy. Exactly like the US government demands it for the public sector. Would EA become a regulatory feature for public listed companies? 

Well, there is another possibility that springs to mind, after all: the EA team, having failed to satisfy it stakeholders is gradually disbanded to man more tactical efforts. Would this happen?

...

Overall, EA looks like business as usual. In fact, little really happened in the field for years now. Nothing of true value was added since Zachman's table and TOGAF. No substance was added. 

Except that, in this void, certifications offerings are getting a foothold. 

An external observer would say that people are satisfied with the state of the art, the methods, the frameworks, the results. I cannot speak for others; speaking for myself I would say "no way". 

Since there is no academic or an agreed definition for an EA framework, many fora and companies have come with their own views that cover just aspects of the Enterprise, in various depths. For instance, some cover the development process; others, the business process map; some add stakeholders' views. 

We often have to ask questions like: how do we map business strategy? Why is the human component "people" left out? How do we align organization, process and technology? What are the key artifacts? 

Even though it is clear for everybody now that EA should cover business architecture, there is no agreement on what that is in the first place. Secondly the business side, pushed by IT, seldom buys into the concept of business architecture. They deal with Value Chains. 

Since no major contribution has advanced the cause, most people wait and see, hoping for a miracle breakthrough. 

People technically still use the four layers paradigm: business, information, applications and technology in various combinations sometimes adding the strategy view. Even so, each layer is described differently by different people. 

The layers are poorly interconnected since there is no navigation between them. Sometimes, to compensate, architects add matrices of application interconnections, mappings of applications to technology systems, processes to applications etc. The mappings matrices are not intuitive and become out of synch rather easy. 

I believe that a "standard" metamodel would be a cure; it would help jump start the EA framework evolution again. A metamodel would describe key artifacts in layers, their entities and dependencies. In other words, it would describe an EA framework in practical terms, would provide the EA vocabulary and clearly scope the basic EA. The metamodel will be the key structure for EA development, additions and tool. 

EA remains confined in the space of IT where it is slowly depreciating since the business people have no incentive to use it. In fact they would prefer to outsource IT altogether as a too costly and troublesome distraction. They would like a clean contractual relationship to a rather chaotic cross boundary continuous debate with IT. 

Business expects the EA to describe the Enterprise operation, which is not the case and as such ceases to employ the EA. The Enterprise operation is partly described sometimes by process maps and improved by frameworks as Six/Lean Sigma, but they still seem to remain independent approaches. 

Yet, everybody agrees that EA is necessary despite its performance in terms of results and usage. 

...

From time to time it is worth assessing the progress of Enterprise Architecture body of knowledge. Not much has happened in the past few years. 

It was said SOA is dead or at least the hype. With the EA the problem is no better. It is barely moving. No remarkable results have been published. Most use own frameworks because the EA frameworks are what they are. But EA has yet a lot to deliver since the concept is very promissing. 

Zachman covers a high level philosophy, Socratic in that it asks various questions to define an entity. It is called sometimes an ontology or taxonomy. It is not practical, it does not take us too far. After asking the first few questions, the road ahead is too open to interpretation. There is no more guidance. It is appealing in its simplicity to top management as it enables an executive's analytical approach. But, at the next level of depth, another framework is required. 

TOGAF covers extensively the process and its deliveries, ADM. Its technology standards chapter is said to be obsolete. TOGAF 9 adds a few hundred pages, some structure and Archimate, an architecture language which looks more like a metamodel. People are looking hard for examples because it is not clear how to use it. It introduces services and interfaces although most Enterprises, having evolved organically, cannot be described using the service concept. And that does not help TOGAF. 

Neither of these frameworks is specific to the Enterprise, i.e. they can be applied to most technical systems. As such they can be called Architecture rather than EA frameworks. 

Zachman covers a high level taxonomy while TOGAF a process. In a sense they are complementary. None of them provides guidance for the structure of an Enterprise which is essential for an EA framework. 

As a result no two EAs outcomes are similar. Everybody pretends to know Zachman and TOGAF. It's easy to pretend to be an EA architect as Zachman's matrix is a straightforward one pager while few can verify that an answer is compliant or not with 800 pages of TOGAF. 

FEA and DODAF are more prescriptive but specific. And even so no two departments EA look or feel quite the same. 

EA frameworks should enforce repeatable or predictable results so that even if you build your EA in two different Enterprises in the same industry, they should still have the same fundamental structure and components. So you can compare apples with apples. 

Some have delivery checklists but architecture is about diagrams not lists. 

No framework offers reference designs (templates), not even for IT, except, maybe, for the old model-view-controller paradigm for software. 

As with SOA, the first step is to design the EA Business Architecture. It is not the business of IT, in the first place, but IT understands "architecture". 

The business schools, academia, management consultancies have not quite put together a business reference map to guide the architecture. What are the typical parts of an Enterprise? You would wonder why they don't need an EA in their work. 

There are a few tries though at process architectures. (APQC, VCG, SCOR, eTOM...). They do not help too much though. They are virtually unknown in the IT domain. They are used by business people for benchmarking and quality improvement. The Value Chain concept, the closest attempt to an architecture in the business world, looks foreign to the IT world. 

How can you build an Enterprise Architecture (essentially the Enterprise structure, operation and strategic planning) starting from technology, IT for that matter? 

Imagine an electricity utility company that has other technologies. How can the EA IT architecture describe what the Enterprise does? It can catalogue the IT landscape and document front-ends, back-ends etc. But there are networks of transformers, transmission lines, couplers, switches, meters, SCADA systems not part of IT. Not to mention the people operations. 

The natural expectations of business and management from the current EA i.e. to deliver the Enterprise blueprint, roadmap, transformation are far from being fulfilled then. The solution would be to limit the expectations to technology standardisation, reduced platform duplication and complexity and integration of the islands of IT. 

To succeed, in its full meaning of structure and operation of the Enterprise, the EA has to be started top down from the business architecture in scope (for instance for the Operation or Shared Services) and then the supporting technology architecture. But the division between business and IT does not help.

...

I would look now at the dark side of EA to regal that hidden audience just lurking under the surface, keen to express their distress with the EA state of art. 

"Enterprise Architecture as a Black Hole" (to paraphrase a known title of an EA book) seems to be a proper name for many EA contemporary developments. To business, EA certainly looks like that. It sucks resources and energy and returns naught. 

To IT, the EA often means an IT applications and technology architecture discovery and design exercise. No more than that. But, since long, IT appended to its technology the "Enterprise" denomination to demonstrate it can be used anywhere inside. But that created false expectations for business and other stakeholders. 

Zachman, while developing the framework, initially for IT systems, extended it to the Enterprise. So people expect all the benefits of an Enterprise level architecture as opposed to those of an Enterprise level technology like JAVA, EAI, ESB... This mismatch between expectations and deliveries may ruin the EA prospects, in time. 

I have surveyed the EA field for years now and I have to say that the state of affairs is bleak. We have pretty much the same few frameworks we had years ago, with a few twists. The EA scope can be anything you like. 

The trouble is we have more EA architects and developments than ever. Are the EA developments fruitful? What do they deliver in fact? What keeps the architects busy? Do they feel secure? 

What does an EA architect use for a framework? 

Essentially, there are two schools of thought. 

One, indeed, appears philosophical, looking into the approach to the discovery and design of a system. The EA architects like true Socrates' disciples, start asking questions like Why, What, How, Who, Where and combinations like Where is Who? Where is What? Who makes what? or who knows what or maybe who's who. The answers though, consituting the basis for the Enterprise artifacts, may have such a variability that is hard to forecast what you get. You are left on your own, with little guidance, soon after asking the questions. No two answers look similar. 

Nevertheless, the management likes the questions as they convey the right scope avoiding the focus on IT only. 

But, as with philosophy, those questions beget other questions rather than answers. 

An EA framework should enforce similar predictable and repeatable outcomes, otherwise it fails to be a framework. 

...

On the other hand we have the "method" cult. This, in a "deus ex machina" manner, promisses results if you follow the process provided. 

In my experience, in a known company, the architecture development exercise was restarted three times, with different deliveries and management teams. While the results were different for each iteration they were similar neverless in their uselessness and quantity of tree paper. They did not address any stakeholder specifically. 

The process alone did not help without a framework defining the artifacts, the relationships, the expected outcomes and their form. 

The cult members have to be expensively certified to be accepted. They have a bible of many pages, describing in indiscriminate detail the workings of the EA architect's. How do you use it? You open it at a certain chapter and read the verse. "You have to do this and that!" There is no holy picture to show you the inner soul or structure of the Enterprise. The method is general enough to help you build anything and everything. Down the line, you start offering a stack of unrelated, uncorrelated artifacts, with lots of explanations. The customers of that, if any, are not clear. As a result, nobody feels served. The results, one might say, are not quite fit for purpose. 

"Enterprise Architecture is about diagrams, not stories"; I would like to suggest it as a key design principle. 

Our customers need interconnected diagrams to analyse interaction, costs and impacts, rather than heavy tomes describing whatever. And they are not interested in the methods we use, whichever.