> ## Content Index > Fetch the complete content index at: https://www.ariet.net/llms.txt > Use this file to discover other available public pages before exploring further. # Enterprise Architecture as Diplomacy - URL: https://www.ariet.net/enterprise-architecture-as-diplomacy/ - Published: 2026-07-16T09:13:14.000Z - Updated: 2026-07-17T19:58:10.000Z - Author: Richard Thackeray - Tags: Enterprise Architecture *From a LinkedIn post from August 2023, rewritten in July 2026* ## Time to ditch the technology domain Some time off work, plenty of thinking time, maybe some overthinking, reading, and some challenging work experiences have made me reconsider the role of enterprise architecture and the enterprise architect. As is typical with enterprise architects, I will announce my conclusions as fact and not up for discussion. Okay, that's not quite true. This is a work in progress in my head, and I am writing as I am thinking, which you may notice. But it would be better done as a discussion. For many of my colleagues, this is a gentle shift in focus, though maybe not an easy one to make. Enterprise architecture must leave its technology roots behind. If it is about connecting the enterprise, collecting, connecting and correcting the dots (as Roger Burlton rightly says), it cannot do this if it is trying to justify its existence on the quality of technology delivery. This doesn't make it business architecture as it is still focused on understanding how an organisation uses resources and assets to deliver operational capability, and this includes technology. Its aim is to offer the structural viewpoints needed to understand the best next course of action and investment. It focuses on what we know to drive decisions that create sustainable structure rather than necessarily knowing what an organisation does and needs to do (and hence can still be distinguished from business architecture). But just holding the pen on the knowledge base isn't enough, it needs to "be where the work is", as Chris Potts says in RecrEAtion (my book of the year!). Enterprises aren't designed to join up; structures, people, power, politics and incentives get in the way, which introduces an essential skill for the enterprise architect: diplomacy. ## The relevance of diplomacy I've started reading Tom Fletcher's Naked Diplomacy book. He had a series on Radio 4 a few months back that discussed 'The Battle for Liberal Democracy'. I was impressed. He talks of diplomacy as a set of interventions that set and keep in play a coalition of decisions that strengthens the interests of a nation-state. But also when done well they invest more in bridges than walls and bring states together by having a worldview that results from having actually viewed the world. Architectural diplomacy represents the interests of the structural integrity and cohesion of the organisation. Lord Salisbury said in 1862 "there is nothing dramatic in the success of a diplomatist. His victories are made up of a series of microscopic advantages: of a judicious suggestion here, of an opportune civility there, of wise concession at one point and far-sighted persistence at another, of sleepless tact, immovable calmness, and patience that no folly, no provocation, no blunder can shake". Some of the best architects I have seen work like this. They create conversations that create a series of microscopic advantages. Enterprise architecture can be very difficult. In the book, Tom outlines that diplomacy is hard when: - You are in perceived decline, when it is more difficult to get invited to that important meeting, when people want to engage the new kids on the block. - When your power is on the wane, you can't invest, people are not engaged to drive your interests and extend your influence. - When you are competing with players with greater pioneering zeal, when you are representing interests that have lost their creative edge or hunger. - When lack of resources or confidence leads to an introspective mindset rather than a drive to find new ideas and sources of renewal. - When people on your own side want to throw in the towel and decline quietly into a corner, when your visitors smell the faint whiff of genteel decay. - When the rules of the game are in flux, when the players are ready to turn the chessboard over, when the system is being disrupted or degraded. - When those intent on furthering their own interests are dominating the agenda. - When rival sources of power think that diplomacy doesn't matter. Do these sound familiar? Tom points out that these are the times when it matters most and as architects, while we focus on technology, we cannot hope to build and sustain the conversations that achieve our goals. ## Perpetuating tribalism? One of those times is happening right now, inside our own profession. Sorry, we are still debating enterprise architecture. It's an endless and often tedious debate that highlights what we see as tribalism in our profession. But it's a very individualistic type of tribalism, as I am not sure we actively seek and work together with like-minded people. As I write that word it makes me wonder about tribalism. Tribalism creates in and out groups with subsequent disrespect between them which can lead to conflict, shrill and sanctimonious discourse and resulting failure to problem solve. I see this all the time between business analysts, systems analysts, product teams, architects and engineers. I hate it. I hate that it feels so personal, when really it is those who write the manifestos and push them out as the next big thing who are largely to blame — like those who polarised and tribalised people into Remain or Leave. We need to understand the perspectives of the other groups if we are to stand any chance of working together. Tribalism is an enemy of bargaining, compromise and rational engagement. As architects of the enterprise, we have to find common ground to work across the tribal groups. Thinking of the tribalism within architecture, maybe it is time to simplify our proposition, remove the "Are you TOGAF, or Zachman, or maybe EDGY?", and find our core values. One of these core values is how we should work across the organisation to inform decision-making. Good decision-making drives the correct structural investments that build, evolve and sustain capabilities critical to performance (however that is defined). When we talk structure, we can think of the building metaphor: those elements designed to carry loads, that provide strength and stability. But in a dynamic system, structure provides more: - Mobility, the necessary range of motion - Stability, the necessary ability to control and hold position and motion against forces operating in other directions - Strength, the ability to overcome resistance - Power, the ability to overcome resistance in the shortest period of time. All enterprises need structures that can provide these abilities. Diplomats need to work across the organisation to make this happen. Tribalism isn't the only place that diplomacy is being tested. ## Where next then? Someone needs to hold the pen on the blueprint of how operational capability is delivered, and how that knowledge is applied to delivering the right change and delivering change right. However, we should not let this distract from the real value of someone seeing the enterprise as a whole and working with people to join up discussions that must be joined up, encouraging others to do the same. Back to that theme of connecting. Connecting is a people problem, and it takes time and skill. But many enterprise architects have a massive distraction and the wrong set of metrics that govern their behaviours. One of these distractions is that it is far too closely coupled with solution delivery in an attempt to retain legitimacy and relevance. This is based on the belief that to be relevant it has to be in the bowels of the change; if I am not able to have a design discussion with an AWS expert, I am irrelevant. But in whose eyes? Enterprise architecture has to be relevant, but if the definition of relevance is, for example, being able to discuss the best solution for AWS integration, this is probably the CTO talking. EA should not be directed by the CTO. In nearly all my roles I have taken the position that legitimacy comes from being attached to delivery. It's an obvious path, and probably an easy one. But the moment you start to think of value and metrics beyond your contribution to solution design (which is of huge value) that legitimacy breaks down. Architecture metrics often look at what has been delivered and how, and not whether we created and informed the right conversations a year ago that resulted in the right project delivering the right capability. We create a proxy for this by assessing whether what we did was strategically aligned and not whether we have made the correct structural investment that will enable business performance. That's really difficult to do and under CTO sponsorship I will never get the space to do that. Caveat. If I am asked to run another enterprise architecture function, and it is within IT, and we legitimise it on our relevance to delivery, I will do it again. But change starts here. ## Business design is within the business So who is our customer if not delivery teams? It is the myriad of roles across the organisation that are designing it. The design of a business, which cannot avoid a discussion about technology, happens across organisations. Architecture needs to be part of that. If there is an operational capability, someone will be designing how it is configured to meet capability-specific operational and strategic goals and that will include technology and data by implication. The missing piece in many organisations is what binds these people together: how the needs of the product designer, technical pricing, and risk specialist get exposed, and how conflicts and opportunities are identified and resolved in a way that keeps all parties happy, even if they don't get everything they want. Business functions (which should deliver services) are not designed around a system that delivers services, they are designed around how the chief executive wants her/his top team to look, the themes she/he wants to control and have visibility of, and this cascades down through the hierarchy. Most business functions focus on their own purpose and not their purpose within the ecosystem. Partly because they are not incentivised to, and partly because it is really hard to connect all these interests and broker or inform good decisions that are in the interest of the ecosystem. If enterprise architecture is bringing these people together, it cannot do this as a side-of-desk role whilst worrying about technology standards. We must create a new narrative that describes the value of the decisions that come from connecting the interests and breaking down artificial barriers that prevent coherent decision-making. Architecture is one of a very small number of roles that has a remit wider than themselves. Functions tend to think of their boundaries and adjacent functions, but probably no further. I have performed this connecting role within the context of helping translate strategy to capability, and in doing so connect the functions on that quest. It can be done although I have yet to resolve how to operationalise and measure it. ## What next This is still thinking in progress, and I'd rather have it as a discussion than a doctrine. But the shift I'm arguing for is this: stop measuring enterprise architecture by its grip on delivery, and start measuring it by the microscopic advantages it wins for the organisation; the judicious suggestions, the opportune interventions, the coalitions it holds together. That's a harder thing to put in a dashboard. It's also, I think, the only thing that was ever going to be worth doing.