Projects rarely die only because of a bad technical decision. Quite often they die because someone did not get information they needed, or was never asked for their opinion. I have seen both from close up.
The first two articles in this series argued that a system copies the communication channels of the temporary project organization formed by client and vendor, and that you only get to know that organization by walking through it more than once. This article is about what to do with the people you meet on that walk: how to classify them, how to decide who is informed, who is consulted and who decides, and why one of those questions can move the boundaries of your system.
Two failures, one pattern
Two short stories from my own practice.
A short discovery engagement. The client had a strong idea for a product and a CTO on their side. We had one or two rounds of calls to understand the domain and the problem, and from my perspective everything was clear. A colleague and I spent two to three weeks on solid work: the architecture was well thought through and the document was almost finished. After three weeks an escalation reached our management: we were working badly, we did not know how to work, and the client wanted to end the contract. When we looked at what happened, it turned out the client had not been informed about our progress at all. The engagement ended at discovery and never moved to implementation.
A small internal sales tool. A founder and CEO who came from sales ordered a simple CRM-style application for their sales team. They knew what was needed and worked with us closely, and we built it. The sales team did not want to use it and raised problems, some artificial, some real. We had never consulted the ideas with the people the application was for.
In the first case the missing piece was informing. In the second, it was consulting. Neither of them was caused by technology.
Mapping the people: power and interest
The classic tool for the first question is a stakeholder map with two axes. Its roots are usually traced to A. L. Mendelow’s work on stakeholders and environmental scanning, which linked how an organization watches its environment to the power of each stakeholder relative to the organization (Mendelow, 1981). Today it is mostly used as a simple grid: influence (or power) on one axis, interest (or importance) on the other.
Tanusree McCabe describes the four quadrants from an architect’s point of view (Fundamentals of Enterprise Architecture, pp. 61-63):
- High influence, high importance: key stakeholders, engaged from the start, invited to meetings, reviewing documentation, getting frequent updates.
- High influence, lower importance: keep them aligned with occasional check-ins and briefings at milestones, because their dissent can block the work.
- Low influence, high importance: keep them informed, because they will be noisy if left out, and their support is better than their resistance.
- Low influence, low importance: notify them when a decision affects them.
How I use it in practice: when I walk an organization, I like to build a general stakeholder map early, to understand who is who, whom to talk to, whom to inform, whom to ask for an opinion and whom to ask for a decision. From an architect’s point of view, the most valuable groups for requirements are the ones with high interest, both with high and low influence. They give you the functional requirements, and you can also ask them about the non-functional ones.
The other groups cannot be skipped. If they are not informed about the state of the project, where we are and what we are doing, the project can be killed only because someone did not get information from us. That is exactly what happened in the discovery engagement.
One map is not enough: RACI per epic
A stakeholder map works at the level of the whole project. In a larger system, each epic or feature tends to involve slightly different people. The sponsors stay the same, because someone pays for the project and owns the budget, but the people who know and care about a given epic change.
For that I use a second tool, the RACI matrix:
- Responsible: who does the work.
- Accountable: who takes responsibility for the decision.
- Consulted: who must be asked before the final decision.
- Informed: who should simply be kept up to date.
McCabe adds the rule that makes RACI useful: for every activity there must be exactly one accountable stakeholder and at least one responsible one. Shared accountability diffuses and weakens authority. She also recommends treating the RACI as a transparent artifact and confirming it with the people in it, so they can say whether they are the right stakeholder at that level of involvement (Fundamentals of Enterprise Architecture, pp. 64-65).
For simple projects one RACI can be enough. For larger ones, in my practice, the RACI for each epic can look different.
A fair warning from Diana Montalion: RACI by itself is a management sign-off process. It assumes that people higher on the ladder give the best feedback on systemic reasoning, which in her experience is not always true (Learning Systems Thinking, p. 136). A RACI tells you who must be asked. It does not tell you that the answers will be good. You still need real conversations, and the walk from the previous article, to get them.
The vendor belongs in the RACI too
Here I build the RACI slightly differently from the stakeholder map, and it connects directly to the first article. When our team enters an organization, the software house or technical team and the business become one organization in the sense of Conway’s Law. So the technical people also carry responsibility, and they belong in the matrix.
Business should be accountable for business features, because the business takes responsibility for what is built and how. Some decisions are technical, for example integrations between systems or with external systems. Those are decided by the architect or a developer, and it is worth consulting a CTO or an enterprise architect on the client side, who sees the wider landscape.
McCabe’s generic example has the same shape: the architect accountable for the analysis behind a decision, an engineering lead accountable for approving it from the engineering perspective, a product lead accountable from the business perspective (Fundamentals of Enterprise Architecture, pp. 64-65).
For a client choosing a vendor this is a useful test. If the vendor’s people never appear in the RACI, nobody on the vendor side is accountable for anything except tickets.
Who owns the customer? When ownership moves system boundaries
In theory, both tools look simple. In practice, some things are very hard to map, and the hardest are often about data.
A typical scenario: you ask the organization who owns customer data. Finance says it is theirs, because they issue the invoices. Operations says it is theirs, because they work with the customer every day. This is a classic data ownership problem, and if you discover it during the walk, it is very important to establish who really owns the data. A wrong call here can significantly shift the boundaries of the system and the split into bounded contexts.
Domain-Driven Design explains why. In Martin Fowler’s summary of Eric Evans’s idea, a bounded context divides a large system into parts with their own unified model, because different contexts may have completely different models of common concepts. Customer and product are the recurring examples (Fowler, 2014). Finance’s customer and operations’ customer may simply be two different models.
Ford, Richards, Sadalage and Dehghani show the technical side: once data is split, tables must be assigned to the services that own them, and a table becomes part of the bounded context of its owning service. Ownership gets complicated quickly when several services write to the same data (Software Architecture: The Hard Parts, ch. 9, p. 251). Zhamak Dehghani’s data mesh principles push the same logic into analytics: data should be owned by the business domains that produce it, following the seams of organizational units (Dehghani, 2020).
Put together: an ownership argument between two departments is an architecture decision in disguise. The RACI question “who is accountable for customer data?” and the design question “which context owns the customer?” are the same question asked in two rooms.
The email that would have prevented a steering committee
To sum up briefly. Besides talking to the people who give us features and functional requirements, we as architects have to take care of communication with the people who should be informed: those who fund the project and watch the deadlines. They in turn have to report to their own boards. If we do it badly, or simply stay silent, frustration builds up, and steering committees appear that could easily have been avoided with a simple email.
For a decision-maker hiring a vendor, I would turn this into a few expectations:
- A stakeholder map early in the project, shared with you, so you can correct it.
- A RACI for the epics that matter, with the vendor’s architect and developers in it, and one accountable person per decision.
- An explicit decision on ownership of shared data before the system boundaries are drawn.
- A regular, boring status update for the people in the “keep informed” quadrants.
None of this needs special tools. A grid on a whiteboard, a table per epic and a short email do most of the work.
The next article in the series looks at the moment when someone inherits a system and asks “who broke this?”, and at why architecture needs to record why a decision was made, not only how the system works.
Sources
- A. L. Mendelow, “Environmental Scanning: The Impact of the Stakeholder Concept”, ICIS 1981 Proceedings.
- Tanusree McCabe, Fundamentals of Enterprise Architecture, chapter 3 “Shared Alignment”, pp. 61-65.
- Diana Montalion, Learning Systems Thinking, chapter 8 “Designing Feedback Loops”, p. 136.
- Martin Fowler, “Bounded Context”, 2014 (on Eric Evans, Domain-Driven Design).
- Neal Ford, Mark Richards, Pramod Sadalage, Zhamak Dehghani, Software Architecture: The Hard Parts, chapter 9 “Data Ownership and Distributed Transactions”, p. 251.
- Zhamak Dehghani, “Data Mesh Principles and Logical Architecture”, martinfowler.com, 2020.
- Case material: Piotr Filipowicz, Walking Talking vlog episode on stakeholder maps and RACI, own experience as solution architect at Arpeggia.