Pizza as a model?

When it comes to describing how technology works, a picture is most certainly worth a thousand words. Whilst they’re not likely to win any prestigious art prizes they can sometimes be beautiful (in their own way) and help turn something complex into something understandable.

When it comes to describing how technology enables an Enterprise to work, a model is worth a thousand pictures.

That’s quite the claim… and to be honest, I can’t guarantee that one model is worth one million words, it’ll all depend on how you use it and what you use it for.

That said, they’re definitely useful and many organisations would benefit from having one.

What is an architectural model?

Models serve as a means to represent, analyse, and communicate the various aspects of an Enterprises’ architecture.

Every element that can be used to describe the business is created and stored centrally. That includes stakeholders, outcomes, capabilities, business processes and of course applications, software and infrastructure.

We also create the relationships between those elements, the things that connect them together. For example, the Content Management application would likely enable the “Update web content” business process.

Finally, we can create views onto the model that help describe it visually.

Why is an architectural model handy?

• Re-usability: Every element is stored only once and will be re-used across multiple diagrams. We don’t have to start from scratch each time.
• Meta-Info: Every element can have information stored with it that describes it. It may contain things like links to further documentation, review dates etc.
• Controlled: The model can be stored in a source code repository alongside application code. Secure and roll-backable!
• Accessibility: The model can be published on the web so that everyone in the business (who needs to) can access it.
• Analysis: Analysis can be done on the model, asking questions like: “if I change this, what else might be affected” or “where does my personally identifiable information sit?”
• Consistency: The model notation will drive consistency and ensure everyone’s “speaking the same language”
• Cross-Functional Collaboration:?Isolated groups sitting in an ivory tower cascading PowerPoints is sooo last decade, everyone can (and should) contribute to an architectural model.

What does an architectural model look like?

It’ll depend on the notation used, but a common one is Archimate (which is a standard developed by The Open Group). This models an organisation across 5 layers:

Motivation?— Why we do stuff

Strategy?— Our high level objectives and direction

Business?— How we operate

Application?— How our applications work

Technology?— How our infrastructure, networks and software works

Each of these layers has its own elements that help describe it and they can be combined together to enable people from the whole business to drill down or up as far as they are comfortable.

For example, you might want to drill down if you’d like to understand how the business does a particular activity (and then on to the applications that support it). Equally, you might want to drill up if you’re working on a particular application and want to know what benefits a certain feature is hoped to realise.

Enough of the blah, blah, blah — show me the model

To try and bring this to life, I wanted to use an example that’s close to my heart. I’ve dabbled before with bringing together food and tech in articles like?Pizza as a Service 2.0?and?IoP — The Internet of Potatoes?so will continue that theme…

So without further ado, here’s a Pizza as a Model…

Motivation & Strategy

This models the reason for change and what capabilities will be required to realise it.

The modelling principles are the same whether it be a Chief Marketing Officer wanting to increase market share by implementing a new sales channel or a hungry me who wants to get full on pizza.

The basic story here is that there is a stakeholder (me), who is driven by some need (hunger) and there are a couple of truths that will influence how we go about solving that to achieve the goal of ordering a pizza for delivery. The desired end result, the outcome, gives rise to the three requirements across the bottom of the motivation layer.

The requirements help us identify the capabilities we’re going to need to fulfill the motivation. In this case, we’ll need “Pizza Selling”, “Pizza Delivery” and “Pizza Consumption” capabilities. In a more business-y environment, these would be things like “Product Management”, “Distribution and Logistics” etc.

This layer would typically be put together by Product folks (& architects!)

Business

Now we know why we want some change and what capabilities are needed to enable it, we can start to think about how we organise ourselves to make it happen.

The business layer describes how the organisation actually does things. Firstly, what roles are needed, in this example, it’s all about chefs and delivery drivers, but in a real World example, this would be our customer service colleagues, our logistics peeps and our marketeers etc.

We also usually have a set of “Business Services”. These are quite generic, long-lasting and will hopefully be recognisable by most people in the organisation. They’re the services our business provides.

The key bit here is the process part across the bottom — that’s the multi-step business process required to power those business services and achieve the goals.

This is where we start making meaningful choices — what do our processes look like?, who’s involved with each step? what data artifacts do they require?

This layer would typically be put together by Analysis folks (& architects!)

Application

Now we know what we want to do and how we plan to do it, so we can start to think about the technology that will enable it.

Similarly to the business layer, there are a bunch of generic application services, that should be recognisable to (at least) the tech teams. This provides a nice layer of abstraction — even though we may change the underlying applications, the services they provide to the business layer are likely to stay the same.

The start of the tech choices come with the application components that underpin the services.

In this example, we’ve chosen things like a website for ordering and a moped with sat nav for delivering, but in a real example, these would be things like your Warehouse Management System (WMS), Content Management System (CMS), Product Information Management System (PIM), Order Management System (OMS) and other three letter acronyms (well, technically initialisms for the pedants out there!).

The various functions of these applications are also shown — so we know what they need to do and what services they provide…

This layer would typically be put together by Engineering folks (& architects!)

Technology

Let’s delve deeper….right down into the murky depths of the technology itself.

Although there’s another abstraction of technology services, this layer gets into the nitty gritty of what tech we’re using and how it’s put together. you can go right down to the specifics of hardware and software.

In this example, this specifies the type of fridge we use to store the pizza ingredients, what kind of scooter is used by the delivery driver and even what streaming services I’ll watch whilst eating it. In a real use case, we’d be talking about servers, networks, operating systems, cloud services etc here.

This layer would typically be put together by Platform Engineering folks (& architects!)

Putting it all together — Pizza as a Model 1.0

Although it’s a bit(!) of a contrived example, hopefully it helps demonstrate the potential power of a well put together model of your business.

As with many things, the effort you put in will directly relate to the quality of what you can take out of it.

But with the right collaboration by people from across the organisation, you can create a living representation of the business and the tech that powers it — helping decision making, understanding, governance and productivity.