Agile Software Architect Role - Part 5
Business value as an architectural driver
Imagine a team tasked with building a bridge on a remote island. They go all out—using the latest materials, designing for earthquakes, hurricanes, and even future expansions. It's an engineering masterpiece.
But there’s one critical issue: no one checked if the bridge was actually needed. There's no traffic, no demand, and no real purpose. Despite the team’s incredible technical work, the project fails to deliver any value. The client regrets the investment, and the team feels frustrated, wondering, "Why did we even build this?"
The same thing happens in software engineering when we make architectural decisions without considering Business Value. We get caught up in buzzwords like microservices, complex patterns, or the latest tech trends, forgetting to ask the essential question: "Does this actually solve a business problem?"
What is Business Value?
In simple terms, business value is anything that brings measurable benefit to our stakeholders. It's not always about delivering a new feature or deploying a completed product. Sometimes, it’s about gathering insights or validating a hypothesis that enables the business to make informed, data-driven decisions. This, too, is business value.
According to scrum.org, there are five types of value: commercial value, efficiency value, market value, customer value and future value. Each of these focuses on a different area that almost every business prioritizes.
For instance, optimizing a microservice to use fewer resources could reduce costs to serve customers without impacting their experience. This is an example of efficiency value.
Why is Business Value important?
“It’s not the customer’s job to know what they want.”
— Steve Jobs
You might be asking yourself, “Is Business Value important for a Software Architect?” The answer is simple: absolutely. As a Software Architect, the decisions you make should always be justified by the business value they bring.
For example, if you choose a microservices architecture for your system, it’s likely because you’re aiming to provide extensibility. This enables your team—and ultimately the business—to grow its capabilities over time, supported by the modularity and scalability of microservices. In this case, your decision is driven by future value, as it considers the long-term growth of both the system and the business.
Here’s my personal tip: as a Software Architect, especially in an agile environment, make business value an architectural driver. Let it guide and motivate every—or at least almost every—decision you make. This approach keeps your work aligned with what truly matters to the business.
How can I address this driver?
Great question! One of my go-to tools is Value Stream Mapping (VSM). Traditionally, VSM is used to analyze and optimize the flow of value in a process. In this case, I use it to trace the flow of value through software systems and their components, connecting actors, business capabilities, and technical systems. Here’s how you can create one, in summary:
Identify the actors or users of your system.
Select the processes or business capabilities your system supports.
Map the actors to the business capabilities they interact with.
Trace the business capabilities to the systems that support them.
Decompose your system into software components—for example, microservices or serverless cloud functions like AWS Lambdas.
(Optional) Map to the object or data model.
(Optional) Map to the infrastructure.
This layered diagram makes it easy to identify the impact and value of modifying a specific software component. You’ll clearly see what business capabilities and users will be affected, allowing you to make informed, value-driven decisions.
Balancing Cost and Value
Another key approach that complements VSM is Cost-Driven Architecture. This method emphasizes balancing the cost of a decision with the value it delivers. For example:
Using a built-in cloud service might seem more expensive than developing your own solution. However, building custom code also brings hidden costs, such as ongoing maintenance, technical debt, and operational risks. Delegating these responsibilities to third-party services could align better with business goals in the long term.
As Software Architects, it’s our responsibility to identify these trade-offs and present them to the business. We must balance technical efficiency with strategic value, ensuring every decision aligns with the overarching objectives.
Getting hidden requirements from the business
I firmly believe that a Software Architect is not the smartest person in the room or team. Instead, we are the ones who empower others to shine by guiding the team toward the best decisions. Our primary role is to ask the right questions—questions that steer meetings and decisions in the right direction.
“Your job is really to make other people a little bit smarter, to help them come to better decisions, to look at their problems through different lenses, and to understand impacts and tradeoffs. That is really your role as an architect. You're an IQ amplifier for everyone else.”
— Gregor Hohpe
The people who hold the key to making decisions based on Business Value are usually on the business side. When I listen to my team asking questions to the Product Owner, I pay attention to what might be missing. If I notice important questions left unasked, I step in to ensure we gather all the necessary information to make well-informed decisions.
Tools for Extracting Requirements
Even tasks like resolving technical debt or deploying a new feature come with risks in production environments. These risks demand that our systems be resilient enough to meet business expectations. For example, understanding how resilient or fault-tolerant a system needs to be can be guided by defining two key metrics:
Recovery Time Objective (RTO): How quickly the system should recover from a failure.
Recovery Point Objective (RPO): How much data loss is acceptable in the event of an outage.
Both RTO and RPO are directly tied to the business’s non-functional requirements, which makes uncovering these requirements crucial.
Another tool I use to extract hidden requirements is the Quality Attribute Workshop. This workshop helps teams explore hypothetical scenarios, often edge cases, to uncover the information needed from the business. For example: Imagine you’re tasked with designing a URL shortening service. During the workshop, you could ask:
"If there’s a performance issue, is it equally critical to ensure the capability of registering a new URL as it is to forward requests using short URLs?"
The business’s answer to this question might lead you to implement a CQRS pattern or another architectural strategy. By using tools like this, we can ensure our technical decisions align with business priorities and deliver real value.
Business Value Changes as Requirements Evolve
In the first post of this series of Agile Software Architect, I mentioned the importance of being open to change—and this applies equally to Business Value, which evolves over time.
“Responding to change over following a plan.”
— Agile Manifesto Value
For example, I recently encountered a situation where the business decided to pause all production deployments for a specific period due to a critical and high-profile event. Their risk appetite was practically zero during that time. From IT, we had already developed a small change that could reduce resource costs, but deploying it carried risks that the business was unwilling to accept. In that moment, their non-functional requirements shifted to:
"We need system stability above all else; any improvements can wait."
After the event passed, their requirements shifted again, and we resumed delivering improvements. This experience reinforced a key lesson: Business Value is not static. It changes as priorities and circumstances evolve.
As architects, we must understand that requirements will always change. To maximize value and meet expectations, we need to actively listen to the business and ensure we remain aligned with their needs. Strong communication and collaboration between IT and business are essential to achieving this alignment and ensuring success.
Final Thoughts
As Software Architects, our primary responsibility is to align technical decisions with the evolving needs of the business. This means being adaptable, asking the right questions, and ensuring that every decision we make delivers the maximum possible value. Whether it’s uncovering hidden requirements, balancing trade-offs, or responding to changing priorities, our role is to bridge the gap between IT and business, fostering collaboration and trust.
Business Value is not static—it’s a moving target influenced by circumstances, priorities, and risks. By maintaining open communication, leveraging tools like Value Stream Mapping and Quality Attribute Workshops, and understanding non-functional requirements, we can ensure that our architecture decisions are always grounded in what truly matters: delivering value to stakeholders.
Ultimately, being an Agile Software Architect isn’t about following a rigid blueprint—it’s about staying aligned with the business, embracing change, and helping the entire team succeed. Remember: the best architectures are not just technically sound—they’re designed to support and adapt to the ever-changing goals of the business.