EA for Dummys

What the hell an IT-Enterprise Architect is doing?

It’s always a challenge to explain to my family and friends what an IT-Architect is doing in his daily business. Even more tricky it’s about an IT-Enterprise Architect and the difference to an IT-Architect.
But even in the IT business it isn’t a matter of course. An IT mangager told me some years ago that he believed Enterprise Architecture was a bit Hocus-pocus.

The usual comparison

In making a better example I often compare the profession with the architecture in construction business.

Quelle Pixabay
Essentially the construction architect serves three parties:

• the client (who wants to have the house and is willing to pay for it)
• the developer (who is building the house and wants to be paid)
• the legal government (not all is allowed, there are some rules of course)

To be successfull he must have a lot of competences. He must know mostly all about the construction of the house. About the bricks, the tubes, statics etc. inclusive a lot of legal rules. That’s the core.
More than that he must understand the wishes of the client and have to bring it in a design that is accepted.
And here we are at the most important spot: It is mostly on him to find the right trade-offs. It’s obvious that the client want to pay as less for as much as possible.
The developer on the other hand wants to be paid fair (at minimum:-). And yes, some desires cannot be fulfilled because there is normally a land-use plan.
Let’s assume the success is defined in a way that all partners are happy but at least satisfied.

How the Architect can contribute in the confusion of the different interests?
He must be an expert in construction of course, but more than that he must:

• speak the languages of the stakeholders (to understand the interests)
• be neutral (to be accepted)
• creative and sometimes innovative (to find the good compromises)

Some of it can be learned with a while. E.g. the Architect is producing a lot of technical drawings. Why he is doing it?
He is documenting the architecture, of course. But he makes some more - he makes the design options explicit to the stakeholders, avoiding mistakes in understandings and ensure transparency in motivations of potential conflict partners.

There are two other aspects make an Architect to an Architect:

• Architects have a specific attitude to look on problems, they like to structure things

Quelle Pixabay

• An Architect must have fun to align the different interests, to explain solutions and be strict in following the compliance rules. With other words he must not only behave as an engineer but as a leader.

Coming back to IT

This in mind let’s talk about an Architect in IT now:

Some essentials are directly comparable. Generalized he serves

• the legislative (the client with the money, the sponsor)
• the executive (the party builds some IT’ish, could be an IT project orga)
• the judiciary (compliance is overall)

Instead concrete and tubes he’s working with other ‘bricks’. What ‘bricks’ exactly, depends on the level of abstraction in the IT business:

• A Software Architect is playing normally with:
  Software (what a surprise), means with concrete software development, user interfaces, software patterns, modules, classes, etc.
• An IT Architect deals with things like
  IT systems, networks, databases, clouds, security, performance etc.

Remark: The description isn’t precise and far away from any completeness. There are a lot of different domains in IT like infrastructure, applications, technolgy, data, governance etc. and so there are specialized Architecture roles for it.

To illustrate the different interests in IT see some viewpoints/scenarios in software development:

Scenario	Winner	Loser (Opponent)
Quick and Dirty	Developer, Sponsor	User
Some Extras and Decorations	Developer, User	Sponsor
Unrealizable Requirements	Sponsor, User	Developer

It can be seen that in different scenarios there are different winners and losers.

And the (IT-)Enterprise Architect?

All what was written above about the competence, the attitude and the behaviour is true for an Enterprise Architect as well because he is an Architect.
Focusing on the differences to the classical IT-Architect there are the usual ITish ‘bricks’ like servers, networks, software, databases and all of that, but there are some more due to the fact that the abstraction level, the context is the Enterprise now:

• Business Capabilities, Processes and Value Chains
• IT Landscapes (IT System portfolios, Inventories, Diagrams)
• Roadmaps, Initiatives, Projects
• Technology Standards (Reference models, IT Principles, EA Patterns)
• Information Models

Or continouing the comparising with the construction business - He isn’t dealing with buildings only but with cities and their specific challenges like urban and regional planning, urban design thinking and sustainable urban development.

In the Architecture community can be found tons of different detailed descriptions.
See e.g.
Wikipedia - Enterprise Architecture
TOGAF Standard V9.2 - Introduction
Gartner Glossary - Enterprise Architecture

In my practical experiences the tasks of an (IT-)Enterprise Architect coming from three main processes:

• Modelling and enforcement of policies and standards
  (that’s what is seen as the core: creation of pre-studies, blueprints, concepts, audit reports, funny landscape pictures and a lot of Excel lists and PowerPoint slides)
• Planning support of initiatives
  (supporting the translation of business strategies in executable IT roadmaps)
• Execution and governance support in initiatives
  (‘making the hands dirty’)

Value Streams and Use Cases

The Enterprise Architecture as a discipline isn’t as old as the traditional Architecture in construction. To meet the business expectations as evolving to an enabler of more profitable and sustainable business outcome was and still is a learning challenge.
From beginning bigger organisations had the need to align the IT portfolio management with the Enterprise business strategy.
In Business Architecture there is a concept of Value Streams to classify all tasks if they give some value according the business value proposition (see Business Model Canvas and Value Proposition Canvas)
Applied to the Enterprise Architects use cases I would identify three main value streams:

• Enable Change, Growth and Speed
• Ensure Compliance
• Reduce Complexity

The use cases per company differ and must developed individually. Some use cases with a wider coverage are:

To illustrate what typical questions an Enterprise Architect is driven by, some example use cases:

Example 1 - Application Portfolio Management

The last decade has shown that the most successful companies were those who know their customers best and were the quickest to convert this knowledge into sellable services and products.
The IT of the company has to do at least two things here: first, to automate a learning process of customer demands as much as possible, and second, to be able to support the changed business model in its implementation.
How the IT in the affected companies is prepared for it if the driven factors are uncertainty and time to market?

What could be a valid strategy to support a moving target and how to measure quality?

From software development of a single applications there are known techniques and structural patterns achieving exactly this. The quality of the software architecture will be measured e.g. by the ability to refactor. Another quality attribute is the degree of decoupling of the essential components. Supporting patterns are e.g. Domain Driven Design.
Valid key figures to measure the quality according the agility of a whole portfolio of applications could be similar: Identify the dependencies of the most important components in the application portfolio and find and apply decoupling patterns.

Such patterns, applicable to an application portfolio are e.g. the coverage in usage of MicroServices.
See Wikipedia - MicroServices

Example 2 - Enterprise Concepts

Add on to the first example there is a need to collect data to be able the customer demands and his behaviour. More than that the learning itself have to be automated. Modern technologies like Artifical Intelligence and Machine Learning is exactly about.
Legacy IT landscapes are very often have grown historically and the data are locked in silos.
A valid task for an (IT-)Enterprise Architect is to find concepts to unlock the data and combine data ingestion with intelligent integration concepts.

Such a concept applicable to the Enterprise could look like:

The basic idea is to combine two things:

• a concept to integrate and decouple systems, inclusive the usage of modern event streaming technologies
• a concept to collect data for further analytics

Conclusions

An Enterprise so a business organisation is a composite of a host of different moving parts. Holding the complexity under control and managing it could be a daunting task, unless you have the right approach. The good news is once can use Enterprise Architecture as the glue that holds the puzzle peaces together.
Adoption is a chance to bring order and structure to the business.

Remarkable:
No, Enterprise Architecture isn’t a silver bullet, but the benefits could be realisticly realized.
One of the most applicable understandings I had in the last years is to leave the ivory tower of pure abstraction and apply the same behaviour to the Enterprise Architecture itself as it’s expected to it’s subject.
This assumes e.g. to invest in learning to be up to date in the relevant disciplines of technology and business trends.