Active Stakeholder Participation for Agile Architecture

By Scott Ambler, Consulting Methodologist, Ambysoft Inc.

In Agile Architecture for Software Development Teams: Doing Agile I described a collection of techniques for agile architects, one of which is active stakeholder participation. As agilists we work together closely in an iterative and highly collaborative manner in all aspects of our work, including architecture. Active stakeholder participation is a practice from the Agile Modeling method where you work side-by-side with your stakeholders to collaboratively develop models (sometimes called maps or board).  Yes, they create the actual models and not just provide information to a modeler. This practice extends Extreme Programming (XP)’s Onsite Customer practice by drawing upon participatory design strategies.

Who Are Architectural Stakeholders?

In AM, a stakeholder is anyone who is materially impacted by the outcome of an initiative. This includes business stakeholders (such as end users or senior management), supporting stakeholders (such as enterprise architects, security professionals, experience designers, and data architects), and downstream stakeholders (such as support engineers or sales staff). Although the development team is also a stakeholder of their own work, in AM we distinguish between “the team” and “their stakeholders” for ease of discussion.

A critical thing to observe is that your stakeholders are not just business customers nor are they just technical people. There’s more to architectural modeling that just addressing your business needs and similarly there’s more to it than addressing technical issues.

Why is Active Stakeholder Participation Important?

The people who are best suited to explore what they want are the stakeholders themselves. Similarly, the people who are best suited to explore how something will be built are the people who are going to build it. The implication is that when you are modeling the requirements for your architecture you want to work closely with stakeholders who understand your long-term needs and when you’re identify how things fit together you should work closely with technologists and experience designers.

While your stakeholders have valuable experience and knowledge that you do not have, you don’t want to simply let them model on their own. This is the case for several reasons:

1. Individual stakeholders are likely to focus on their own specialties. Effective architecture needs to consider the whole picture, combining multiple aspects or views into a coherent vision.
2. Stakeholders are likely not modeling experts. While they have valuable knowledge, they may not be very good at abstracting that knowledge.
3. Modeling sessions require guidance and facilitation. Your stakeholders won’t agree on everything, nor do they share the same priorities. Effective architecture requires trade-offs, and that will require someone(s) guiding the modeling sessions.

The point is that effective architectural modeling is collaborative in nature, with architects and stakeholders working side-by-side to do so.

Identifying and Gaining Access to Stakeholders

This can be easier said than done. To identify potential stakeholders, I will often ask myself:

• What architectural view(s) are we focused on, and who are our “go to” people on that topic?
• Who will be affected by what we’re working on?
• Whose support do we need for this initiative to succeed?
• Who has experience building something similar in the past?
• Who will be responsible for building, operating, or supporting this?

The challenge is that your stakeholders are very likely busy people with many other concerns vying for their attention.  I’ve found that the following strategies help me to convince stakeholders to be actively involved with our architectural modeling efforts:

• Respect that they’re busy and may not have had good experiences with similar efforts in the past
• Communicate why stakeholder involvement is critical and why they are key stakeholders
• Point out that this is their opportunity to ensure we “do it right” this time
• Ask allied stakeholders to help convince their colleagues to get involved
• Be flexible regarding timing and level of involvement
• Be prepared to accept stakeholder representatives, but insist that they are authorized to make decisions
• Fight for it, and keep fighting for it

Modeling with Stakeholders

When it comes to modeling we want to include our stakeholders as much as possible, so we’ll use inclusive techniques such as whiteboards and sticky notes.  In general, we try to stay away from complex diagrams when working with our stakeholders.  As architects we often think abstractly and lean towards visual thinking, but this may not be true of our stakeholders. Similarly, we are likely very familiar with modeling notations such as those of the UML, whereas our stakeholders often struggle to understand these notations due to lack of familiarity.  In short, know your audience and adopt techniques that enable you to include them in your efforts. This is called inclusive modeling and it enables active stakeholder participation.

Active stakeholder participation supports the following agile modeling practices:

1. Initial requirements modeling. Early in an initiative you will work collaboratively with business stakeholders with the goal of gaining a high-level understanding of the requirements as input into your architecture, planning, and construction efforts.
2. Initial architecture modeling. In parallel to initial requirements modeling, you should also do just enough modeling to gain a high-level vision of a potential architecture for your solution. The goal is to do enough architectural thinking early in the initiative to get going in the right direction and thereby address major technical risks, but to allow the details to evolve over time.
3. Just in time (JIT) model storming. You want to perform targeted architecture and design modeling on a JIT basis when you need to think through the details of a specific aspect of your overall strategy, and thereby make the best decision that you can at the last most responsible moment.

I will describe each of these agile modeling strategies in future articles.