Discover the Business Goals
Every software system is built to serve some fundamental purpose. Business goals describe what stakeholders hope to accomplish with the software. Business goals also seed conversations about quality attributes, trade-offs, and technical debt.
Business goals are a primary architectural driver and help prioritize competing concerns. The better everyone understands stakeholders’ needs, the better you’ll be able to help them. Here’s a summary of common business goal categories:
Who wants it | What they want |
|---|---|
Individuals | Increase wealth, power, reputation, personal enjoyment, or knowledge |
Organizations | Increase revenue, maximize profits, grow the business, become a market leader, improve stability, enter a new market, beat a competitor |
Employees | Interesting and meaningful work, increase knowledge, help users, become recognized as an expert |
Development Team | Improve specific quality attributes, reduce costs, add new features, implement a standard, improve time-to-market |
Nations, governments | Security, civic welfare, social responsibility, legal compliance |
Capture business goals as simple need-based statements that explain what stakeholders will get from the software system.
Record Business Goal Statements
Great business goal statements are measurable and have clear success criteria. Human-centered business goals allow your team to understand the people you are ultimately serving through the software you build.
Good business goal statements include three things:
- Subject
-
A specific person or role. If the stakeholder or group has a name, use it. United Hamster Trainers Union is better than union groups.
- Outcome
-
Express the stakeholder’s need as a measurable outcome. How does the world change if the system is successful? You will design an architecture to achieve this outcome. For example, maybe the United Hamster Trainers Union needs a way to help members stay in touch with one another.
- Context
-
Context shares an insight about a stakeholder’s need and helps build empathy. Ideally context is insightful and not completely obvious. For example, knowing that the United Hamster Trainers Union’s most important annual meeting has over 5 million members attending virtually creates deeper understanding about the previously discussed outcome.
There are some business goals for Project Lionheart in the table. Putting business goal statements in a slick-looking table sometimes makes them easier to read.
Stakeholder | Goal | Context |
|---|---|---|
Mayor van Damme | Reduce procurement costs by 30% | Avoid making budget cuts to education or other essential services in an election year. |
Mayor van Damme | Improve city engagement with local businesses, measured by the number of applications from first-time local businesses, percentage of overall RFPs won by local businesses. | Improve the local economy by ensuring local businesses win city contracts. |
Office of Management and Business | Cut the time required to publish a new RFP in half. | Improves services across the city and reduces costs at the same time. Citizens suffer when city services go unfunded. Think: No toilet paper at the girls’ basketball game or not enough hypodermic needles for emergency medical crews. |
Office of Management and Business | Review historical procurement data for the past 10 years. | Businesses behave similarly over time and historic data gives the city a leg up when reviewing contract bids. |
Most systems only have only three to five business goals. More than this and the goals become confusing and difficult to remember. When working with many stakeholders, it’s useful to record goals’ relative importance. A simple must have or nice to have designation is good enough for this purpose.
Help Stakeholders Share Their Business Goals
Stakeholders usually know what they want, but many stakeholders find it difficult to articulate their needs as measurable statements. Every architect should have a few simple templates in their toolbox to help stakeholders find their voice. The point of view (POV) mad lib is a fun alternative that is similar to a user story but describes the value expected from the whole system instead of functionality. Other business goal formats are described in Activity 8, Point-of-View Mad Lib .
Collaborate closely with your product manager or other business-focused stakeholders to identify the system’s business goals. They can usually describe a system’s business goals without breaking a sweat. Be prepared to help stakeholders or product managers if they struggle to articulate business goals, but remember they own the business goals.
Get Your Hands Dirty: Create Business Goals for This System
What are the business goals for this proposed system? Create a few point of view mad libs for this scenario.
Bouncing Bean Grocery is a regional grocery store chain. A few months ago an Organic Plus! store opened and Bouncing Bean has seen a decline in sales. Hoping to entice customers to their stores, Bouncing Bean has hired your team to develop a mobile application in which potential shoppers can create shopping lists, search recipes, and clip e-coupons. Bouncing Bean hopes the app will attract customers and provide customer data to drive targeted advertising.
Here are some things to think about.
-
Who are the stakeholders? What do they hope to gain?
-
Who are the users? What are they trying to accomplish? (Hint: It has nothing to do with software.)
-
What’s the worst that can happen? Sometimes thinking about failure can help uncover a business goal. People usually want to avoid failures.