Over the years, I’ve written several posts about IT architecture. Whilst it seems that there is an increasing trend to call experienced IT folks “architects”, one of my core beliefs is that Enterprise Architecture is not the same as “architecting” IT at enterprise scale. Yes, creating an IT architecture that will scale to support a global organisation with thousands of users is “enterprise scale” – but it’s not Enterprise Architecture.

So what is Enterprise Architecture?

Like so many things in life, an illustration can really help describe a point. And, a few years ago, I came across an excellent Enterprise Architecture diagram from Dave Clark and Sophie Marshall. You can see it as the featured image at the top of this post and one of the reasons I like it so much is that it’s clear that the technology is only one of several factors in a whole stack of considerations.

I adapted it (under Creative Commons) but the basic premise of the diagram remained the same – step back from the problem and understand the organisation to consider its needs and requirements. We need to know what is needed before we can can consider solutions! Then, we should ask what good looks like. Don’t just dive in with technology.

Let’s take each layer in turn… and you’ll see that, right away, I added another layer at the top.

Purpose

The purpose is about why an organisation exists. It should be straightforward to answer but is hopefully more than “to deliver value to our shareholders”. A Council may exist to provide services (statutory and otherwise) to citizens. A retailer may exist to (make money and) provide the best selection of fashionable clothing at affordable prices. It’s entirely logical that the organisation’s culture will be strongly linked to its business motivations.

Many organisations will give an indication of their purpose on their website, or in their company report. For example, the IKEA vision, values and business idea sets out the organisation’s purpose in the form of:

• A vision: “To create a better everyday life for the many people”; and
• A business idea: “to offer a wide range of well-designed, functional home furnishing products at prices so low that as many people as possible will be able to afford them.”

Strategy

Strategy supports purpose by providing business ambition and goals – a direction in which to head. Storytelling and visualisation are techniques that can be used to communicate the strategy so that it’s well understood by everyone in the organisation. They can also help others who need to work with them (for example business partners). A useful tool for defining business strategy is the Business Model Canvas, based on the book by Alexander Osterwalder and Yves Pigneur.

Looking briefly at visualisation, Scott Berinato (@ScottBerinato)’s 2016 article for Harvard Business Review on Visualizations [sic] That Really Work stresses the need to understand the message you want to convey before you get down into the weeds. This blog post is a case in point – I want to show that Enterprise Architecture is much more than just technology. And I found a good visualisation to illustrate my point.

As for storytelling, I’ve seen some fascinating presentations over the years on how to tell a good story to bring a presentation to life. One of the most memorable was at a Microsoft MVP Event in 2017. Tony Wells used this example of how we tell stories to children – and how we (too) often communicate at work:

How not to tell a story! Tony Wells from @ResourceiT_Ltd reminds us that storytelling is a learnt skill, which we somehow seem to forget at work! #CinderellaInBullets #MVPBuzz pic.twitter.com/UHQzr6w1SB

— Mark Wilson (@markwilsonit) November 30, 2017

(I’m still practicing my storytelling technique, but Hubspot also has what it calls The Ultimate Guide to Storytelling.)

What, Who and How

What we do is a description of the products and services that the organisation offers – the business’ capabilities. These may be the value propositions in the Business Model Canvas but I would suggest they are a little more detailed. Strength/Weakness/Opportunity/Threat (SWOT) analysis can be a useful tool here too for identifying what could be done, though the emphasis is probably more on what is currently done, for now.

Who we do it for is about the consumers of the organisation’s products and services – understanding who the “users” are. Tools might include stakeholder maps and matrices, empathy maps, personas.

How it’s done is about understanding the methods and processes that deliver “the what” to “the who”. Journey maps, process flow diagrams, storyboards and SWOT analysis can all help.

Who does it is about the people, where they are located, and how the organisation is structured. In a world of remote and hybrid working it’s even more relevant to understand the (human) network and how it works.

Software, data and technology

Only after we’ve understood “the Business layers” (purpose, strategy and the what, who and how) can we move onto the IT. And that IT is more than just infrastructure:

• The data models that support this. (There may a discussion to be had there about data, information, knowledge and wisdom but that’s a topic in itself.)
• The software applications that are used to access that data.
• And the underlying technology infrastructure.

Why is this important?

For many years, I was part of and then managed a team of people who were labelled “Enterprise Architects”. During that time, I argued that the term was aspirational and that most of the work we did was Solution Architecture. Maybe that was splitting hairs but we rarely got the chance to drive strategy, or to get involved in designing the organisational structure. Whilst we were experienced at IT, we still operated at the lower levels in the stack: business requirements driving software, data and technology decisions. We wanted to become trusted advisors, but for the most part, the work we performed for our clients was transactional.

My colleague Ben Curtis (/in/BenCurti5) has an excellent analogy built around perception and perspective. I hope he won’t mind me borrowing it:

• Perception is about what meets the eye. Imagine you’re walking through a forest and come across a single tree. Your first impression of that tree – its size, shape, colour, and surroundings – is your perception.
• Perspective is seeing the Forest and the Trees. Now, let’s say you climb to the top of a hill and look down at the entire forest. Suddenly, you see how all the trees are connected, how the sunlight filters through the leaves, and how animals move through the undergrowth. This bigger view – the perspective – gives you a deeper understanding of the forest as a whole.

Whilst this can be used to show the difference between an individual system and the complete view of an IT environment, I’d suggest that its also about how the IT environment is part of something much larger – an organisation of people and processes, supported by technology, that exists with a purpose and a strategy to make it happen. And that, is the Enterprise Architecture.

Related posts

Here are some posts I’ve written previously on IT architecture. I think this is the first time I’ve properly outlined what Enterprise Architecture means though:

• What is IT architecture?
• Developing IT architecture skills
• The symbiotic relationship between engineering and architecture

Featured image: The Enterprise Architecture Stack, by Dave Clark and Sophie Marshall [source: Dave Clark on LinkedIn]