This little canvas is part of my toolbox for detailing and documenting scenarios.
The Scenario Canvas
Note: I’m currently in a process of changing my presentation design (the image shows what the new design looks like) for all my work. When I’ve stabilized the design and applied it across all canvases and related material I’ll link up the powerpoint to Slideshare.
When you should use this
When designing target architectures I tend to use scenarios in conjunction with capabilities to help navigate the uncertainties of the future. (How this is done will be covered in a later post)
In the HBR article Living in the futures, Angela Wilkinson and Roger Kupers highlight how Shell has used scenarios.
Working with architecture as a way of designing and cataloging the relationships between business and IT has always been a challenge. I recently attended an IASA meeting where we discussed the challenges of designing and maintaining a business architecture. At the meeting I talked about capabilities, what I think they are and how to actually go about identifying the key set of capabilities in a business. I also talked about my view of how these capabilities relate to other elements of an architecture. My view is as I’ve understood a bit different from the common view amongst architects. I promised the participants that I’d release some of my writings on this topic, so here is a preview of the work I’m doing right now.
The basic assumption I work from is that one should try not to confuse functions (functionalities of a business) with capabilities. If one take a good look at the way I prefer to design the connection between information systems and the business one would see that there are no “functions as capabilities” in that architecture.
Functions are a really good way of structuring one view of the architecture but it is not the same as my view of capabilities. Functions are easy to break down in an hierarchical architecture that can serve as excellent requirements of an IT-architecture, if you pare it with a service architecture it’s even better. The best way of doing this functional break down that I’ve seen so far is by Cutter Consortium and it’s documented in the article “The Business Capability Map: The “Rosetta Stone” of Business/IT Alignment“. The functional maps can easily be created for a whole business, a segment or some other subset. One really good thing with them is that if you have excellent architects and knowledgeable subject matter experts then you can start in any corner of the white space and flesh out the map as the projects comes along. I’ve done a lot of these types of maps for various businesses and in my mind they are essentially functional maps and not capability maps. Rest assured that the maps alla Cutter Consortium are effective and brings with them great value, however I believe there is an even greater value to be gained from creating another type of capability maps.
The capability map I describe is on the other hand not used on anything but the business as a whole, and they don’t break down hierarchically.
I’m in the process of creating my complete writings on this topic so here is a draft of a sample capability map. Each one of these capabilities I would detail using The Capability Canvas.
Designing and understanding brands and how the behave as figments of their own is hard enough. Having a simple structure that one can use to design and / or understand a brand makes designing businesses so much easier.
You must understand that software is still one piece of the whole puzzle. I get it that you don’t want to create detailed models of the software architecture. I can relate to the fact that code is the true software blueprint. I’ve experienced every time that the code changes faster than the model can be updated. I truly get that this is the current state of the art wether you use agile or any other way of creating software. All of this is fine and I try to live by it. There is however this issue that software is just one part of the whole puzzle. When we try to figure out how to design the whole we turn to architecture. This is the scope where enterprise architecture comes to play. This is where we create models to effectively communicate between stakeholders. We usually start our designs in workshops where we use post-it and whiteboards to facilitate the dialog. Together we explore everything from peoples beliefs to automation features. Our end result is made up of decisions about overall solutions that we aim to rapidly get implemented and put to the market.
Gandhi said “Your beliefs become your thoughts. Your thoughts become your words. Your words become your actions. Your actions become the habits. Your habits become your values. And your values become your destiny.”
Omvärlden, kunden, uppdragsgivaren och uppdragstagaren är alla en del av samma helhet. Vi samverkar i en ändlig loop.
1. Förstå frågeställningarna
2. Beskriv hela kundresan (horisontellt)
3. Beskriv stegen (vertikalt) = Uppdragskort
4. Prioritera på effekt (h&v) = Uppdragspoäng
5. Bearbeta uppdragskort
6. Gör om och gör rätt
Använd detta som ett fraktalt mönster och låt behovet i varje nivå avgöra detaljeringsgraden.