Worst Practice in EA - And how we can fix it

In Shakespeare’s play Hamlet, one of the officers, Marcellus, says: "Something is rotten in the state of Denmark". He’s just seen the ghost of Hamlet’s father, the late king of Denmark, so he knows that there is something wrong! As enterprise architects we talk a lot about “best practice”, and we are also prone-to-moan about EA when things aren’t going right. The aim of TOGAF is to document best practice in EA: “TOGAF provides a best practice framework for adding value, and enables the organization to build workable and economic solutions which address their business issues and needs”[i].

But there are some EA customs that are certainly far from best practice. What is worst practice in EA? And how can we fix it? Here we list six habits that are commonly found in EA which prevent it from achieving its full potential or which are damaging to EA as a profession! (I should point out that this is my own list, borne on personal experience.)

• Regarding EA as an IT discipline.
• Producing architectures that are too fixed, rigid, or difficult to change
• Seeing value only with delivery of a new architectural state.
• Not have a holistic or systemic perspective
• Accepting a pre-defined framework as the start point.
• Not thinking as an architect!

Let’s examine each of these in turn. I’ll start with number six and work my way up to the worst of the worst EA practice.

6. Regarding EA as an IT discipline.

There is a long-held view that EA emerged originally as an IT discipline. EA was certainly adopted at an early stage in its evolution by the IT world, and EA teams are still widely situated in the IT part of the organizational structure... but that doesn’t mean that EA is an IT discipline.

Certainly EA applies as much to IT building blocks as it does to business, organizational or environmental components. But restricting EA to IT and IT alone puts its practitioners into a straitjacket that prevents architects from doing their job effectively or achieving the potential outcomes that EA promises.

It’s a bit like saying you are going to landscape a garden, but stopping when you have shaped the terrain without sowing any plants, shrubs or trees. Or inviting your friends around for a meal and presenting them with the plates and cutlery, but no food!

How can we fix this? We have to educate anyone that still believes this myth. We have to explain why EA is so much more than mere IT. And we have to work towards positioning enterprise architects in a place in the organization structure where they can apply EA to every relevant component or building block.

5. Producing architectures that are too fixed, rigid, or difficult to change

The next big issue that we need to change is to stop architects producing architectures that are too fixed and rigid, and that are therefore very difficult to change.

Good EA produces some components that are long-lasting and stable, while others are very flexible and adaptable. Compare it with building architecture: the site of a building has greater longevity than the walls, windows or doors that are built there; while the services, use of space and stuff that we put in rooms all change at a faster pace[ii].

There are some future needs that we can anticipate, but many more that we can’t! And increasingly EA needs to produce architectures that are responsive to unexpected, and even un-anticipatable, circumstances. Think about the financial institutions that responded best to the financial crisis of 2008 because they had more adaptable enterprise architectures. Or high-street booksellers that adapted to meet the onslaught of the Amazon.

So it’s very important to consider the different pace at which EA components change. We can fix this rigidity by understanding which EA components need to be long-lasting and stable, and which are characterised by their ability to respond to emerging requirements. By separating dynamic and stable elements we can produce enterprise architectures that are easier to change and quicker to adapt.

4. Seeing value only with delivery of a new architectural state.

Now we come to a pervasive myth – that EA only produces value with the final delivery of a new architectural state. This practice forces EA into a bad place – where architects are expected to produce short-term miracles that cure deeply embedded, long-term problems. Architectural change generally takes longer than short-term maintenance, fixes and work-arounds! So the poor architecture team struggle to prove their value and worth, because the end-results only happen after two, three, or more, years.

The simple cure is to recognize that EA delivers value throughout the strategy-execution cycle. Good EA starts by delivering ideas, strategies, visions and plans, producing value through the originality, creativity, and possibilities it generates. EA principles, standards and blueprints produce value by defining the fundamentals, morals and ethics that the organization follows. EA then examines the feasibility of each architectural option and the capabilities that are produced or improved – which is the value of knowing the right things to do, the value of appropriate effort, and the best use of resources. Then, and only then, EA makes changes through roadmaps and governance, which is the value of seeing things through to completion[iii].

3. Not have a holistic or systemic perspective

Architecture is the art and science of seeing the big picture – of understanding how everything fits together. Strong capabilities rely on effective collaboration between a diverse and complex set of components. When EA doesn’t consider how everything fits together – in a holistic or systemic way – there is a strong chance that it will miss the vital ingredient.

We often hear about high profile, large and complex projects that fail. In most cases, the reason for failure is that one (or more) vital factor has been overlooked. A recently abandoned National Health Service patient record system in the UK – which might have been the world's largest civilian computer system - cost around £10bn[iv]. The project was plagued by “systemic failures”, including changing specifications and an unclear scope – which are exactly the type of problem that can be prevented with a clear, holistic or systemic EA perspective.

2. Accepting a pre-defined framework as the start point.

The EA management technique that provides clear, systemic, holistic overview of transformation change is the use of architecture frameworks. Which brings us to number 2 in our countdown of worst practice... many EA teams use a pre-defined architecture framework as their foundation for architectural work, because they don’t know how the best ways to tailor these frameworks to meet their precise needs!

The most popular architecture frameworks are The Open Group Architecture Framework, or TOGAF, and the Zachman Framework. But more than 300 architecture frameworks have been proposed by vendors, consultants and authors over the years[v]. The first problem is that none of these frameworks was developed for the exact needs of your enterprise. The second problem is that some of these “frameworks” are not what they appear to be: for example, the Zachman Framework is more accurately an ontology or schema. And finally – most pre-defined frameworks cover too many architectural dimensions at once.

So what is the alternative? Instead of starting with a framework, start by deciding which of the fundamental EA factors you need to include in your engagements; for example, the most important factor includes the scope, domains or categories covered by EA. Then decide what elements are required within that factor; for example, typical high level domains are the four included in TOGAF -business, data, application and technology; the business domain might be further categorized into products, processes, events and rules. Finally, decide how this factor needs to be combined with other factors to create a set of practical frameworks that genuinely help you drive architectural change. For example, you might combine the categorized domains with evolution to show how architecture components will change over time.

1. Not thinking as an architect!

And at number one, the most rotten of the worst EA practice, is not thinking as an architect. This occurs when people have architect in their job title but actually behave as if they are something else, such as an IT developer, software engineer, or business analyst.

What does it take to think as an architect? Most importantly the architect must interpret the concerns of stakeholders in terms of EA components and their configuration. For example, you may need to explain why the current architecture prevents the business from doing things it wants to do. You might explain how capabilities are constrained, rather than enabled, by a particular architectural state or enterprise pattern. Or you show how a different configuration or new components remove these constraints and enable the required strategies or capabilities. If you don’t translate requirements and concerns into architectural explanations then you are not thinking like an architect.

In other situations, “architects” talk about specific solutions, but not about the required architectural principles, patterns or paradigms. Or “architects” provide a single, short-term fix, instead of giving a range of long-term architectural options, with alternative roadmaps that deliver short and medium term value following an overall strategic vector. Or “architects” describe the building blocks, but don’t explain the contextual patterns that they fit within.

In short, to think like an architect requires the use of EA techniques, such as fundamental factors, frameworks, patterns, principles, paradigms, layers, deconstruction, and separation of concerns, rather than applying a general, business, management or IT approach.

Final Thoughts

If you search on Enterprise Architecture Best Practice or EA Best Practice you will find plenty of articles, but you will mainly find very general, rather than practical, advice. You will be told to be pragmatic, to make sure that you have business sponsorship, or present a strong business case. Sometimes you will be given advice that is only true in some cases: for example, to complete the future state before the current state, or to start with an EA maturity assessment.

I hope that this list of worst practice gives you more tangible, practical and meaningful challenges to bring greater success to your EA work! There is something rotten with EA practice, but it is not too hard to fix.