I want an architect.....

I seem to have found myself with some spare land, so I guess I need an architect?

Twenty years ago, I debated with a colleague why SNA was always going to be the protocol of choice and TCP/IP would never take off in business. He said I was wrong. He also pointed out that everyone seemed to want to call themselves an architect. Given his win on the first, it’s highly likely that he was right on the second. He was a doctor of genetics or something and one of the most intelligent people I have had the pleasure to work with.

If the architect label was noticed as a problem then, roll forward twenty years.

Having an architect for every small corner of the ecosystem is distracting from what architects are meant to do and have the skills to do, which is to start from strategic motivation and not to start from a solution with a problem.

We must reassure ourselves that it is OK to be called an architect and not necessarily have a specialism; we have one, it’s the canvas to analyse the strategic need and work through to a portfolio of capabilities and solutions. But as I will point out in this paper, neither must architects lose sight of the technology.

When we go looking for ‘an architect’, it will do us all a kindness to think what the real core outcome is of that role.

Architecture without architects[1]

Architecture history is only concerned with a small period and a few cultures. Chroniclers present us with predominantly formal recognisable architectures. It is riddled with pomposity and a who’s who of architects that commemorated power and wealth. It has been preoccupied with noble architecture for architecture nobility and informed the evolution of style as historic forms were copied for the next generation.

Enterprise architecture, the art of managing and visualising all the components, and relationships between components, and of components and their relationship across an enterprise, and in the world of Web 3.0 between the enterprises, has an element of this in it. Architecture is only architecture when it has architects.

While the world of buildings and structures is coming to terms with architecture without architects it is something that the world of business and technology is facing. The creation of architecture without architects, the vernacular, spontaneous, indigenous, rural is to be recognised and the process of creation of any structure to serve a need is now labeled architecture. Good or bad architecture is judged by the profession and the people with the need and the people with the need get to call the shots.

With the democratisation of power and knowledge in the corporation, why does everyone need architects?

An age-old distraction

I want an architect…. No, really, I WANT an architect.

Maybe one day everyone will be architects (that seems the trend) and they will solve all problems; won’t that make resourcing, recruiting and career development easy.

This is not a new protest. A learned colleague of mine at EDS twenty years ago wrote in frustration about the constant bland requests for architects from project teams, usually because a project is in trouble. I wish I still had that paper. I wish I could remember his name!

There’s nothing wrong with needing an architect, and they can of course help projects in trouble. But is that the best use of sometimes scarce resource. At EDS the request represented a reaction to an issue and lack of thought about the real problem, the questions to be asked, the stories to be told and the outcomes and ambition.

It’s still the case today and the broadening of the architect role is making the situation worse. Everyone is an architect…. Cloud, IoT, CRM, Data Centre, Banking etc.

I recently saw a job posting for a chief enterprise architect and the first skill was experience of deploying cloud solutions. Cloud… a solution to a need. The world has changed, and it is a key skill, but if our chief architect is concerned with deploying the cloud, who does the architecture.

This ultimately threatens the ‘profession’; the profession here is the jumble of approaches and frameworks and objectives that as usual in the technology space will always be moved forward by marketeers faster than engineers. After all, there is no RIBA Part 1, 2 and 3.

It may be time for the real architects to stop calling themselves architects. Will the real architect stand up; “yes, hello, I prefer to call it business operating model design, architecture is so 1990s”.

The bigger risk is that it brings client disappointment and poor value for money; no-one comes out looking great.

Architecture is an unhelpful abstraction

It seems that I think architecture is a bit special. This is where I get my flame-retardant suit. Yes, it is.

Many roles within the IT world are commodities. I need a project manager, yes it must be a good one, I’d prefer it if they knew something about my context, but it is still a project manager.

I think the same of developers (slightly less of a commodity as they do come in different shapes…. some create, some assemble, they all have a different view on REST guidelines, but we all have a view on the right way to do what we do). Business analysts, nice people…. commodities.

Architect is an unhelpful abstraction for a vast range of skills and capability.

• Generalists or specialist, although as I point out to colleagues being a generalist is a specialist as it means your art is in problem-solving without starting from a solution and that is a valuable thing.
• Technology domain and platform specialisms; the rise of the Cloud Architect i.e. someone that knows about Azure and AWS, and maybe the strategic case for them.
• Architecture domains e.g. business, information, software and technology, and the enterprise specialist that looks at keeping the four domains aligned.
• Upstream architects (working with motivation), downstream architects (working with delivery…. They can relate to Java developers), and those that can bridge the whole thing.
• Architects may have a dramatically different focus in the lifecycle; on enabling strategic decisions, identifying the need for change, identifying what that change may be, building the change portfolio, change inception and how that change may be delivered, and solution realisation through solution architecture, design and build support.
• Framework and process gurus; architects that can use these tools to break down a problem into the why, what, how and with what and create a compelling story. This may be to the executive team to qualify a strategy, or it could be to a product manager to build new capability, or it could be to purely create the context for technology delivery.
• Some architects start with a vision and work backwards. Some work from the current state and forwards. Vision first to meet ambition, current state first to deal with a performance problem.

When you say you want an architect, you want all this do you, and someone that knows Java, SpringBoot, is PAL Certified, AWS Certified, Azure, and GCP certified……

Back to the Chief Enterprise Cloud Architect problem

From my ivory tower, it seems I have a problem with architecture specialisms; I do, with the need to tag it with architect, there’s no need.

In the main, these people are great at the platforms they work with and are people I have deep respect for. They can think through problems and provide solutions about stuff that seems totally incomprehensible. Business people love them as they can take a given solution and leverage it and move the business forward rapidly. That’s great. But what about when we don’t know what the solution is going to be, or our default isn’t fit for purpose for a new business scenario, or what the options are, or what capability is needed, how that forms part of a roadmap and why on earth we need to change in the first place.

And in case you think I am all style and no substance, fur coat and no knickers, there has never been a greater need for architects to need to know about technology to remain relevant to delivery; to avoid the ivory tower purists that create commandments from on high but have no interest in seeing if deployment aligns with ambition. The deployment must align with ambition.

When is architecture architecture?

For architecture to be architecture it must start with motivation and the process of why, what, how and with what. And through that iterate around options and choice until we can see what physical resources and assets need to be deployed (the “with what”) to enable the “what” that has been defined as capability necessary to meet strategic goals.

What do I mean by architecture then, why does it appear so complex? Let’s get all Melvin Bragg for a second.

To the Romans, it was the art and science of designing something with structure and function with durability, utility, and beauty. Poetic description aside we know that sustainability, quality, cost, and compliance are also factors, and I bet the Roman’s considered them too.

Modern architecture believes that successful architecture is not a personal, philosophical, or aesthetic pursuit by individualists; rather it must consider everyday needs of people and use technology to create liveable environments, with the design process being informed by studies of behavioural, environmental, and social sciences (or for a system the customer persona, event, need, journey and experience).

The way we view business and their technology systems is no different. Any architecture describes:

• The structure of a system (a complex arrangement of components) and the capabilities of those components
•  How they interact, how they each behave and perform and how those interactions behave and perform
• The experience that comes with interacting with that system
• How it interacts with its environment and other systems around it
• The rules that inform its operation
• How it may endure and evolve.
• The assets and resources that need to be deployed to build it and what skills that drives.
• And ultimately how all this aligns with our core needs.

The game is changing from what the Romans said; Enterprises are constantly changing their mission and operating model, in a rapidly changing environment, they behave and evolve unpredictably. Cities will struggle if they don’t have a city plan, enterprises will struggle much harder.

Architects love working with this complexity and constant ambiguity. Is this the sort of architect you want?

Are your architects busy doing the right thing?

Many years ago, I spent some time with the architecture function of one of the world’s largest companies. The CIO knew they were busy but wasn’t sure why. I was helping businesses improve their architecture capability at the time and this was a classic case of lacking purpose. And from purpose, we can consider people, process, product, partnerships, performance…

To define the outputs (and supporting process and products) that enable architecture to tell the right stories, the purpose must be clear. Where is the focus?

Successfully delivery of existing technologies into new scenarios?

• Transitioning the existing technology to new platforms for either functional or technology management reasons?
• Creating new capability within the business?
• Providing leadership expertise to ensure programmes keep on track?
• Laying the tracks for strategic capability across the enterprise and its business divisions?
• Facilitating and creating the overarching business model for the organisation as a whole and, typically, diversified businesses within it?
• Defining the long-term roadmap based on structured analysis of the need for business change?
•  Informing the strategic business decision process with a clear view of opportunity, risk, and need?

These are very different things.

The assumption is that outside of large transformation the role of architecture generally adds context to simple change e.g. it is taking something that is understood and defining an approach for a known business need into a similar business scenario.

But in a transformative role and where architecture is moving upstream in the change lifecycle, there is a much greater ask of architecture in terms of leadership, stakeholder management, problem-solving and the ability to deal with iteration and ambiguity.

The caveat

I’ve tested this thought process with several peers and it seems to make sense. However, I do wonder if this is all predicated on an outdated notion that our chief sponsors want us to continue with the why, what, how, with what journey.

I cannot see how that journey can become irrelevant, but the execution needs to change.

I was asked recently about my ability to deep dive on machine learning. I will admit that in an engineering context I would be found wanting. My push back was that the journey to ML is going to pass through why, what, how and with what (WWHWW) and surely by the time we are deep diving to leverage and extend we have built up a centre of competency. And this is where the thinking breaks down a little in that while we are traversing the WWHWW path, we are also probably delivering e.g. an ML MVP. But we are still thinking and refining the roadmap and guardrails for this capability as we extend it. The key is to start simple and evolve in order to avoid locking in bad decisions at the start due to the lack of thinking time.

This calls back to the notion that architects more than ever need to be able to engage with delivery; Amazon is boxing up books for me as I type.

What’s the first thing we need to do when someone “wants an architect”

Consultancies tend to have an answer here as they know they need to understand the client and their problem and match resource to it (in a way that makes money). If you need an architect there is a good chance you are looking to address a problem of thinking and not logistics and engineering; I need an architect to validate my target operating model as I’m not sure my programme is delivering against it.

Know your client, understand their problem, their real need, find a great resource to work with them.

Clients, don’t be lazy. Recruiters, don’t be lazy. Architects, get your value proposition clear.

And recruiters if you can get this right you will be rewarded for having an amazing relationship with your client, they will know that you understand and that you can help them understand.

[1] With thanks to the Exhibition of Architecture without Architects at the NYC MoMA in 1964