Talk to the Right People
Stakeholders usually, but not always, have a business interest in the software. They might pay for the software or directly profit from it. Users are important stakeholders but so too are the people who build and maintain the system. Other people might not even realize how our software might affect them, but it’s sometimes necessary to consider their concerns as well.
In the wild, stakeholders rarely travel alone. We use the term stakeholder group to highlight this fact. Working with groups is different than working with individuals. Two people from the same stakeholder group can provide inconsistent or conflicting information. We must work to understand the whole group’s concerns and sometimes even help them reach consensus.
Here are some stakeholders for the Project Lionheart Case Study, introduced. In this picture, the icons represent specific people or roles while speech bubbles show stakeholders’ thoughts and feelings.
Stakeholders are interested in what we’re building and will influence the architecture we design. Since we’ll want to invite these people to future design workshops, we should find out who they are. Enter the stakeholder map.
By Bett Bollhoefer, software architect at General Electric
Architecture is about the customer. If I create an architecture that doesn’t give value to the customer, I am wasting my time. When I talk to customers, I often hear horror stories about how their current systems were developed by someone in an ivory tower who didn’t understand them or their work. How do I make sure I am bringing value to customers through my architecture?
My answer is to use a customer-centric design process. I start with who the customer is and what they want to do. I divide the system into tasks the customer performs. For each task, I find out how they start it and where they run into issues.
You might be thinking, “This doesn’t sound like architecture—it sounds like user experience!” Yes, it is, but many UX designers don’t understand the technical aspects of the system well enough to determine the architecture. My process goes beyond the surface to ensure the deep structures support the customer’s values. I call it Customer Experience Architecture.
- Step 1:
-
Determine what matters to the customer, including their functional requirements and quality attributes, by watching how they do the task in their natural environment and asking lots of why’s.
- Step 2:
-
Design the system around the customer’s needs and document it in a prototype. The prototype should be as interactive as possible, not just a flowchart.
- Step 3:
-
Review the prototype as early as possible with the customer. Make sure they really understand what is changing in the new system and how it will impact them.
- Step 4:
-
Revise the architecture based on feedback from the customer’s review.
Using these four steps, you can create value for your customer through your architecture and become their hero, or at least not the person in the ivory tower who is ruining their life.