We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Enterprise Architecture Matters

Adrian Grigoriu

EA architects still discuss what architecture is

Vote 0 Votes
The fact that we cannot even agree on what architecture is, never mind what enterprise architecture (EA) is, says a lot about the maturity of the EA discipline that, surprisingly, has so many practitioners and experts today. What is EA delivering then? 
That explains too why we argue so much about any EA aspect and why our results differ so wildly

Should we even discuss what architecture is? Are we trying to redefine the term architecture yet again?
Had our stakeholders discovered that today, we still debate what architecture is, they will feel rather distressed. What credibility would we still claim then?

In simple terms, architecture is the description of a system that enables the construction,  proper usage, repair and further development of a system. 
Architecture as such, is implicitly embedded in the constructed system. 

Architecture is neither strategy nor business or operating model... even though it can be employed to those purposes and it is impacted by them. 

What the description consists of is a different matter. Structure, behaviour, information to begin with. 
In any case, an architecture has many views describing the "architectures" as seen by each and every stakeholder. 

We need a framework that links all the above in one integrated and navigable whole to help us model EA and reach consistent results that help us construct, use... the system. Until then, architecture remains a chat topic because its various outcomes cannot be used to construct, repair and further develop a system. 

That architecture needs a development process is another matter, related though. The process has to be specific enough to consider the description parts.
The architecture development process needs governance which is usually ensured by an Architect leading a team. 

Architecture constitutes a discipline as well.
In our definitions, we have to make a distinction though between the architecture team, architecture discipline, architecture views... and the architecture (description) itself. Otherwise we confuse ourselves.

In my book I explored architecture as the anatomy and physiology of the enterprise, which disciplines explored for a long time the ways to describe the human body from various angles. The anatomy describes the structure of the body. The physiology describes the behaviour. 
A body can be described in views showing the skeleton, the internal organs, the body parts, the nervous system and also the digestive process, the breathing process etc.
This approach is embedded in a method called GODS-FFLV.

Using GODS_FFLV we can depict a system in a consistent and similar manner to anatomy and physiology in views showing the structure (as the organs or parts of the body), the processes (like breathing...), the technology blueprints  such as networks, servers, printers... (similar to the nervous, circulatory systems)...
When put these artefacts together in the framework, the outcome would be the integrated architecture of the system. This is the EA for an enterprise. Without such an approach the overall result will be disjoint, not integrated and non-navigable. The result would not be EA.


| Leave a comment

Adrian, your points are well-taken and I believe your premise is right on. I applaud your comment that we need to make distinctions in our definitions. But, to some degree you are part of the problem.
Other disciplines establish definitions and taxonomies via international standards. Standard definitions of architecture do exist, but architecture practitioners--and bloggers--don't want to adhere and advocate. ["Standard" does not mean "framework." Standards should be the "jumping off" point for frameworks. Otherwise, debate will perpetuate.] I almost believe that some bloggers--much beyond just yourself--truly wish to perpetuate the debate because it perpetuates their readership and the number of books they can sell.
I look at other disciplines, like project management, and can directly relate their maturity progress to their establishment and acceptance of such standards. The fact that standards in architecture are not adhered to suggests to me that they may be faulty (or the practitioners may be faulty). If we don't like the standards then leaders should emerge to call for a standards convention to rewrite and establish a larger body of standards. In fact, this is what I think you and other bloggers should be advocating. In the end though I am reminded of the colloquial name for a group of architects ... an "argument."


While I don't think this true in a broader sense, I do agree in the context of EA (and in fact IT).

I don't think it true that we not agree on what architecture is. Architecture is a fairly well defined discipline in the building industry. I trained as an Architect. It is fairly well understood what it means.

I do think it true that the IT industry has a poor understanding of the function EA. This is because the term is anachronistic, and does equate to the "Architect" in building (equating more to City/Town Planner). By anachronistic I mean it was coined in a very different era of IT - when there was typically only a single system, often a single language, etc - as if there was a single castle (not a city). I would also suggest Solution Architect's - who do equate more closely to the role of the Architect in building - are not clear on their role. This is because many are by background SW engineers, they think SA is really just SW engineering. Like a carpenter (electrician, bricklayer etc.) thinking Architecture is about is about carpentry.

In the this context I would suggestion the description provided in the item is an example of the flaw i.e. Architecture is not systems per se, though systems are encompassed. We would be better to abandon the term EA - and instead of the:
- E word say: "business", "product", "process", "system", "software", "services", "assets" etc.
- A word say: "design", "planning", "asset management", "governance", etc.

If we were really smart we would look at mature industry i.e. building and use that as a reference model and relate our concept to that - so we would understand our equivalents (see http://ea-in-anz.blogspot.co.nz/2007/09/ea-and-analogies-with-built-environment.html).

I agree in many respects.
But since EA is so immature, it is hard to get an agreement on its definition, not to mention standards.
In any case, an EA framework could be adopted as an EA standard.
In fact TOGAF has become a de facto standard if not de jure. That does not mean it is any good. It was just pushed hard.

Right. But no matter how we call it, it would still be the description of the enterprise.

Well, the A word for Architecture could be replaced with "blueprint"...
The E word, Enterprise has the advantage of including more than business concerns, for instance technology, when compared to the term"Business".

Overall I thing the naming is all right as long as it's not hijacked by IT.

Leave a comment

Adrian Grigoriu blogs about everything relating to enterprise and business architecture, SOA, frameworks, design, planning, execution, organization and related issues.

Adrian Grigoriu

Adrian is an executive consultant in enterprise architecture, former head of enterprise architecture at Ofcom, the spectrum and broadcasting U.K. regulatory agency and chief architect at TM Forum, an organization providing a reference integrated business architecture framework, best practices and standards for the telecommunications and digital media industries. He also was a high technology, enterprise architecture and strategy senior manager at Accenture and Vodafone, and a principal consultant and lead architect at Qantas, Logica, Lucent Bell Labs and Nokia. He is the author of two books on enterprise architecture development available on Kindle and published articles with BPTrends, the Microsoft Architecture Journal and the EI magazine. Shortlisted by Computer Weekly for the IT Industry blogger of the year 2011.

Recently Commented On

Monthly Archives