The biggest problem with your architecture is that you have an architect

rawpixel-com-559744-unsplash.jpg

I’m often stunned when I engage in dialogue with people that work in organizations that have a job title with the word architect in it. The conversation usually goes:

“So tell me about your <subject area> architecture”

The reply I tend to get is something along the lines of:

“Well, you’d have to talk to the <subject area> architect to find that out, I don’t know.”

I immediately picture a tall Ivory tower, a mad-man designing unrealistic blueprints, drinking coffee with top-level management making crazy decisions that are impossible to implement. Inevitably, people end up disappointed, feeling they aren’t getting anywhere and can’t figure out for the life of them why everything is in such chaos. Buildings catch fire, people run around screaming and airplanes fall out of the sky!

Well … All jokes and dramatization aside, I can’t for the life of me fathom the idea that the way an entire organization is organizing the way they work can be the sole responsibility of a single, or a small team, of people. If LEAN has tough us anything, it’s that business is everybody’s responsibility. And what can be more business than the way we do business? The fact is that architecture is a big part of every business. Let me make my case.

I have always found it useful to approach the subject using different levels of abstraction. Let’s take a quick dive into different levels of architecture

Photo by rawpixel.com on Unsplash

Services

These are the end-to-end, day-to-day, value streams your business uses to produce value for a customer, and of course, capture a piece of that value for themselves to make a profit. When discussing services, you are usually talking to people with a business background rather than a software development background.

The realm of service design is vast, and there is no way we can cover that in a single blog post. It touches on customer journeys, user experiences, cycle times, response rates and other interesting things. But what is important to keep in mind in the context of the article is that every service consists of a number of interacting processes and customer touch points. Processes are the building blocks of services.

Services are (usually) totally unique to a business. Services are where businesses compete with each other since services are how customers perceive your business. Services need architecture and design to meet customer expectations.

Photo by STIL on Unsplash

Photo by STIL on Unsplash

Processes

These are the cogs and gearboxes driving your business forward. Usually, you would do the good old process workshops, similar to value stream mapping workshops here. Processes describe how people work, what raw material they take in, such as forms, documents or even concrete. Processes also depend on tools and techniques used when the workers transform something into something, an application into a loan, concrete into a wall. Finally, a process document might describe what should be produced. For example, a loan application might not be completed unless a committee has met and approved the loan. A wall might need to meet some inspection standards. Processes need architecture and design, so they meet requirements.

Photo by Debby Hudson on Unsplash

Recipes

recipes describe how we make one thing by combining others. We can make the processes by combining patterns. We can make services by combining processes or solutions by combining patterns. Think of how you design a city. You might start by figuring out who the city will serve, then you work from there. You know that for every 1000 inhabitants aged 10–12 you might need 1 school and a sports club. You can calculate how many miles of roads and the number of lanes you need to connect different parts, police and fire stations are next. Using these recipes, we are able to design a myriad of towns, all looking different but providing the same quality infrastructure to their inhabitants. The same goes for processes, they all look different since the services they support shape them heavily.

Let us take another example when designing a website, you know that you need a bunch of servers serving up a web page, there might be some backend that does data processing and a database to persist a data. For a process, you might need that you at least need an inbox to receive the raw material, an area for processing (such as an office or a factory) and some means to hand off the products from the process. Another example of a recipe is that when you are designing a service you need to have an ingredient which is “case management” to handle when customers have problems with the service.

A recipe for a service implemented in different locations in the world will look the same to the end user, but you have different flavors. For banking you usually have different legal requirements, you have the local financial services authority, you have different cultures. This might result in the same brand, the same product, and the same service but totally different implementations of processes, solutions and so on.

Things made from recipes have more character. When you are talking about cupcakes you might have “mom’s good old muffins” but in business, recipes give your coffee that distinct flavor, or your services that special something that sets your business apart from others. Recipes are where you add the secret sauce! Everybody loves the secret sauce…

Photo by Adam Birkett on Unsplash

Patterns

Patterns are a bit easier to understand than recipes, recipes live in the area between patterns and processes in my mind. An area which is pinched between two rather large concepts and as such spills a bit over its adjacent borders.

Patterns, simply put, describe re-usable ways to solve re-occurring problems. For example. If you are working with data, you need to store it somewhere. You might store it in a database or you might store it in a file depending on requirements. If you need separation of concerns in a web site’s user interface, you might use model-view-controller pattern to structure your solution, or, if so required, HMVC, MVVM, MVP or PAC. There are many different patterns to solve the same problems.

Patterns also apply to the business side. One pattern we have to solve the re-occurring problem of faulty service is the customer support hotline. Another one is a frequently asked questions webpage. If you have a high-cost luxury item, such as a high-end luxury car, customers expect to be able to call a hotline, have a limo service pick them up and a replacement car of similar quality provided to them. So, there are different patterns that describe how we solve recurring problems.

A well-known example is when you design a service desk for your IT department, then you have a few patterns to choose from. You might have a local, central, virtual or follow the sun service desks. You might have it in-house, or outsourced, single level or multi-level. All of these are solutions to the single problem of providing customer service.

Solutions

A solution is an implementation of the pattern, how you realize the pattern in reality. It’s that special follow-the-sun, single level call center hotline you have for your luxury car customers to call when their luxury car breaks down. It’s the script your service representatives go through when they greet the customer, how they make sure the customer feels welcomed and well-taken care off, it might even include a section where they try to calm the customer, after all, that’s a very expensive car that just broke down.

A solution might be the full-stack JavaScript implementation of the model-view-controller website you have, which talks to a backend hosted in the cloud. A solution might be implemented using a Microsoft SQL server or an Oracle SQL server, each having their own specific set of benefits that might be more suitable to the organization, based on a mixture of the problem that needs solving, the know-how and capabilities existing within the business or its partners.

To conclude

When you think about it like this, you’ll realize that architecture permeates everything. It exists at different abstraction levels in different parts of your business. You might have architecture and design elements in your services, your infrastructure, your processes and even in your culture. The secret sauce you apply to your operations is, actually, architecture and design.

That’s why I feel confident when I state that architecture is everybody’s business, not just some “white-bearded wizard’s sitting in an Ivor tower”. Some people might agree with me and others won’t. I think this subject is that important that I’d like to invite you to have that conversation with us. Is architecture really everybody’s business? Let us know what you think.

I am a Management Consultant with a background in Enterprise and Solution Architecture. I’ve started a handfull of start-ups throughout my years. Learn more about what I do and why I do it at www.coremotif.com

Or just follow me on twitter @jon_gretar