For twenty years or more we have heard the call “Get me an architect”, usually as the building is crumbling (metaphorically speaking). Or maybe the design never designed the 35th floor for Hans Gruber and John McClane to meet and to stage the brutal battle with Karl Vreski. It generally means something is going wrong. It also means someone does not really know why and what sort of person they really need. Sourcing architects of the street in this way can be unsatisfactory as the architect does not get the chance to ask the client direct “what do you need”. Café Associates can help resolve this and get the right resource in quickly.
Everyone is 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 is 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 that needs a problem. It is also a disabler for getting architects to do what they do best, which is solve problems at the start of the journey. Often the call comes when the project has started. This is so far away from the decisions that should provide the business with options on what to do next it is a very poor investment.
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, toolbox and experience to analyse the strategic need and work through options to a portfolio of capabilities, projects and solutions. It doesn’t stop there; they need to engage delivery to support them through it where needed, don’t leave engineers with architecture problems. It is also having the experience to know that to really explore a system we must combine analysis and synthesis; we must break problems down to structure our thinking, but we must stand back and see the system in context to see what else makes it operate.
Enterprises have never been so complex and alive, and to be able to analyse and synthesise is a critical skill when designing a business. But as I will point out, 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
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 behaviours of components and relationships, 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 had architecture which probably means some architects involved..
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 labelled 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; 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 is 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 is still the case today and the broadening of the architect role is making the situation worse. Everyone is an architect…. Cloud, IoT, CRM, AI, BlockChain, Data Centre, Banking etc.
I recently saw a job posting for a chief enterprise architect and the first skill was an 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 to the cloud, who does the architecture. It is an interesting piece; I have heard of some organisations where the CEO is considered the chief architect.
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. Interestingly the field of building architecture is in a similar place as designers take work and threaten the role and architects just become the architect of record for the building permit.
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 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, probably qualified, and I would 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, highly-trained…. Commodities that analyse, and not conceptualise.
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, the 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, I have a problem with the need to tag it with architect, there is no need.
In the main, these people are great at the platforms they work with and are people I have a deep respect for. They will be experts on many platforms. They can think through deeply wicked 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 is 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 what in the organisation may be aa strength we need to protect, where the risks are to change that are related to a deep understanding of how interactions across the enterprise work and the habits that make them work.
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 actually 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.
By the way, these strategic goals, I bet they are a mess and if someone does not put some structure around them, it is unlikely that anyone really knows why they are doing what they are doing.
What do I mean by architecture then, why does it appear so complex? Let us 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:
- What is the structure of a system (a complex arrangement of components) and the capabilities of those components?
- How do they interact, how they each behave and perform and how those relationships behave and perform?
- And when you consider the sum of those relationships, what strengths and weaknesses do we see?
- What are the assumptions regarding the nature of the relationships, what they do and the organisational perspective on why?
- What is the experience that comes with interacting with that system?
- How does it interact with its environment and other systems around it?
- What are the rules that inform its operation including autonomous operations and those that have a human touch?
- How will it endure and evolve as the needs change?
- The assets and resources that need to be deployed to build it and what skills that drives; is our high-rise bricks or glass?
- And ultimately how does all this align 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 do not have a city plan, enterprises will struggle much harder to remain relevant and therefore sustainable.
Architects love working with this complexity and constant ambiguity. Is this the sort of architect you want?
The caveat
I have 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. Maybe they want to do it themselves, after all the Director of Sales knows how to sell, but does he know how to build capability. I have seen it, architecture in the boardroom, behind closed doors, few understand the direction, or believe the integrity of the process to get there. This is an issue eating away at middle and lower management, “I don’t get it, why are we doing these things?”And when purpose and mission are unclear, it is very difficult to make it diffuse throughout the culture to build the keystone habits that are the foundations of a sustainable change.
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 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. After all, if they are the architect of record, they are carrying the risk.
What is 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, a then land another 25 resources).
If you need an architect there is a good chance you are looking to address a problem of thinking and not logistics and engineering. For example, I need an architect to validate my target operating model as I am 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 state your need, not the solution. Recruiters do not be lazy. Architects get your value proposition clear.
And if we can get this right, an amazing relationship with your client, they know that you understand and that you can help them understand, what could be better.
Café Associates will help you resolve your needs by placing the right sort of architect at the right time.