Architect/stakeholder inversion occurs when non-technical stakeholders tell software architects how a system should work, not what it should do. Without the “what”, software architects are left trying to guess or reverse engineer it. The resulting system may not solve the customer problem or may bloat with features attempting to do so.
Architect/stakeholder inversion is not a stakeholder wanting to move a system into the cloud to reduce costs. It is not wanting a mobile app to reach a different, younger market or offer a better user experience. It is not marketing pushing for a better analytics tool. They have business justifications.
Architect/stakeholder inversion is wanting two products integrated without saying what data to share or tasks to provide. It is creating a report engine without knowing the reports it will run. It is any framework created solely to handle nebulous requirements.
Architect/stakeholder inversion occurs due to one of three reasons. First, non-technical stakeholders feel they need to give low-level, technical requirements. Usually a sign of inexperience or frustration, the stakeholder bypasses discussion with technical details.
Alternatively, software developers may be used to implementing what they are told. This is common in environments with many ancillary roles (user experience, visual design, business analysis, copy writing, solution architecture, application architecture, agile coach, project manager, scrum master, team leader, etc) and stakeholders may take advantage of this.
Second, stakeholders often make technical assumptions and present those assumptions as solutions. They may not even realize they made assumptions.
Technical people may miss the business impacts of technical choices. However, non-technical stakeholders may miss technical impacts of business choices, too. For example, while the ongoing costs of moving to an “Infrastructure as a Service” (IaaS) or “Platform as a Service” (PaaS) provider may be lower, non-technical stakeholders may not consider the transition cost and impacts on compliance, security, jurisdiction, privacy, bandwidth and latency. The stakeholder might not have considered other benefits, such as elasticity (rapid scale up or scale down), built-in monitoring and management tools and cheap creation of test and staging environments, either.
Stakeholders with technical backgrounds may exacerbate the problem. While the technical solution requested may be good, the business context is still needed. Software architects are part of the checks and balances for the business requirements and stakeholder technical knowledge does not negate this.
Third, stakeholders may not yet know the business goals of the system. This may be driven by schedule (“We need to start coding now so that we will hit the deadline”), a misunderstanding of agile processes (“We will work it out as we go”) or a lack of preparation.
Architect/stakeholder inversion is usually solved by highlighting assumptions or providing alternate solutions. Forming these into questions (“Have we considered doing X instead of Y?”) and prototypes/spikes are effective. However, if software architects are on a “need to know” basis, stakeholders set direction solely by intuition instead of evidence or stakeholders take offence at challenges or questions, there may be wider organizational problems.
Architects and stakeholders should cooperate and respectfully challenge each other, providing greater understanding to both sides. Software architects can make better informed design decisions and glean insight into wider and future direction. The stakeholder can get a better understanding of and confidence in the solution.
That said, there are no sides here. Both the stakeholders and architects are working toward the same goal. If the organization has appointed stakeholders and architects, it realizes the value of each. Architect/stakeholder inversion contradicts this and produces a lower quality product.
Update: This post is featured in a discussion in the International Association of Software Architects (IASA) group on Linkedin.
Like this:
Like Loading...
Anthony Langsworth
@alangsworth
anthonylangsworth
Random Acts of Architecture 
Don’t underestimate the value of deep domain knowledge regardless of the source.
I agree. However, would you agree that a non-technical stakeholder (even one with a technical background) should not neglect the business context (and vice versa)? That was the article’s intent.
As an architect, I also experienced some points. Sometimes, I feel the cause is Ego. I felt, Architect is also one of the stakeholders, I go by your distinction. Sense, Coach-Player kind of relationship. Player is the one who plays on the field. Isnt it?
This is a common problem, particularly in large enterprises where you may get representatives from both the business and the IT departments involved in requirements discussions. (Whether or not they should both be in the same meetings is another point!) Often I have found this phenomenon arises from the customers trying to prove that they know what they’re talking about, and how much they know about the solution – even if they don’t.
I have come across this quite a lot as a result of ‘interference’ from the pre-sales organisation, who have gone in to the customer and liberally sprinkled around loose concepts and buzzwords amongst the smoke and mirrors needed to sell products and services to the customer in the first place.
I don’t think that there is much that can be done about this, other than to recognise that it is happening, and try to drag the conversation back to real requirements, and not solutionising when it is not appropriate. Also, architects in these requirements gathering sessions should also refrain as far as possible from designing in public – that is, not looking at a requirement and saying to the customer “Oh yes, we can deliver that by integrating the back-end using an ESB and XML payloads..” As the saying goes, that is too much information!
Thanks for the comment. I like your points about people trying to sound knowledgeable and the presales organization sprinkling buzz words. The latter seems to happen with alarming regularity. I also agree that designing should not be done in public. If discussed with a wider and non-technical audience, the design may become a group effort (“design by committee” or worse).
Anthony, really enjoyed your post on stakeholder management. It seems to me your observations are mainly about business stakeholders. Do they also apply to programmers managers and enterprise architects?
Good question. As an architect, it would be hypocritical of me to not give context with a proposal or design so, yes, this also applies to programmers, managers and enterprise architects (particularly the latter two since they deal with more ambiguity).