How to Have More Effective Conversations with Business Stakeholders About Software Architecture

"Almost every problem in software development is fundamentally a communication problem."

- Thomas Betts

Development teams have a challenge when they need business support for technical decisions: business people don’t really care about technology. They might care about what it can do for them, or for their customers if you can explain it succinctly, and quickly. As technology has penetrated nearly every aspect of life, at least you can rely on a basic user-level knowledge of technology, but even this can cause some discussion challenges because what users see are systems that largely work, not the underlying mess that often just barely works.

Most of the time this isn’t a problem, with a few big exceptions: when you need a decision that needs business support in terms of funding, product direction, or business policies and processes. Technology often comes with side effects that can dramatically improve products but require changes to the way the business runs, or the way it interacts with customers, which business stakeholders need to understand and embrace. With these benefits also come significant costs. If you can’t explain them in ways that business stakeholders will understand, you won’t be able to build the support you need for the change.

Trust and transparency foster effective communication

The idea that "the business" is a "customer" of IT creates many problems, not least of which are that it causes IT to lose sight of the real customer, it makes IT subordinate to the business, and it creates an arms-length distrustful relationship between the two parties. Forced separation between business and development organizations creates the illusion that win-lose is possible. In reality, if it’s not win-win, it’s lose-lose.

This latter dysfunction often arises out of discussions of cost and time for projects. The scenario usually plays out like this: the business says they need some solution to a problem they don’t fully understand, and they provide a partial list of features that may or may not really be needed. IT takes the bait and responds with a good faith but completely imaginary estimate of cost and time based on their interpretation of what the solution to the presumed problem is, incorporating the partial lists of potentially irrelevant features.

IT wraps this estimate in enough caveats to deflect any blame if their assumptions turn out to be wrong, but like an eager child unwrapping a birthday present, the business tears away all the caveats and only remembers the cost and budget estimates which then become enshrined in the program management system.

This budgeting and estimation approach, and its variations, establish foundations of mistrust on both sides. The two parties can’t hope to achieve trust and transparency until they can have credible discussions about cost, and the first discussion they ought to have is that both the cost and time estimates are bogus. The initial requests are usually so lacking in useful information that no credible estimates could be derived from them, but when IT is subordinate to the business they don’t feel they can challenge the request. By responding to it, they endorse and reinforce the approach.

The problem is that most "requirements" are not valuable, but you don't know which ones are valuable. Estimating all the potential scope leads to cost and time estimates that are unreasonably high and create contention. A better starting point, and a way to build trust and encourage transparency, is to first agree that there are no "sides" in collaboration, that business and IT need to work together to develop the best solution they can. When both parties work together on the business case they better understand the business opportunities and potential benefits. This helps them to understand what they want or need to achieve and what benefits they might obtain if they can do this.

Doing this has several benefits:

• It leads to healthy discussions about desired outcomes and what success looks like;
• It establishes, through financial modeling, an upper threshold of what they can spend and still maintain their desired profitability goals, and
• It gives them practice working together that can lead to better trust and transparency.

One challenge in estimating time and cost, at least for complex work, is that the solution can’t be defined without building and testing some portions of it. Doing so will inform better solutions as well as a better understanding of the problem. It also informs better estimates of the cost and time frames for building the solution. A previously published article about the role of experimentation in making better decisions explores this more completely.

You can’t achieve trust and transparency until you can have credible discussions about cost. You have to involve the business stakeholders in decisions about cost by having transparent discussions about benefits and costs framed in terms of outcomes. Having open conversations from the beginning of an initiative helps to build the trust and transparency, and empathy that are essential for difficult discussions about trade-offs and alternatives that inevitably happen when an organization is trying things they have never done before, as most big programs do.

Frame scope discussions in terms of business  outcomes

One big barrier to effective conversations about technical decisions that need business input is that development teams and business stakeholders speak different languages. To be more precise, when techies talk about technology, business people tune out. What they need to do is frame discussions in terms of how technical choices will affect business outcomes - something business stakeholders do care about.

In an earlier article about technical debt, we discussed how technical debt is a metaphor that helps business people understand technical decisions. The metaphor helps, to a point, but an even better approach is to describe how addressing a technical issue will enable the organization to achieve a business outcome that they could not otherwise do. Or how not addressing a technical issue will impair the business outcomes that the organization can achieve.

This conversation works both ways. When there is a major shift in business priorities, such as the organization deciding to exit a specific market, or needing to respond to regulatory mandates, describing the shift in terms of business outcomes helps everyone understand the impact. Focusing architectural decisions and designs on the outcomes they deliver, rather than the features that comprise the design, helps everyone to better express and communicate how the architecture needs to change to meet the changing priorities.

In an earlier article, we talked about using Quality Attribute Requirements (QARs) to capture important capabilities that the system must be able to achieve. QARs are expressions of business outcomes that the system must enable. We prefer a "stimulus, response, and measurement" format. Using a trade finance example, a performance-related QAR would be expressed as:

When a letter of credit specialist processes a payment request following acceptance of documents from an exporter,
The system will respond by sending the payment to the exporter’s bank and debiting the importer’s account.
The following will be measured: The end-to-end payment transaction time does not exceed 5 seconds.

Framing QARs in terms of business outcomes helps to establish the common language that development teams and business people can use to talk about important things that the system must be able to do.

Example: Talking about Security

Security is a challenging topic to discuss. Like discussions of hurricane preparedness, security issues tend to only get attention when there is a crisis, and when that crisis passes, security-related initiatives are no longer considered a priority and become harder to fund.

Discussing specific vulnerabilities usually requires very specialized knowledge that even many developers and architects lack (or the vulnerabilities would not exist), so discussing them with business stakeholders is even more challenging. But while most business stakeholders won’t grasp the technical nuances of a vulnerability, they can understand the potential outcomes that a vulnerability may cause. Discussing the need to patch a memory leak in a particular open-source framework is not as compelling as discussing the need to prevent the loss of sensitive customer account information (that, if it occurs, may be widely reported in the press and very costly to the company.)

In these conversations, business stakeholders are likely to initially say that no loss of customer information is acceptable, but they also say that they can’t afford the time or investment to conclusively eliminate all possible vulnerabilities; they are clearly willing to accept some level of risk if you can find a way to frame the conversation.

To have more meaningful discussions, include probability and impact information as part of the outcome discussion. An outcome that has a million-to-one chance of occurring and has a minor financial impact might not need to be addressed, whereas an outcome that has a hundred-to-one chance of occurring and could result in an impact on a regulatory filing or annual report can’t get fixed fast enough.

Software Architecture is the hidden part of the Application iceberg

A helpful metaphor for having conversations with business stakeholders is to think of your application as an iceberg. Your business stakeholders only see what’s above the water, and most of your application is invisible to them. In order to have a conversation about architectural issues that are invisible to them, you have to relate your concerns to something that is visible to them.

In a series of prior articles, we introduced the concept of a Minimum Viable Architecture (MVA), which supports the architectural foundations of the Minimum Viable Product (MVP). The relationship between these concepts using the iceberg metaphor is shown in Figure 1. The MVP is visible to business stakeholders, while the MVA is usually invisible to them. Business stakeholders may not care about the MVA, but they do care about QARs and business outcomes that the MVA will enable. Therefore, try to frame your technical discussions with business stakeholders in terms of QARs and business outcomes that they feel the system needs to deliver.

Figure 1: MVPs are what stakeholders care about, but they rest on a hidden architectural foundation

Every conversation with a business stakeholder turns into a conversation about money. Come prepared.

Discussions with business stakeholders uncover an unpleasant reality: talking about money makes IT uncomfortable, and business stakeholders only want to talk about money. Adding parties such as project managers to help with the money discussions only makes things more complicated and confusing. The reason why it’s important to frame discussions in terms of business outcomes is that doing so provides a way to talk about what business stakeholders really care about, money, but in a way that still links the MVP and MVA parts of the application.

Traditional budgeting is a red herring

In the early part of this article, we talked about why the traditional budgeting approach fails: because it creates estimates that have become disconnected from the business outcomes that the organization wants or needs to achieve. Retaining the connection to business outcomes is an important way for everyone to continue to have meaningful conversations about what applications need to, and don’t need to, do.

MVPs based on desired features are almost always a trap. The features might not be needed, and might not provide the desired outcomes. Most features are irrelevant; the problem is you don’t know which ones are useful. It’s better to toss them out and focus on outcomes. Build a small increment, deliver it and measure the outcomes.

Traditional budgeting, based on a dubious list of features that may or may not be relevant (and most aren’t) distracts everyone from the real issue: determining the minimum amount of expenditure that will achieve the desired outcome. Usually, it’s not possible to know this without doing a little exploratory work, but after some experimentation, the organization will have a better idea of whether the idea is financially feasible/desirable.

In many ways, most business people already know the budgeting process is broken. One finance director expressed his skepticism about claimed project benefits: "If we summed all the claimed benefits of all the projects we funded this year, the numbers would exceed the annual revenues of the company." This was his way of saying that most benefits estimates are not credible, but we’ve heard similar things said about cost estimates. This lack of credibility on both sides creates an opportunity to work in a different way.

What stakeholders really care about: Cost-Effectiveness

Cost-effectiveness is an oft-overlooked but critical Quality Attribute that helps teams make better architectural decisions. Most companies, particularly financial companies, are concerned about the cost of their IT function, especially if they happen to operate in the retail sector (e.g., retail banks, personal insurance carriers), yet few teams explicitly design for cost-effectiveness. As a result, they could create an application that is too expensive to run and maintain. Failing to consider cost-effectiveness may also lead them to late-lifecycle architectural changes to deal with poor cost-effectiveness.

In the physical world of buildings, bridges, and ships, architects routinely propose several options to their customers based on cost-effectiveness and trade-offs in either QARs or achievable outcomes, or both. The same is true of designers working on everything from aircrafts to microchips. All clients are cost-sensitive, regardless of their domain.

When working on novel challenges, in which the organization does not really know what things they need to do to achieve particular customer outcomes, detailed estimates of cost are not possible. In order to move ahead, technical and business stakeholders need to work together, incrementally, to make decisions and trade-offs that will produce a cost-effective solution.

Cost thresholds can help teams make better decisions

Here’s one way to approach the problem, especially in the early discussions about opportunities, outcomes, and cost: Consider a company that has identified an opportunity that they think will result in an additional $100 million if they can satisfy a particular unmet customer outcome. If the company expects that it will obtain at least a 20% profit margin, this means that the total of all their expenses in delivering the outcome cannot exceed $80 million (we're ignoring the time-value of money for the sake of illustration.) Let’s assume that, at least initially, it does not know whether it can deliver the outcome or how much it will cost; it simply knows how much customers might be willing to pay for it, and the maximum amount the organization would be willing to pay to achieve it. We call this amount the cost threshold.

Cost is always a factor, especially from the business side, but is sometimes ignored when developing solutions. As developers explore different alternatives for the solution, knowing this cost threshold helps them to make better trade-off decisions. If they find that a particular choice is leading toward exceeding their cost threshold, they know that they need to make a different choice. Suppose that they find that no solution can be delivered beneath the cost threshold. In this case, they have a responsibility to share this concern as early as possible so that the organization can choose to pursue different opportunities. Understanding the cost threshold also helps developers make choices that can improve profitability without compromising the outcomes the solution delivers.

Shared decisions help to improve working relationships

The cost threshold makes conversations about cost-effectiveness easier in ways that traditional budgets cannot. As we discussed above, the budget often represents an estimate that is based on assumptions that are often incorrect. Staying within the budget while not achieving the desired outcomes is always a bad thing, and exceeding the budget while achieving the desired business outcomes might be a better thing, but based on the budget alone no one can tell.

A cost threshold expresses, from a business perspective, that it’s undesirable for us to pursue these business outcomes if it costs us more than the cost threshold. Since this is a language that both technical and business people can understand, they can have meaningful conversations about whether they should even pursue a particular set of business outcomes - maybe they would be better off working on some other opportunity. That leads to healthy discussions about what opportunities in the portfolio should be pursued based on a combination of their benefits and costs.

Having open conversations about these questions helps business and technical people to work more effectively, together, to decide what they should work on, together.

Developing transparency and trust in early conversations about the cost threshold has benefits later on, when teams need to make architectural trade-offs that affect cost and the ability for the solution to satisfy QARs. An example illustrates the point:

A development team is evaluating a build-vs-buy decision for the foundation of a possible solution. They have found a package that has many attractive capabilities, but it cannot satisfy all the QARs that the business stakeholders believe is essential for the solution to achieve the desired business outcomes, at least not without significant modification. Those modifications would cause the cost threshold to be exceeded.

The development team and the business stakeholders have a conversation about the QARs and they jointly decide that some of them are too stringent and can be relaxed. They document the change in the QAR, but the development team also makes a note in their ADR to record that if the QAR changes back to the original, the cost threshold will likely be exceeded.

As they continue to work on the system, both business stakeholders and the development team need to continually revisit their assumptions about their QARs based on new information that they learn as they develop and test the evolving system. If these assumptions change, they may need to evaluate the viability of their current direction and correct course, if they can.

Using QARs and the cost threshold works at multiple levels: when making basic decisions about the foundational choices of the solution, as in the example above, but also in making day-to-day trade-offs between different alternatives. At each decision, people need to ask themselves two questions: (1) will the choice we are considering prevent us from achieving the desired business outcome(s) and associated QARs, and (2) will the choice we are considering cause us to exceed the cost threshold?

Many MVPs look promising at first, but unconsidered costs can so burden a product that it eventually collapses under the weight of unsupportable lifecycle costs. The challenge of architecting is to build a solution that stays within its cost threshold for its entire intended lifespan. In fact, one indicator that it’s time to retire a product is when you can see that the solution can no longer be operated within its cost threshold.

Architecting is about managing trade-offs; talking about the trade-offs in meaningful ways can be challenging

Organizations sometimes make implicit trade-offs they don’t fully understand at the time they make the decision. Examples of this include:

• Building the MVP on technology that enables the organization to reach the market quickly but which won’t satisfy essential QARs, such as using a low-code development tool that won’t scale to desired levels of workload, or can’t satisfy critical security QARs.
• Ignoring scalability concerns in the early design work by assuming that moving the application to the cloud will solve any unhandled scalability issues.
• Only focusing on online user experience concerns and ignoring large-scale operational issues that are themselves, ultimately, also user experience concerns. Examples of this include focusing too much on something like ordering a product and not enough on all the things that happen between the order confirmation and the customer getting the product.

Solving these sorts of lifecycle problems means being able to effectively talk about issues that can become deeply technical, but with people who may not be deeply technical. Focusing on QARs and desired business and customer outcomes helps provide a common basis for understanding. The last point above emphasizes the importance of understanding how IT and the architecture of the solution affect many different people and needs to support a complex process that involves many different parts of the business.

Patients encounter similar challenges when they discuss alternative treatments with their physician: patients typically don’t have the medical background to understand the details of the procedure, but if their physician focuses on outcomes, they can have a meaningful discussion about the short and long-term impacts of different alternatives on the patient’s desired outcomes.

In the architectural decisions example, framing the technical decision in terms of how it might affect the ability of the solution to meet, or not meet, important outcomes and/or QARs provides a common language for the discussion. As part of this, any impact on the cost threshold should be discussed as well, including the possible cost of reversing the decision if there is some likelihood for that happening. That way, everyone understands the potential implications of the decision.

The details of the proposed solution aren’t really important, it’s how they will affect outcomes and QARs that matter to business stakeholders.  The result of these discussions, the architectural discussions themselves, are documented in ADRs, which need to include a summary of the outcomes/QAR discussion in order to preserve the context of the decision.

Involving business stakeholders in critical architectural decisions, at least when framed in terms of outcomes and QARs, has an important benefit: it makes discussions that involve changing or reversing decisions easier because everyone was party to the original decision and so everyone "owns" that decision. It dramatically reduces the discussion devolving into a blame game.

Some architectural decisions, of course, are too small to discuss with business stakeholders. If a decision doesn’t materially affect the cost threshold or the ability for the solution to achieve outcomes or satisfy QARs, it’s not really relevant to business stakeholders and development teams can make the decision on their own.

Example: Discussing scalability decisions

As noted in Continuous Architecture in Practice, "Scalability can be defined as the property of a system to handle an increased (or decreased) workload by increasing (or decreasing) the cost of the system." Architectural decisions for scalability can have a significant impact on deployment and operating costs and may require tradeoffs between scalability and other attributes, such as performance.

Figure 2 illustrates how scalability concerns affect cost as well as several other QARs.

Figure 2: Scalability–performance–availability–usability cost relationships

Scalability is technically complex, and that complexity is hard to communicate to business stakeholders. Business stakeholders may believe that scalability (and performance) issues can be solved by throwing money at the problem (buying more capacity, e.g. "put the system in the cloud", or "Amazonification"). They may think that they can safely ignore scalability concerns because the cloud provider will handle them. In fact, a poorly designed system that does not scale well in a proprietary environment is not likely to scale well in a commercial cloud without significant design changes, or at significant cost.

Meeting scalability QARs, as Figure 2 suggests, means making a complex set of trade-offs that have implications on the ability of the system to satisfy business outcomes and QARs while staying inside the cost threshold.

Your first challenge in having conversations with business stakeholders is nailing down their scalability requirements, which they may not have thought much about, or they may not know enough yet. You can live with this for a while, so long as you do not have to make decisions that will be costly to reverse. Simulating the effect of large workloads on the MVA will provide you with insights into its scalability (and performance) as well as information that will help inform better conversations about scaling needs.

Conclusion

Ultimately, business stakeholders seem only to care about money, but that’s not completely true. They care about profit, and by making money discussions only about cost, development teams constrain their ability to have healthy conversations about trade-offs that can help them develop better solutions.

Development teams can improve the quality and effectiveness of their conversations with business stakeholders by shifting their approach. First, they need to avoid wasteful budget discussions that are based on incomplete and incorrect assumptions about the solution to a problem and shift the focus of conversations to focus on the business outcomes and QARs that the solution needs to meet. Both parties need to then talk about how valuable these outcomes are to achieve, and how much the organization can afford to spend, at maximum, to achieve these outcomes (i.e. the cost threshold to achieve the outcomes).

Once started down a more effective path, development teams should continually focus on staying within the cost threshold, and even lowering it while raising issues early when they think they might approach or exceed it. Resulting discussions with business stakeholders about trade-offs will help everyone make better trade-off decisions.