Random Acts of Architecture

Tales of an architect trying to bring order to the chaos that is modern information technology.

Tag Archives: requirements

Architect/Stakeholder Inversion

Stakeholder Architect InversionArchitect/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.

Handling Challenges to Architectural Decisions

One of the most critical aspects of a software architect’s job is the initial high-level design. Based on customer requirements and the architect’s own non-functional requirements, this is where development starts from. It is also written when the development organization knows the least about the problem and so issues often arise as the development team works it.

Challenges are inevitable. It is important is not to panic and not to take it personally. The architect’s goal is to get the best product, not necessarily his or her product. Therefore, first get the other person to explain their issue and reasoning. Common scenarios include:

Different understanding of requirements:  All major analysis and design discussions around the product should involve the architects. (If not, then this indicates possible broader organizational issues.) Explain the decision’s rationale and ask if that matches the other person’s understanding. One or both of you will probably learn something in the ensuing discussion.

Proposes a better solution: Has the person raising the issue tried it before? Did they use a different tool or technique? Do some research to see whether others have had similar problems and their solutions. A small proof of concept is almost always helpful. Non-functional requirements, such as scalability or integration with other systems, are often the deciding factors.

Use an existing solution: This is often a difficult issue. If the person raising the issue was involved in the “better” solution, he or she may take this personally. Explain why it was not selected and work through the decision-making process. It is easy for developers (and architects) to apply their previous work beyond its design goals, even when it is no longer appropriate. However, existing solutions may save time and effort, help standardize products and are politically safer choices.

Resourcing or deadlines: The architect should understand the current and near future resource allocations, such as looking at the Scrum backlog, and do his or her own estimate of resource requirements because this is often an excuse given when the development team feels a task is not in their best interests. The important question here is prioritization rather than total work, so the architect should work with the customer to deprioritize tasks if needed.

Non-technical reasons: Sometimes decisions have to be made quickly, such as to meet changing market requirements or an unexpected opportunity, or people have conditions imposed upon them, such as head count reassignments or reductions. Those in senior positions do not have to justify their decisions but an explanation (usually discretely from a trusted source) may be invaluable. Politics is a fact of life and organizational awareness is important for architects, even if they choose not to “play the game”.

Before considering a solution, what is the impact of the change? Are other components affected? If so, do those teams have the bandwidth to make the changes? Also, does the change use a familiar, proven technology or is it speculative. Each organization has it’s own level of risk tolerance. Clearly, the larger or riskier a change, the more likely to go through a formal change control process. Assuming it is not clearly in that area and a change is warranted, solutions include:

Accept Change: You are only one person and there are always people smarter than you, people more familiar with the problem than you or just luckier. Assuming the impact is acceptable, make the change, communicate it and move on. In the long run, admitting mistakes will earn you more respect than defending the indefensible. If the change is small or low risk, even if it is a worse solution, it may be easier just to accept the change and move on because it gives others a more personal investment in the design.

Compromise: The solution is what neither of you are proposing or bits of both. Although almost cliche, finding a solution that keeps the important aspects of the original design and the person raising the issue happy is best. The architect must be open-minded even if others are not.

Delay: Sometimes the issue raised requires a change that is simply too large to accomplish with the remaining time and resources. In that case, add it to the requirements for the next version.

Escalate to Customer: If there is a disagreement about customer requirements, often the best solution is to take the question to the customer, such as the Scrum product owner. Remember to put this in terms the customer can understand, emphasizing the impact on users. The area may not have been covered in detail and so require more investigation.

Escalate to Management: Perhaps a team is demanding changes that would make their component easier but have a great impact to the rest of the product. Perhaps an external team is demanding changes without an adequate business purpose or return on investment. In this case, it is best to escalate this to the appropriate level of management if no compromise is possible.

Note that infrequent escalation to management or the customer is not a sign of failure. Indeed, involving them in the project can give them much-needed updates and let them know problem areas.

Lastly, do not forget to capture and communicate details of any changes. This may be a short announcement at the next team conference call, entering something into a change log and/or updating the original high level design documents.

No matter how thoroughly an architect researches and presents the high-level design, there will always be those who disagree. Sometimes, it is important to distribute the high-level design to air decisions and elicit feedback. Sometimes, deadlines dictate a incomplete design must be used. Sometimes, someone just wants to prove they know better than the architect. Remember that “architect” is a role, not a rank, and reacting well to challenges may speak more to an architect’s ability than the architecture itself.

%d bloggers like this: