⏱ 24 min read
Most ADM stakeholder plans are fiction.
That sounds harsher written down than it usually does in a steering committee room, but after enough years working in regulated banks, I have come to think it is simply true. Most architecture teams can assemble a stakeholder matrix in a day. Names, roles, influence, interest, perhaps a RACI if the mood is ambitious. Then the real work begins, and that polished artifact quietly expires in a SharePoint folder while actual decisions get made through corridor conversations, control-function ambushes, budget objections, and governance forums that somehow discover “new” concerns six weeks too late. ArchiMate for governance
In banking, stakeholder management is not a soft activity hanging off the side of the “real” architecture work. It is one of the mechanisms that stops the architecture collapsing under constant churn. Do it badly and you get late-stage non-compliance findings, redesign loops, migration plans nobody can actually fund, and decision trails so thin that audit can drive a truck through them.
And the stakeholder landscape is far messier than the old business-versus-IT story implies. In any serious banking transformation, your stakeholders include product, yes, but also operational resilience, compliance advisory, data privacy, model risk, legal, financial crime, internal audit, cloud governance, vendor management, finance, service management, and regulators indirectly through the control teams already preparing for the questions they know will come. EA governance checklist
The uncomfortable truth is this: stakeholder management in the ADM is really about negotiating decision rights over time. Again and again. Not once.
So let’s start with the mistakes, because in my experience that is where most of the useful lessons tend to sit.
The case that runs through this article
To keep this practical, I will use one case throughout: a digital lending platform transformation in a multinational bank.
The objective looked straightforward on the strategy slide. Replace a legacy loan origination stack with an API-led, event-driven target architecture. Move selectively to cloud under strict regulatory controls. Improve turnaround time. Reduce manual handling. Strengthen data lineage. Support model transparency for automated decisions. Operate across several countries and legal entities with slightly different obligations. integration architecture guide
Reasonable.
The stakeholder landscape was not reasonable. It was real.
- Chief lending officer
- Head of operations
- Security architecture and CISO delegate
- Data protection officer
- Compliance advisory lead
- Model risk team
- Enterprise platforms team
- Cloud governance office
- Finance business partner
- Product and delivery lead
- Internal audit observer
- Third-party/vendor manager
And that is before adding country CIOs, legal entity governance, records management, and the teams still carrying scars from the last “strategic lending modernization” that went nowhere. ADR template
This is the kind of case where TOGAF stakeholder management either becomes genuinely useful, or turns into theater. TOGAF training
Mistake #1: treating “the business” as one stakeholder
If your stakeholder map says “business,” it is already too late.
I mean that almost literally. In banking, “the business” is not a stakeholder. It is a category error.
In our lending transformation, the product organization wanted faster digital onboarding and fewer abandonment points. Operations wanted fewer manual exceptions and less swivel-chair processing between systems. Compliance wanted stronger KYC and affordability controls. Security wanted better identity proofing and tighter IAM integration. Finance cared about processing cost and transition spend. Country leadership cared about local regulatory exposure and whether the group design would force local workarounds.
The first pass from the architecture team captured much of this under a broad heading: business stakeholder needs.
That single choice created weeks of vagueness. Principles became mushy because they were trying to satisfy contradictory interests all at once. Governance meetings circled endlessly around “business priorities” as if there were one coherent thing to optimize. There was not.
What works is splitting stakeholders by accountability, not by org-chart labels. Ask four blunt questions:
- Who can block this?
- Who owns a control affected by this?
- Who absorbs risk if this goes wrong?
- Who pays for the change or the transition state?
That produces a much more useful map than “business, IT, risk.”
I have found this especially important in regulated product domains like lending, payments, and onboarding. Product may own customer outcomes, but operations often owns exception handling, compliance owns interpretation of obligations, and legal entity leadership owns the institutional consequences when something breaches local rules. Treating them as one voice guarantees churn later.
A stakeholder map that hides accountability behind broad categories is not simplification. It is deferred pain.
Mistake #2: only engaging control functions at governance gates
This one is endemic.
Architecture and product work together for weeks. Engineering starts shaping options. Someone gets excited about the target state. Maybe there is a clean event-driven design, Kafka for domain events, APIs fronting core capabilities, cloud-native document storage, a modern IAM pattern, all the right phrases. Then security, privacy, resilience, or compliance get invited in when the design is “ready for review.” cloud architecture guide
At that point the design is not ready. It is exposed.
In our lending case, the initial target design assumed customer document storage in a shared cloud service aligned to enterprise platform strategy. Technically it was sensible. It reduced duplication. It helped standardize retrieval and audit trails. Then privacy and records management got into the room properly and raised jurisdictional residency issues, retention constraints, and legal hold requirements that had not been resolved for several countries. We ended up redesigning part of the document handling model during Phase C, and that change rippled straight into implementation planning.
None of this was exotic. It was predictable.
Control functions in a bank are not there to review architecture at the end. They shape which options are viable at the beginning.
What actually works?
A pre-brief before formal architecture work starts. Not a giant workshop. Just enough to surface red flags.
Then an early red-flag session in Preliminary or Phase A. The aim is not to finalize the interpretation of every control. It is to identify non-negotiables before solution optioning hardens around the wrong assumptions.
And where regulations are ambiguous—and they often are—maintain a control interpretation log. That sounds bureaucratic until you need to explain six months later why one cloud pattern was considered acceptable and another was not. In regulated institutions, memory is not governance. Written interpretation is.
There is a balance here, obviously. Involving everyone in every meeting is wasteful and usually performative. But involving the right control owners at the right decision points is essential. I have seen far more bad architecture caused by control functions arriving too late than by them arriving too early.
Before Phase A, there is usually a political phase nobody documents
TOGAF is fine. Reality starts earlier.
Before the ADM is formally launched, there is almost always an undocumented political phase where experienced architects do the real reconnaissance. You find out what the sponsor is actually worried about. You test whether they really have authority. You discover who was burned by the previous attempt. You identify hidden veto-holders. You learn whether “strategic priority” means funded, tolerated, or simply fashionable.
In one bank, a country CIO was enthusiastic about a lending modernization. Central risk was cautious. Operations was quietly against it because the cost of retraining branch and contact-center teams had never been budgeted. Audit had prior findings from an abandoned workflow initiative and did not trust claims about control uplift. On paper, sponsorship existed. In practice, it was conditional, fragmented, and politically brittle.
This is where chief architects earn their keep.
The most useful interviews at this stage are not requirement-gathering sessions. They are off-record listening sessions. And the best question is rarely “what do you need?” It is usually closer to: what would make you oppose this?
That reveals much more. Reputational risk comes out. Prior failures come out. Territorial concerns come out. So do the phrases that should make every architect pause: “audit will never allow it,” “we tried this before,” “legal still has concerns,” “that works centrally but not in-country.”
One artifact I like here is a stakeholder heat map with resistance hypotheses. Not facts, hypotheses. It forces a bit of honesty.
For example:
- Operations resistance likely driven by exception handling cost, not target architecture preference
- Model risk likely to challenge automated decisioning explainability before technology design review
- Cloud governance likely supportive if managed services remain inside approved landing zone patterns
- Finance likely neutral early, negative later if dual-running costs emerge
That is far more useful than a neat influence-interest grid with green circles.
Mistake #3: assuming stakeholder concerns stay constant across the ADM
They do not. And this is one of the biggest reasons stakeholder plans go stale so quickly.
Stakeholder salience shifts by phase. Not politely either. Dramatically.
Early on, stakeholders care about intent, scope, mandate, and risk boundaries. Later, they care about operating consequences, control points, data lineage, service ownership, and whether the architecture creates work they do not currently have capacity for. Then, once migration planning begins, the conversation changes again: sequencing, duplicate cost, cutover risk, residual exposure, customer disruption, change fatigue.
In the lending transformation, finance was mostly quiet during visioning. They were comfortable enough with the strategic direction. They became central during migration planning when it became clear the bank might need dual-running decision engines, duplicate reconciliations, and temporary overlap with a third-party document service during transition. Suddenly the target architecture was not the contentious item. The transition state was.
Operations also got louder later. During early architecture, they broadly agreed with the target. During implementation planning, they realized branch support processes, manual overrides, and failure-handling responsibilities in the event-driven model were underdefined.
That is normal. The mistake is pretending otherwise.
What works is rebuilding the stakeholder matrix at phase transitions. Not from scratch every time, but enough to capture concern drift. Who matters now? What evidence do they need now? What decision are they influencing now? Who can step back from deep engagement because their concern has been sufficiently addressed?
I call this a phase-specific stakeholder contract. Not legal, obviously. Operational.
For each key stakeholder:
- what they need from this phase
- what decision they influence
- what evidence they require
- when they must be engaged
- what happens if they disagree
This stays far more alive than the usual static catalog.
Stakeholder concerns across ADM phases in a banking transformation
This table is not for documentation theater. It should drive different engagement tactics by phase.
What TOGAF gets right—and where teams use it too mechanically
TOGAF is often criticized by people who have only seen it used badly.
It gets some important things right. Stakeholder identification matters. Concern mapping matters. Viewpoints matter. Governance integration matters. Those are not trivial contributions.
The problem is the mechanical use of those ideas. Teams fill in stakeholder catalogs, document concerns once, create viewpoints that architects find satisfying, and then never reconnect any of it to actual decisions. The ADM gets treated as if stakeholder treatment can remain static while the politics and risks evolve around it.
In a bank, that is fantasy.
The ADM is not linear enough, and the institution is not stable enough, for static stakeholder treatment. Use the TOGAF artifacts, yes—but use them as negotiation tools, not as compliance paperwork for the architecture office. ArchiMate in TOGAF
That distinction changes everything.
Mistake #4: architecture viewpoints that answer the wrong questions
Architects often think they have communicated because they have explained the architecture. Those are not the same thing.
I have watched compliance teams receive component diagrams when what they really needed was a control-impact summary. I have watched CFOs get a polished target-state picture without any credible transition cost narrative. I have seen operations teams shown capability maps that ignored failover responsibilities, support ownership, and manual exception paths. Internal audit gets architecture principles when what they actually need is traceable decision history. capability map template
Then architects are surprised when the same stakeholders block later.
If a stakeholder says, “interesting deck,” and still blocks later, the viewpoint failed.
For the lending platform, the useful viewpoint set looked nothing like the architecture repository structure.
We used:
- an executive one-page decision view showing what was changing, why now, key risks, and where decisions were needed
- a compliance control mapping view showing control continuity, changed control points, and unresolved interpretations
- an operations exception-process view showing failure scenarios, handoffs, and ownership
- a finance transition-cost view showing dual-run periods, temporary control duplication, and vendor overlap
- an engineering dependency view showing APIs, Kafka event topics, IAM dependencies, and sequencing constraints
That last one mattered more than it may sound. The event-driven design was attractive, but the real concerns were around idempotency, replay handling, audit evidence, and who owned failed event processing when an application decision could not be completed. Showing event flow as a clean technical pattern was not enough. We had to show the control and operational consequences.
Tailor viewpoints to stakeholder anxiety. That is the simplest rule I know.
Phase A techniques that work, if done with discipline
Phase A is where architecture teams either create a usable mandate or create years of ambiguity.
A few techniques have held up well for me.
First, sponsor triangulation. Never rely on a single sponsor in a bank, no matter how senior. You need the formal sponsor, the operational counterweight, and at least one control-function perspective. Otherwise the vision gets approved by one power center and undermined by another.
Second, interviews framed around risks and trade-offs rather than broad wish lists. Architecture vision sessions become much sharper when people have to state not just what they want, but what they are willing to trade off.
Third, a one-page architecture vision with explicit out-of-scope items. That last part matters more than most teams realize. In lending, for example, we made it clear that the phase-one target would not rationalize every downstream servicing process or harmonize country-specific credit policy. That prevented later arguments about implied commitments.
Fourth, concern-to-principle mapping. If operations says manual exception volume is already untenable, that should become an explicit principle or success condition, not just a note in a workshop output.
And fifth, define success criteria that include control outcomes, not just speed or cost outcomes. In our lending case, one success criterion was not merely faster approval. It was reduced manual review without an increase in policy exceptions. That changed the conversation with model risk and operations immediately.
What does not work is broad consensus theater. Endless workshops. Long lists of requirements before decision rights are clarified. Architecture becomes a sponge for every anxiety in the room, and the result is a vision nobody can really govern.
Mistake #5: confusing stakeholder management with communications planning
This deserves a blunt distinction.
Communications is what people hear.
Stakeholder management is how decisions move.
Many architecture teams are decent at communications. They produce roadshows, newsletters, all-hands decks, FAQs, intranet updates. Fine. None of that resolves a deadlock between product urgency and regulatory caution if nobody knows who has the authority to accept residual risk.
In our lending transformation, the architecture team socialized the target state widely. Plenty of visibility. Strong attendance. Positive feedback. And still we hit a major deadlock over model explainability in automated decisioning. Why? Because the problem was not awareness. It was unresolved authority between product, model risk, and compliance over what level of explanation evidence was required before rollout could expand.
No amount of better communication would have fixed that.
The tools that help are much plainer:
- a decision-rights map
- an issue escalation ladder
- a decision log with accountable owner
- an exception process with expiry dates
That last one is underrated. In regulated institutions, ambiguity about who accepts risk is one of the fastest ways to stall ADM progress. If an interim state is needed, say so, document it, assign an owner, define the control impact, and put an expiry date on it. Otherwise temporary exceptions become semi-permanent architecture.
Mid-ADM reality: this is where credibility is won or lost
The textbooks separate Phase B, C, and D neatly. Real transformations do not.
Business architecture bleeds into application architecture. Data questions reshape process design. Technology constraints alter operating model decisions. In banking especially, these phases overlap because controls cut across all of them.
In the lending program, the event-driven design looked elegant. Kafka topics for application submitted, affordability assessed, document verified, decision made, case referred. APIs for channel integration. IAM federated into central identity services. Cloud services for scale and observability.
Then the hard questions arrived.
Who owns exception handling when an event fails after the customer has received partial confirmation? What is the evidential chain for a model-assisted decline if the decision path spans multiple asynchronous events? How do we preserve records retention obligations when document metadata and document binaries live in separate control domains? What are the service management responsibilities on day two, not day zero?
These are the moments when architecture either grows up or retreats into diagrams.
The techniques that work are practical and, frankly, sometimes unfashionable. Scenario walkthroughs using real customer journeys and failure cases. Day-two operations workshops before design sign-off. Architecture decisions explicitly linked to control owners. Rejected options documented with reasons, not because the repository needs more content, but because people forget and old arguments return.
One example: operations challenged the event-driven approach because exception ownership was undefined. They were right. The architecture team initially treated that as an operating model detail for later. It was not later. It was architecture now. We had to add explicit exception orchestration and accountability design into the target state, not leave it to implementation interpretation.
Stakeholders trust architecture more when they can see consequences, not just target-state elegance.
Mistake #6: leaving finance out until migration planning
Architecture teams often under-engage finance because they assume finance only enters when funding is needed.
That is a mistake. Finance is a stakeholder in architectural viability.
In banking, transition states can kill an otherwise sound target architecture. Dual running, duplicated controls, temporary reconciliations, vendor overlap, retraining, local remediation, extended support contracts—those costs often sit outside the clean target-state business case.
In our lending transformation, the migration required temporary coexistence of old and new decision engines, duplicate monitoring controls, and overlapping vendor commitments while records retention and legal hold arrangements were stabilized. Finance objected late, not because they disliked the target, but because the transition cost profile had been largely invisible during option evaluation.
Bring finance in earlier. During option assessment, not only in Phase E/F.
Quantify transition states, not just target-state TCO. Show the cost of interim controls. Explain how long duplicate environments are expected to run and why. If an option is technically superior but creates eighteen months of duplicated control cost across multiple legal entities, that is an architectural fact, not merely a budget problem.
I have seen strong target architectures die because architects treated transition economics as somebody else’s concern.
The small set of artifacts actually worth maintaining
Most banks have too many stakeholder artifacts and too little stakeholder intelligence.
You do not need a giant spreadsheet with 70 names and fictional ratings. You do not need a RACI chart pretending decision rights are settled when they are not. You definitely do not need slide decks detached from active decisions.
What you do need is a compact set of living artifacts:
- a stakeholder map by decision right
- a concern log with phase and date updates
- architecture decision records linked to stakeholder input
- an issue and exception register
- a tailored viewpoint pack
- a transition-state impact sheet
If I had to choose one, I would keep the living concern log over a polished stakeholder catalog every time.
A concern log forces movement. It shows what changed, who raised it, whether it was resolved, deferred, escalated, or converted into a design principle or exception. It gives you traceability without drowning the team. architecture traceability in Sparx EA
Callout: Red flags that your stakeholder plan is already stale
- It still says “business” as a primary stakeholder
- No concern has a last-updated date
- Control functions only appear at review boards
- Finance is absent until migration planning
- Viewpoints are organized by architecture domain, not stakeholder decision
- Escalations happen informally but are not logged anywhere
Mistake #7: governance forums that punish escalation
Large banks often say they want transparency. Many governance forums actually reward apparent alignment.
That creates a bad behavior pattern. Architects hesitate to surface unresolved conflicts because they do not want to look unprepared or politically clumsy. Delivery starts on unstable assumptions. Disagreements stay buried until they surface as design changes, delays, or audit findings.
Good stakeholder management is not about avoiding conflict. It is about putting conflict in the correct lane.
Classify the issue properly:
- design preference
- control interpretation
- risk acceptance
- funding trade-off
Then route it to the right forum.
In the lending case, there was a dispute over the use of certain cloud-native managed services. It was initially framed as a technical architecture choice. It was not. The real issue was control interpretation and whether the service fell within acceptable cloud governance patterns for regulated workloads in specific jurisdictions. Once that was recognized, the discussion moved out of the architecture aesthetics lane and into the cloud governance and risk sign-off lane, where it belonged.
That sounds obvious. In practice, teams misclassify these conflicts all the time.
Governance should make unresolved concerns visible early, not punish the people who raise them.
Phase E/F is where stakeholder management becomes brutally practical
This is the point where theory meets institutional friction.
Opportunities and solutions sound tidy in certification language. In a bank, this phase is about sequencing around regulatory deadlines, customer impact during transition, branch and contact-center readiness, procurement timing, vendor contracts, coexistence risk, local obligations, and whether the bank can tolerate the operational complexity of the interim state.
In the lending program, a phased migration by product type initially looked sensible from a technical and delivery standpoint. But compliance preferred migration by jurisdiction because local obligations around documentation, explainability, and retention varied. Product wanted the highest-volume product moved first. Operations wanted the lowest-complexity process moved first. Finance wanted the shortest dual-run period. Architecture had to mediate not just technical dependencies but operating and regulatory constraints.
The useful techniques here are very concrete:
- transition scenarios with explicit winners and losers
- dependency heat maps
- cutover rehearsals involving operations and control functions
- timeboxed exception approvals for interim states
Do not underestimate the value of making trade-offs visible. A transition scenario that clearly shows customer impact, control impact, duplicate cost, and dependency timing does more for stakeholder alignment than another polished target-state slide ever will.
Mistake #8: treating implementation governance as architecture policing
This is how architecture loses trust in Phase G/H.
The anti-pattern is familiar. The architecture board becomes an approval body detached from delivery reality. Delivery teams stop surfacing deviations because they expect pushback, delay, or sanctimony. Stakeholders only hear from architecture when something is wrong.
That is not governance. It is slow-motion disengagement.
A better model is issue-led governance. Regular conformance conversations focused on risk and outcomes. Architecture participation in implementation trade-off decisions. Post-implementation stakeholder reviews that feed lessons back into the repository and the standards.
On the lending program, one delivery team deviated from the preferred canonical integration pattern to meet an external regulatory deadline. The right response was not to reject it theatrically. The right response was to document the deviation, assess control impact, confirm residual risk ownership, and define a remediation date. The wrong response would have been to force a formal rejection and drive the team into shadow architecture behavior.
In regulated environments, exceptions are normal. Unmanaged exceptions are the problem.
How chief architects read stakeholder behavior, not just stakeholder lists
This part is harder to teach.
Stakeholder management is not just about maintaining artifacts. It is about reading behavior. You learn the signals after enough review boards, regulator prep sessions, and uncomfortable escalations.
A stakeholder who agrees too quickly often does not own the risk.
The quiet control function is often the dangerous one.
Repeated requests for “more detail” can mean many things, but often they signal low trust rather than genuine information need.
Local business enthusiasm sometimes hides enterprise platform resistance that has not surfaced yet.
And certain phrases should always make you lean forward:
- “we assumed…”
- “historically…”
- “audit will never allow…”
- “legal needs to check…”
- “that is how the last program got approved…”
Those phrases usually point to hidden constraints, inherited scars, or unresolved interpretations.
I have also learned to pay attention to what people do not ask. If operations never asks about service ownership, they may not yet understand the operational consequences. If finance never asks about dual running, they probably have not seen the transition state clearly. If internal audit is unusually silent, they may be waiting for traceability evidence rather than debating design in public.
This is the craft part of architecture. It does not fit neatly in a method diagram, but it matters.
A pragmatic operating model for stakeholder management in the ADM
If I were setting this up cleanly in a bank, I would not overcomplicate it.
The rhythm would look like this:
- pre-ADM listening
- phase-entry stakeholder refresh
- decision-focused workshops, not generic socialization sessions
- monthly concern review
- explicit escalation lane for unresolved control or funding issues
- implementation feedback loop into the architecture repository
Ownership matters too.
The chief or lead architect owns the stakeholder strategy and the hard escalations. Domain architects own day-to-day relationship maintenance and concern tracking in their areas. PMO supports cadence and logistics, but should not own the substance. Governance forums adjudicate unresolved conflicts and record outcomes.
Stakeholder management has to be distributed, but not ownerless. Ownerless stakeholder management turns into everyone assuming someone else is handling the difficult conversation.
Callout: Questions to ask in pre-ADM stakeholder interviews
- What would make you oppose this initiative?
- Which control or obligation are you most worried could be weakened?
- What happened in previous attempts that should not be repeated?
- Where do you think sponsorship is weaker than it appears?
- What transition-state risk worries you more than the target state?
- Who will be affected but is not yet in the room?
What “good” looks like in a bank
Not perfection. That is not a banking condition.
Good looks like stakeholder concerns being visible and current. It looks like decision traceability from vision through implementation. It looks like control functions shaping options early rather than objecting late. It looks like migration plans reflecting operational and regulatory reality. It looks like deviations being managed transparently. It looks like architecture governance being seen as useful, not ceremonial.
The bad signs are easy to recognize:
- late surprises
- repeated redesigns
- control objections after sign-off
- executives hearing different architecture stories from different teams
- delivery treating architecture as a hurdle instead of a source of clarity
You do not need every stakeholder to be happy. You need the right stakeholders engaged at the right moments, with clear decision rights, current concerns, and a credible path for resolving conflict.
That is a much more realistic standard.
Conclusion: stakeholder management is the hidden execution discipline of the ADM
In banking, stakeholder management is not an adjunct to architecture. It is part of how architecture survives contact with regulation, delivery pressure, budget tension, and institutional memory.
TOGAF gives you useful concepts for this, but the value does not come from filling in the artifacts. It comes from using them to negotiate live decision rights, refresh concerns by phase, tailor viewpoints to real anxieties, and route conflict into the right governance lanes before it metastasizes into churn.
The architects who do this well are not usually the ones with the best slides.
They are the ones who know whose concerns matter now, whose concerns will matter next, and how to turn disagreement into governed progress.
Frequently Asked Questions
What is TOGAF used for?
TOGAF provides a structured approach to developing, governing, and managing enterprise architecture. Its ADM guides architects through phases from vision through business, information systems, and technology architecture to migration planning and governance.
What is the difference between TOGAF and ArchiMate?
TOGAF is a process framework defining how to develop and govern architecture. ArchiMate is a modelling language defining how to represent architecture. They work together: TOGAF provides the method, ArchiMate provides the notation.
Is TOGAF certification worth it?
Yes — TOGAF Foundation and Practitioner are widely recognised, especially in consulting, financial services, and government. Combined with ArchiMate and Sparx EA skills, it significantly strengthens an enterprise architect's profile.