Context Mapping, by Example

I will demonstrate a technique for Context Mapping that leverages David Sibbet/The Grove’s work on Context Maps. We will build up the map incrementally, using the comments on this post to gather input to the Context Map which I will create iteratively and incrementally here.

In a follow-up example, we will do a Competitive Landscape Map, which is a Context Map for a product, service or even business. But for now, I would like to focus on the architect, and use the Context Map as a way to facilitate a discussion of the role of the architect. It is simply a way to create a “big picture” of the landscape the architect plays in.

The way I’d like to use the limited conversational tooling of a blog post to do this is as follows: I will pose a question in the comments, and it would be helpful if you would answer the question as a comment on the comment/question, so that questions and their answers are nested.

Let’s see if we can make this work. Loads of goodwill and interaction required here. :-)


6 thoughts on “Context Mapping, by Example

  1. First, we need to identify the “stakeholders” that architects serve. Let’s just brainstorm stakeholders.

    Of course, Tom Graves post on stakeholders is a resource, but also think of your situation, and who you view as having a stake or vested interest in your (architect’s) work. Think of who is enabled, constrained and otherwise impacted by your (architect’s) work. Who has a vested interest in the system?

    • For me (working as an infrastructure solution designer) the stakeholders are the people I meet at, between or round various “stations” on the subway map at (which is, like every map, a filtered subset of all the possible places & connections and a work in progress*)

      Most people I meet are a kind of agents who represent other stakeholders. E.g. I don’t meet customers of the enterprise I work for during my work but they are represented by agents like business project managers, testers, service managers, functional application managers etc.

      *when I write this I have just drawn one subway line and a number of loose stations so perhaps you want to revisit the map to see how it will develop :-)

  2. from my standpoint (application/solution architecture), in no particular order:
    - Users (internal and/or external customers)
    - Users’ management
    - Enterprise as a whole
    - Operations/Infrastructure/DBAs etc.
    - Development (maintenance)
    - Compliance/Audit/InfoSec
    - Partners (if applicable)

    I’m sure there are others I’ll think of right after I hit “Post Comment” ;-)

  3. In the spirit of Peter’s comment I’ll stick to my current engagement. In that context I am,at least in name, an enterprise architect but, as I have responsibility for the architecture as a whole my stakeholder group gets a bit more technical than might otherwise be the case.
    My stakeholders are (or include):
    - operational folks in my customer’s organization (the term “users” would be misleading here)
    - representatives of “users” (in the more usual sense)
    - representatives of the customer’s IT organization (the folks who get it in the neck if we screw up)
    - functional application managers in the customer’s organization
    - the customer’s enterprise architect
    - my company’s “client director”
    - our contact management folks
    - our service development folks
    - our project managers
    - our (technical) service management folks
    - our sales and business development team
    - our (technical) architects and designers (indirectly)
    - our testers
    - our helpdesk folks
    because they all need at the very least the context in which their work takes place (at least they ought to want to know)

  4. Just adding to that. All those people have vested interests in the system. IEEE1471 (ISO 14010) calls those interests “concerns”. Their concerns may conflict or may appear to conflict, depending on how they are stated. One of my jobs as an architect is to understand and represent those concerns in such a way as to minimize (ideally eliminate) unnecessary conflicts. I represent the concerns from the perspective of viewpoints. That’s how 1471 defines viewpoints. But you all know that, I guess.
    Stories (whether or not visualized) are a good way of achieving this, which can’t usually be achieved by static diagrams.

  5. I’m usually an immediate user of a system, so I tend to see it overmuch from that angle. In defence of this view, it’s difficult for a system to work other than how it’s used, isn’t it? Nowadays, systems tend to face both inside an organisation and towards its customers (or their agents), so I hope there’s a better view of how its use will be shared. One aspect that may get neglected is not the user story day-to-day but the story of how well the system gradually changes for them over the years. I’m not sure a representative user is very good at representing their behaviour in 5 years’ time, though, but future users matter, so can I put them in?
    Also non-users, non-customers – those who are able to avoid or reject the system (or may be rejected by the system).
    Then there are information consumers, who use data collected from the work done in the system but don’t create it. (Why is it sometimes that these get put before the users?)
    Then there are those who build, test and service the system.
    Finally, those who require the system, the beneficiaries of the work – those who financed it (or their agents), and the customers – again, but I think there’s no harm in being circular. When there’s some sort of existing system, there’s already use and purpose (e.g. product/profit).
    Oh, I’ve forgotten governance – who has a legal stake in the system or is responsible for ensuring that interest is served?
    And I know I’ve missed out lots of facilitators, relationship managers and so on. I can’t be expected to know who they are, I just know a selection will always be present, either getting in the way or being unfairly put upon.
    That’s how it looks from the bottom – you architects seem very remote, and several roadmaps may come and go without anything apparently changing.
    I realise in practice – and from reading the lists above – that real considerations may be quite different – external suppliers, etc; an architect could be another supplier.

    One interesting thing (sorry, nearly finished now!) is how your system may affect others in the same market or even society more generally. Sometimes, for instance, all the hard work on a slightly improved system may simply make it easier for competitors to top it later, so there could be hidden stakeholders.

    Oh, by the way, I like the way you’re using the comments here. I tried the same on my old blog, using the comments to create and rewrite the post.

Leave a Reply to Ruth Malan Cancel reply

Your email address will not be published. Required fields are marked *


You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>