For most of us, smartphones replaced paper maps long ago. You enter your destination, and it presents you with multiple potential routes. Given one route is often fastest, why bother?
The smartphone may not have all the information, such as weather or traffic. The phone does not know that an alternate route may be faster.
Perhaps the environment changes after navigation starts. Having a prepared alternate makes switching routes easier.
Speed may not be the crucial attribute. Maybe the driver wants the psychological safety of a familiar but slower route. Maybe one route is more enjoyable and scenic. Maybe the driver wants to shop on the way.
The fastest route may also have variability or risk. Maybe a football game at the local sports ground will finish soon. If time is tight, the time of a slower route may be more predictable and, therefore, better.
These reasons also apply to IT architectures at any level, whether technical/component, solution or enterprise.
The problem is most IT architects come from an implementor background, like software developers or network engineers. Good implementors build complex and deep mental models of their systems. These models allow implementors to both isolate issues and plan small to moderate changes quickly and effectively.
Organizations incentivize implementors to make changes quickly and with low risk. Having a good mental model facilitates that. The sooner an implementor can envisage and choose a solution, the sooner they can implement it and the sooner it can ship. This speed inspires confidence and provides technical leadership.
However, architects need to think differently to implementors. They still need higher-level mental models but should think more strategically (“Are we solving the correct problems? Is the solution complete?”). IT architects also need to think politically (“How do I convince stakeholders of the solution’s value and my value?”).
An architect should own all technical solutions in a business problem space. Providing a single solution implies the architect owns the solution, not the problem space. Subsequent design changes, even improvements, may diminish the architect’s credibility.
Focusing on a single solution alters how people justify them. The more assured people are that a solution is best, the less strongly they argue for it. They lose empathy with others to whom the solution’s merits are less clear. They often think beyond the design and evaluation stage and are frustrated when yanked back. Alternatives contrast and identify the solution’s pros and cons.
Providing multiple solutions helps generate discussion. Stakeholders may have differing preferences. Presenting different solutions, like playtesting a game’s rules or A/B testing a website, can draw out these preferences and derive the best solution. Stakeholders are customers.
Creating good alternatives and fighting an implementor’s instincts is difficult. The trade-offs are situation- and stakeholder-dependent.
That said, most organizations treat IT purely as a cost. Therefore, the biggest concern in any IT system is cost, including staff, time, and money. Create alternatives that minimize one or more of these by dropping, substituting or minimizing features.
Never sacrifice quality when creating alternatives. Stakeholders, particularly executives, are often not accountable for maintainability, security, availability, and the like. If they are not accountable, they do not care. For those that are accountable, quality is hard to quantify or demonstrate, so executives almost always delegate it.
Another alternative source is the “shortest path to value” (SPV). SPV identifies small projects within large ones with the biggest “bang for buck”, embodying the Pareto principle or 80:20 rule. SPV reduces otherwise massive projects that are hard to scope or have high schedule risk, making them more concrete and predictable.
Consider implementing the project using different technologies (tools or frameworks) or teams. Another team, even if only hypothetical, may take a different approach. Using or avoiding the technology de jour also opens possibilities. A greenfield project has advantages and disadvantages over non-greenfield projects.
Re-examine constraints or “bad ideas”. Even “hard” constraints are sometimes malleable. People often shun anything close to bad ideas. However, unrecognized good ideas often surround bad ideas.
Providing a single “best” solution undermines the architect’s credibility and removes agency from stakeholders. Like smartphone navigation, an IT architect often lacks full knowledge, may not grasp all requirements or environment, or solutions may provide unexpected opportunities for stakeholders. The biggest barrier is frequently identifying good alternates.
However, the biggest reason why alternatives are so powerful is IT architects need to differentiate themselves and sell their role. IT architects are not accountable like managers or responsible like implementors. Their value proposition is technical insights and good designs. Creating, evaluating and comparing the alternatives provides those insights and demonstrates the superiority of that design.
Image is from https://pixabay.com/illustrations/arrows-alternatives-many-direction-3438123/.