Anyone who has practiced any sort of technology project or transformation role for long enough knows the feeling of dread when things go wrong as this cynical but all too-true project lifecycle recounts [1]:
- Initial Enthusiasm;
- Disillusionment;
- Panic;
- The Search for the Guilty;
- Punishment of the Innocent; and
- Praise and honour for the nonparticipants.
But if those “things” that go wrong are not operational or delivery focused; don’t involve code that can be rectified; servers that can be rebooted; ML models that can be retrained on better tagged data; budgets that can be boosted – the dynamic involved gets very interesting, and can be very negative on an Enterprise Architect’s career.
That dynamic becomes one of which idea is “right”, and for an idea to be right, another idea can be wrong.
The ideas, concepts, frameworks and models that Enterprise Architects use to try to rationalise and align the technology assets and platforms to the organisation’s current and future missions are very useful, and helpful to structure diverse problem spaces. That said, some of these models, ideas and concepts are, to most people, esoteric at best and subject to misinterpretation at worst.
Take the integration pattern of three forms, two transforms [2] for using canonicals to “correctly” integrate data between applications (A2A integration). Taken on its own it seems fine – I have a system specific schema, like customer, at either input and output end, and a common form in the middle that interoperates both.
Some team needs to create the three forms if they don’t exist, some group needs to model the data, then conform it, ideally, into a broader transactional enterprise data model, remove any ambiguity, and ensure the business logic of the transformation is not buried in code but in a business glossary. It’s actually a lot of collaboration across many teams, and if that integration exists already, no appetite exists to change it, and the project fails EA governance in this example. This creates tensions and conflict, especially when the project team and management have no idea what the benefits of a canonical data model is, or even what a canonical data model is.
From that point forward, the story typically goes along the lines that the project agrees they are not remediating this technical debt, or agree to do a quick and dirty point to point integration and fix it later, agreeing to do it in subsequent phases, where it is forgotten about or the project is disbanded after the major objectives are achieved – none of which was to reduce complexity and increase elegance and reuse.
Worse yet are the platform debates which usually centre around tech first, requirements later, because of the CIO imperative to be seen to be making progress – and signing a vendor agreement is a concrete sign of progress. The worst statement I’ve ever heard from a senior IT leader along these lines is:
“I don’t know what we’re doing with data but we’re doing it with Azure”.
So, if the vendor agreement is signed and then the requirements/objectives/value outcomes are vague or unknown, usually at some point your friendly neighbourhood EA will be engaged and starts walking around asking sense-making questions – who is the audience of the platform; what is the business case; what systems/processes/integrations are we replacing; how will it integrate securely; what skill gaps do we have; how do we scale and so forth.
After some time, the EA produces a blueprint and a roadmap for the platform, addressing these concerns, then moves on to the next problem. Job done, or so we think.
Sometime later the program comes back from the trenches and says “the architecture is wrong, we need to do this instead in order to deliver”. What has also happened way before the EA hears about this is that “the architecture is wrong” statement has been circulating and, like a black hole, garnering negative attention with senior management, who now “blame the architecture” for the project’s lack of progress, for being a governance bottleneck, for not figuring out how the data leak happened, or “the EA said we have to do it this way that’s too slow” (like A2A integration) and so forth. And then the function of enterprise architecture is thrown into question, which has really happened in some Australian organisations who saw Agile as a way of removing the “EA bottleneck” [3].
This dynamic is the architecture blame game. Step 3 (Panic) has moved to step 4 (blame) and step 5 (punishment, or banishment of EA in fact).
How is this so?
One explanation is that the risk of personal reputational damage from egoists is being mitigated by those who hold power (like IT delivery leadership) to those who don’t (architects). So at one level it is the political process of shifting blame, and avoiding collaboration.
Projects and architectures and organisational transformation are big hairy complex endeavours. The blame happens via simple miscommunication, the left-hand right-hand problem, with the powerful stakeholders (especially project managers) flexing political muscle to shift reputational damage away from them so the executive continues to trust them.
Another reason is incompatible working assumptions. For example, a stakeholder was told (by the vendor) SAP Netweaver PI is true real-time which is critical for meeting a requirement. The architect knows it is micro-batches. The requirement can’t be met, and the money has been spent and expectations set. The vendor said it is true, so the architecture must be wrong, and since it was adopted as an EA standard, the Enterprise Architecture must be wrong. What’s more, the Enterprise Architect who made it a standard must be wrong too.
How to avoid the blame game?
All of this is messy and unfortunate, and occurs in other professions as well, but here are some practical suggestions for EA’s to avoid the blame game:
- Keep a journal. Every good EA keeps diarised notes and meticulously archives documents that can be brought out quickly (like the elevator pitch – why we’re here, what we’re architecting and why it’s like that and not another) when needed to dispel misconceptions rapidly to avoid miscommunication.
- Sell the vision and sell the detail. Without the detail and the debate about the detail, you don’t have an architecture. You don’t have an architecture unless it has consensus.
- Stay in touch with major programs and preferably get a seat at the steer co. This is tough as usually PM’s don’t want architects there because they want to write the narrative and quell dissent. The best execs will realise that a balanced committee works well.
- Don’t agree to architect a pear. If it’s pear shaped at the beginning, no amount of architectural will power will fix fundamental issues like no requirements, tech before business case, etc.
- Don’t play politics. Period. You’ll undermine your integrity for the next time round and most people who genuinely consider themselves architects (not just carry the job title) are crap at it.
- Seek an audience with the sponsor. Have a comms deck put together and clearly and concisely explain in simple non-technical jargon what the architecture is and what they will get. When the blame game starts, wheel out the same deck and remind everyone of what’s trying to be achieved (and why).
- Be patient, make friends. We’re all human and strong relationships are the key to strong architected transformations.
- Realise that no architecture is “right”. Just as no architecture is wrong per se, an architecture is simply a mental model – a collection of ideas, trends, notions, concepts, best practices and educated guesses. So don’t be precious about your architecture and roll with the punches, but don’t give way to what you believe is wrong either – that’s the key to integrity.
Footnotes
[1] https://www.barrypopik.com/index.php/new_york_city/entry/six_phases_of_a_project_enthusiasm_disillusionment_panic/ [2] https://www.enterpriseintegrationpatterns.com/patterns/messaging/CanonicalDataModel.html [3] And who now realise lack of system roadmaps and planning have increased cost and complexity and the pace of change irrespective of SAFe.About the author
Dr Adam Hart is an experienced Enterprise Architect, working across numerous organisations in Australia. He is also the Owner and Author of The Digital Ethicist on Medium.
