Setting the scene
Let’s stop trying to define enterprise architecture as anything but a body of knowledge that binds an enterprise together to guide it in a direction aligned with ambition. It can contain anything, be influenced by anyone, be owned by everyone, be represented in any notation; it just has to work for that organisation, and it has to be a key part of delivering change. This means different roles and relationships as part of a more collaborative style of building the blueprint. Café Associates can help with this transition.
This is an article from early 2019. It starts “I’ve just started reading another book on Enterprise Architecture; it promises to be a refreshing change in a world of unfettered and unfulfilled Enterprise Architecture ambition”.
As I refresh it for 2020, it is odd, as I have just started another book on EA, and there have been several since, and I doubt I will finish this one too. This may be partly because I cannot do 50 pages of introduction of a tired argument that tries to be something new.
I’ve just started reading another book on Enterprise Architecture. I’m reading another because it looked like it reflects where I am now; that it is not working and the landscape of the organisation, and its change drivers and methods, is going to seriously hinder any further progress towards the original dream of a complete and perfect enterprise blueprint owned by a charismatic but enigmatic enterprise architect (EA).
There are times when it is necessary to consider whether we dogmatically continue forward in an unfaltering belief we are right (and self-belief is generally not something we lack) or consider that all the people that have pushed back over the years may have a point (well, some of them anyway).
Where have we come from?
For many years as a consultant I have worked with architecture teams, to help them understand their purpose, whom they do this stuff for, and to answer what questions, and what product do they produce in the execution of that mission, and does it do the job they intended. These are the right questions any function should be asking of itself.
I’ve done this for organisations with large teams. For example, 80+ architects at a bank, or 30+ for a global organisation that had invested huge sums of money in a heavily customised and rather wonderful TOGAF variant. For a multibillion-pound organisation where architects thought bringing a 200-page design document to a Strategy Board was the way to get decisions made.
For huge organisations that knew they were a bit lost…. “Hi, can you help, I know my team is busy, but I’m not really sure what they are doing”. For large and smaller organisations with little or no capability but sensed that they needed to do something different, usually motivated by change or external factors.
In all cases, we should start with Why, before What, How and With What. But why were these teams unsuccessful? A lot of it was related to a clear lack of purpose and understanding of that purpose.
A bloated agenda and promise
In all these teams there is no question of the nobility of motivation; in each it was about delivering a better outcome for the business, customer, citizen, or to align technology with the business, or reduce risk, increase the rate of change, make change more predictable, make better decisions, create flexibility and adaptability, remove waste, drive innovation, technology and/or process rationalisation etc. Or all those things, after all we are EAs and if we don’t do this who will. It’s worse than that, if we don’t do this, everyone else is going to make a mess of it.
There is an arrogance here that needs to change in a world where
- Everyone is part of an agile, lean, collaborative and componentised delivery model
- Where there is a library full of alternative approaches to business design that seem more dynamic and less pompous.
There is no doubt that the teams were generally populated by incredibly talented individuals who could turn their hand to pretty much anything, reflecting a core purpose of architecture which is to solve customer problems through a number of structured and unstructured methods including design, engineering, estimating, planning, testing, selling etc.
And here we have a hint of a problem; huge ambition, huge confidence (which brings huge latitude), huge demand (for better outcomes) and a huge amount of documentation on what ‘good enterprise architecture’ is. And unfortunately, an audience that is still largely cold to the idea. No…. it is not gaining traction, don’t kid yourselves. The only thing that has traction is the everlasting and indulgent debate. it is a debate that the stakeholders we most wish to serve, the directors of businesses, the executive team and CEO, just will not tolerate.
The final straw…..
I recently saw more posts by well-meaning bloggers trying to help the world understand the role of various types of architects. Was this just more of that bad old indulgence of architects describing what they do? Why is this so common? Are we that insecure? Is it that complicated (and if so should it be…)? Is it that we just can’t get the message across because it’s plain wrong? One of the posts tried to reinforce boundaries between architects at a time when we know we must break them down. This dogma was the final straw and I thought it time to call time.
Zachmann used to say, if you need to make a change to a complex system, you get out the blueprints. And the EA assumed responsibility for all roles relating to these blueprints. If you want to do some town planning, you get out the blueprints. It’s an old metaphor and it doesn’t really work as dynamic systems aren’t like Jumbo jets. Enterprises have a property where individual components of the system work together to give rise to dramatic and diverse behaviour, the system is the sum of its interactions and this could be the intangible ingredient that drives differentiation. I don’t think Jumbo jets do this, they are complicated for sure, but do not have emergent properties (we shall leave that to the 24th century).
But in each of these cases, no single individual creates, owns, governs, maintains, transforms these blueprints; a team must come together to make it happen and keep it relevant and take some shared ownership in it all hanging together.
Catalysts for change
We keep hearing that all industries and the entire software profession are undergoing unparalleled change.
It’s not new. Bernard H. Boar wrote about it in the late ‘90s in Constructing Blueprints for Enterprise IT Architectures. He talked of hyper-competition, marked by:
- The difficulties of creating and sustaining competitive advantage.
- Rapid and dislocating innovation which rapidly devalues know-how which continually must be refreshed.
- Competitive escalation and the continual raising of the stake to play the game.
- Customer power increasing as their expectations increase and the ability to effortlessly substitute increases; loyalty is fleeting and needs to be bought.
- The constant redefinition of what is value by customers and how this drives continually change into the value proposition.
- Competitors act relentlessly to satisfy there need for market share and barriers to entry and success are challenges to circumvent.
- Disruption rather than protection is the rule and focusses on devaluing your competitor’s advantage before they do it to you.
This all sounds very familiar, sounds like 2020 But what else is changing, and again nothing new to any of you?
Some of them are pattern shifts to be accommodated:
- Cloud computing causing disruptive change, creating complex and fragmented architectures and changing development practices.
- Digital is creating new capabilities and integrating with the old as it transforms. Giving the customer and user more control of the services and information they consume will play to that hyper-competition agenda.
And some are disrupting the traditional architecture mindset.
- Agile and DevOps is refocusing the organisation on the production of working code that delivers a customer-defined incremental change. Architecture must evolve to remain relevant; this means architecture engaging with the downstream part of the lifecycle and being there to the end (which it should always have done anyway). The risk of disengaging at concept or solution is now much higher.
- APIs/Microservices and architecture is potentially a meeting of worlds that is difficult to orchestrate well; the difference in methods, tempo, understanding and perspectives.
The previous two examples focusing on speed, disintegration, swarming, self-defining teams, peer networks and generative cultures, and giving decisions to those with the data will challenge the corporate architect who is tempted to think he/she is at the top of the ‘hierarchy’.
And the final and I think the most disruptive drivers may be a surprise
- Business architecture has come of age (almost). But this is what we’ve always been aiming for? Yes, but enterprise architecture largely failed to deliver it and it the business has caught up, maybe helped by Osterwalder and Pigneur. This creates a new kid on the block and a very powerful one.
- In addition Design Thinking, Enterprise Design and other tools are taking work from the architect because they seem so much more aligned to the reality of delivering value.
Business architecture comes of age
Historically enterprise architecture has created business architecture as a context-setting exercise for a technology project; it creates the requirements in a framework that means we can create an integrated blueprint and show that alignment and traceability. That’s a good goal, but it did not seem relevant to the business participant who is struggling to turn ambition and motivation to goal to capability need to transformation blueprint and change projects.
In the last ten years, I have seen the rise of the Target Operating Model (TOM) as a formal, rich and powerful tool. It is one that has yet to undergo formalisation and result in an 800-page document and at the moment that is a good thing.
A key problem in delivering business change is bridging the gap between the abstractions of strategy and the realities of operational and technology delivery; it is not possible to generate meaningful change from simple mission, vision and goal statements and is why capability management has become core to linking need with resources and assets, identifying what needs to be built, and what needs to be sustained and protected.
Often this gap is significant with portfolio and programme functions unable to successfully structure an integrated road map of projects that reflects the business ambition. It can result in no demonstrable view of how investment and the progression of business change are aligned to it.
The operating model is a great tool to achieve this; not just a view of operating structure but a detailed assessment of capability and capacity to provide an integrated view of the changes needed across all key enablers.
It is architecture but it uses terminology that aligns with the business participant and promises to engage and create a collaborative experience and not one that wants to own the thinking.
The ability to capture and refine the three key business models, the motivation model, the market model and the products and services model, creates a solid context for the business and technology architecture elements that follow. This combination of business and technology architecture determines the deployment of assets and resources to deliver the value proposition to the target customer. But this is enterprise architecture, isn’t it? The TOM and the transformation map that follow are enterprise artefacts and there is still a need to maintain alignment of these elements.
The TOM takes enterprise architecture into a world it finds difficult to play in. To create a strategic plan that says whom the organisation will serve, what is offered, and how value is created it is necessary to flesh out the elements of operating model, value proposition and the business model. This requires considerable business buy-in but this is where the business is actually architected.
Great. The final bit of the jigsaw in world domination. No. I’m sure examples exist but this is not going to be the domain of the EA. I’ve said for at least twenty years that it probably easier for a business person to grow down into the technology space to drive alignment than it is for a technologist to grow upwards (I’ll put my flame suit on……). As technology has become more commoditised, Google has provided access to all known knowledge and we all carry a supercomputer in our pockets, it no longer seems like a dark art (unlike enterprise architecture).
The final bit of the jigsaw is being delivered within the business. This creates a very new dynamic as two powerful stakeholders, the COO and the CIO, own the enterprise blueprint. Or in the case of a recent assignment, the Director of Strategy and Marketing pretty much owned all of it, supported by a fantastic team of business architects within their team, and some amazing enterprise architects that could collaborate with them.
What opportunities does this create?
The good news is that finally, we understand most of the whole problem space e.g. what is a TOM, how is architecture a part of it, what are the component parts? The big challenge is how a set of roles, processes, artefacts and deliverables are implemented around that big TOM picture. Typically, in a complex and federated organisation, these roles are separate and defined by different leaders and probably mired in ambition and disagreement.
The TOM space must be joined up to be relevant. Do our culture and organisation address a joined-up TOM model and are conflicts and gaps addressed?
The process must be a joined-up process with one thought process able to lead to the next and back again if required. If we do not think of it this way and that the goal is common, it’s just a repeat of the “what’s the difference between architecture and design” discussion; and if you organise and collaborate properly around a common set of outputs and outcomes, it does not matter where that boundary is as if you are not iterating across it, you have a silo.
Intractable organisational politics will enforce a federated model and it’s probably a fight not worth having (in fact it’s disruptive and distracting) to suggest that it’s all done in a single place.
This drives the need for a twist to the EA role; someone that is accountable for the integrity of the whole model and not necessarily all or any of the detail. That’s still a challenging role as rather than being the mad professor that owns all the strange artefacts, it is a person that can bring a broad spectrum of contributions together and make it relevant for the executive team. After all, creating a blueprint for a Boeing 747, a city, or an enterprise is a collaboration amongst many people and skills; probably more than we can imagine, but that is for another discussion.
I believe this is the EA of the future.
- Accountable for the integrity of a ‘good enough’ enterprise blueprint but not delivering it. It’s like Microservices across disparate development teams, let them use the languages they want, but ultimately there needs to be a common language of integration.
- Choosing when to intervene where necessary to increase organisational performance.
- Helping leadership distinguish architectural change and act accordingly.
- Aligning the enterprise approach to architecture to the enterprise goals, culture and performance.
- Providing support across the enterprise to help business, information, software, service, operations, security, infrastructure, network, Cloud architects make their contribution.
- Facilitating a clean flow of decision making across the lifecycle from dream, discover, define, design and deliver.
This means letting go to enable focus on what really needs to be delivered, business and technology aligned, business leaders and technology leaders aligned, and architects across the enterprise aligned.
This may be a difficult change for the organisation and the architecture stakeholders. It is possible to try before you transform with some targeted Architecture as a Service.