Who is your customer?

In 1984, R. Edward Freeman’s “Strategic Management: A Stakeholder Approach” was first published, triggering a re-appraisal of how best to consider the many perspectives of interested parties in enterprises.  Stakeholder analysis is often considered the preserve of the project manager, with a focus largely on how a change initiative communicates with different parties.  An understanding of stakeholder perspectives is also a vital tool in the kitbag of the architect.  One aspect of this is seeing as architecture through the eyes of different stakeholders and using this to arrive at better architectural decisions.

Many different ways of analysing and mapping stakeholders have been devised, with the most commonly used approach being a simple matrix relating high and low levels of “Power” and “Interest”.  A more subtle variant of this, which I’ve found to be the most useful way to help business sponsors understand their various stakeholders, adds a third dimension: “Legitimacy”.  This was introduced in 1997 in a paper by Mitchell, Agle and Wood in the Academy of Management Review.  The three dimensions combine to produce seven classes of stakeholders, with varying levels of salience.  Their formal definition of “Legitimacy” is “whether the stakeholder’s actions are considered to be desirable, proper and appropriate in the context of the project or solution”, which I often translate as “is the stakeholder on the same page, or do they have their own agenda?”.  I do like their crisp definition of Power: “can the stakeholder get the project to do something it would otherwise not have done?”.

 

Of course, using these three dimensions calls for sensitive handling – to broadcast too widely the names of stakeholders you think are not legitimate in the eyes of the project might make some stakeholder relationships distinctly cooler.  But if the core project leadership, the business sponsor, the project manager and the architecture owner, want to anticipate stakeholder behaviours and manage the relationships and communications accordingly, I think this model is really valuable.

In evaluating architectures and considering architectural alternatives, an architect can view an architecture from the standpoint of different stakeholders.  This involves a bit of effort in the early stages of the project, but if your project has distinctly different stakeholders, it is worth getting this understanding early on and avoiding potential conflict when it is much harder to change direction.  As architecturally significant requirements are identified and captured, the project can record the level of interest of each stakeholder.  I use just three levels, “strong interest”, “interest” and “no interest”.  For example, functional features are likely to be of much more interest to a service’s users than to those who maintain the availability of the service.

If you’ve been following my two previous articles, you will by now be familiar with the example of our insurance company seeking to replace its policy admin system.  In that example, we documented over sixty architecturally significant requirements, and against each of these were recorded the levels of interest of eight stakeholder groups.  The requirements were also classified using the ISO 25010 quality model, which enables us to look at stakeholder interest by quality characteristic.  This interest map is much easier to read than trying to navigate across a sea of individual requirements:

A simple weighted scoring model has been applied.  If a stakeholder has “strong interest” in all the requirements that belong to a given quality characteristic, they will have a score of 1.0.  If they have just “interest” in them all, then the score will be 0.5, and of course if they have “no interest” in any of the requirements, the score will be 0.0.  The “Overall Average” column and ranking show how much interest each stakeholder has across the whole set of architecturally significant requirements.

This interest map can help us to validate the project’s direction.  Just from the map, we can see that the primary beneficiaries of the initiative are not the customers, but rather the insurance product owners.  Even the Usability aspects would seem to be focused more on the operational users inside the company than the customers.  This might well be what is intended, but it is certainly worth validating against the project’s vision and objectives before pressing ahead with the publication of the requirements in a tender document and using them as the basis for evaluating solution options.  The map also shows the relative significance of each quality characteristic according to the impact scores of their requirements.

I once saw a project whose aim was to develop a new interactive website for the public, but whose interest map showed internal management as being much more interested in the requirements than the customers.  With the use of this map, we were able to challenge the direction of the project before too much effort had been expended, and the project reworked its high-level requirements with much greater customer involvement.

My previous articles showed how an evaluation of solution options can be conducted using a risk trade-off analysis.  They focused on the use of a quality and capability model to provide an abstracted view of trade-offs among quality characteristics and business capabilities.  If stakeholder interest has been captured against each architecturally significant requirement, a similar risk trade-off analysis can be presented from the perspective of each stakeholder. The view below adds the stakeholder perspectives to the quality and capability perspectives previously presented:

A trade-off analysis rarely provides you with a definitive answer.  But it does help you to see where to dig deeper, and suggests questions that need answering.  In this example, Option 2 looks attractive to most stakeholders, but its weaknesses in reliability, maintainability and portability damage its support from the IT team.  Can these risks be mitigated?  Or might the effort to reduce these risks be greater than that required to address the functional suitability gaps in Options 1 or 3?  This analysis can drive the detailed investigation of each vendor proposition, and the architectural strengths and weaknesses of each option should be well understood before a final decision is made and a new admin system is developed and deployed.

For a major initiative such as replacing an insurance company’s policy admin system, it is worth examining architectural options from different perspectives.  Architects are used to looking at the world from the perspective of quality characteristics.  Seeing it through the eyes of different stakeholders will lead to even more successful systems and services.