Some basic business capability map patterns (level 0)

Don’t be scared, level zero in a capability map is just a way to structure the map so that we have a consistent way of communicating. It’s really not that important if all you wish todo is create an excellent set of capabilities for your business. However if you are intent on changing the foundation of your business then level zero is absolutely imperative to get right. Capabilities and capability maps are not organization structures, they do however serve as a powerful instrument when one need to create an organization architecture, in fact they are best thought of as organizing structures.

Basic patterns for capability map level 0

Are these patterns better than any other pattern one may ask and the answer is that they are not. There is probably more than a enough patterns to this problem of layout if you Google for capability maps. It’s just that I’ve used these patterns a lot and have seen others use them and have found them to be highly effective to influence the future of a business.

Remember that any business capability map can be reordered into any of these patterns, so do not let the choice of pattern for level zero stop you from investigating what is important.

The system perspective is highly influenced by the viable systems model created by Stafford Beer and the OODA Loop created by John Boyd.

When you should use this

  • Whenever you need to create a capability map
  • Whenever you have a desire to change the business

What you should consider when you use this

  • Use this is a guide, change it to fit your needs
  • Use the patterns many times to understand what works and refine those
  • Add your own patterns and create a pattern library
  • From a training perspective I’ve found that the hierarchical pattern works best

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Download
You will be able to download the presentation here.

Related

Post change log
2015-11-09: Published initial post

The Idea Card

Whatever business you are in innovation is the name of the game. Today it’s even more important than ever that you innovate fast and somewhat accurate. This little card is designed to help you go fast by staying small and keeping it nimble.

The_Idea_Card

When you should use this

  • Whenever you need to innovate
  • When you need to keep a trail of successful and failed ideas

What you should consider when you use this

  • Use this is a guide, change it to fit your needs
  • Print many large copies and put the on walls
  • This card is best used as a communication tool in collaboration between teams

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Download
You can download the presentation here

Post change log
2015-10-29: Published initial post

The Entity Card

Whatever business you are in, information is the most important raw material there is and it should be understood by many. Using tools like the entity card is one way of communicating on relatively stable information structures, there are other ways. People may say this is hard and takes a lot of time todo. To them I would recommend that they think about the basic information used in the business and evaluate for how long the average entity has been around. My experience is that most entities within a business domain has been around at least +80% of the lifetime of that domain. Changes to the entity is almost always on business rule or attribute details.

The Entity Card

When you should use this

  • Whenever you set about designing an entity you can use these questions to understand the shape and use of the entity in scope
  • When you need to document in some detail a key entity

What you should consider when you use this

  • Use this is a guide, change it to fit your needs
  • An entity in the overall information architecture is just one piece of the puzzle
  • This card is best used as a communication tool in collaboration between agile teams and architects

 

License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

Post change log

2015-10-15: Published initial post

Using the Capability Inventory for municipalities

Using the Capability Inventory for municipalities

I was talking to Marino the other day and he told me he would like a special capability inventory for a municipality. I said that there is no need to have a special capability inventory, the basic pattern exposed in the original capability inventory should cover any organization. In fact he should just use the original one and perhaps add the elements that are missing. The basic pattern behind the capability inventory is to view every organizations output as delivering services. This view enables us to use the same basic elements across all organizations. I can relate to the fact that the pattern and elements looks unfamiliar because it does not follow the way one is used to visualize a municipality. To remedy any confusions I´ve designed a naïve example below.

Elaborating on the capability inventory for municipalities
Elaborating on the capability inventory for municipalities

In the example I´ve removed the elements in the envision and enable rows and focused on the engage row. The text in the capability elements are not capabilities rather they describe the activities one would perform using the capability to reach the business goals.

When you should use this

  • Whenever you set about using a capability model of your enterprise
  • Whenever you have a new business problem to consider

What you should consider when you use this

  • Using the capability inventory and mapping out the basic activities will give you a good hunch but it is not the complete constructs needed to design the business.
  • It took me about 15 minutes to whip up the example

Download note

I’m currently in a process of changing my presentation design (the images 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.

License This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

Post change log

2015-07-02: Published initial post

The Capability Inventory

This model is part of my toolbox for working with capability architectures.

The Capability Inventory

I know that there is certain ways of naming a capability and also that there are other principles that people and I promote that you should adhere to when designing your capability map. Here I’ve taken some liberties in regards to those principles to make it easier to relate to the possible content in the boxes. This inventory is basically what I refer to as “functions as capabilities“, now there is certainly a way of mapping proper capabilities into this inventory.

The Capability Inventory Details 

Detailing production
Details of production capability

Philip asked about the production capabilities so I’ve detailed some parts of production (above) to show where they could be situated. The detailed inventory map also shows how one can reuse the original layout to keep things in view.

Details of the sales capability
Details of the sales capability

 

Details of the marketing capability
Details of the marketing capability

 

I have some more of these laying around in different formats and states of publicity. When I find the time I’ll update this post with more of these.

Download note: I’m currently in a process of changing my presentation design (the images 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

  • Whenever you set about designing a capability model of your enterprise
  • When you need to understand what types of capabilities an enterprise can have
  • When you are set to create a target context map for microservice architectures

What you should consider when you use this

  • This is not “the complete, nor the correct” inventory of capabilities
  • There is no known right way of designing or describing a capability of an enterprise
  • There is techniques like reversing the names of processes and then consolidating them that could give you a fair hint of what capabilities you have in your enterprise
  • Look at other peoples capability inventories and take inspiration from those
  • The “best” capability inventory is the one you get enough people to use in their work
  • Develop the capabilities and the capability inventory in as wide spread community as possible
  • Continuously refine your capability inventory as you go
  • When naming capabilities think of each capability as part of a namespace
  • In the end it’s all about just doing it

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Related

Post change log
2015-06-15: Published initial post
2015-06-20: Added the detailing view of production
2015-06-22: Added the detailing view of sales
2015-06-23: Added the detailing view of human management
2015-06-23: Updated the basic inventory of capabilities to reflect the sales capabilities directly
2015-06-24: Added the detailing view of marketing

The Inventory Model

This model is part of my toolbox for working with business architectures.

The Inventory Model

THE ENTERPRISE INVENTORY

 

The important thing to remember is to be agile minded in use of tools like this. So, when I say extendable I mean that this is definitely not all things that could or should be in the inventory. Reconfigure it in the X, Y or Z axis as you see fit for purpose and make sure to deliver something of value.

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

  • Whenever you set about depicting the greater enterprise

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Post change log
2015-05-19: Published initial post

The Strategy Model

This model is part of my toolbox for working with strategic architectures.

The Strategy Model

The Strategy Model

 

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

  • Whenever you set about understanding the greater enterprise

License
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 Unported License.

Post change log
2015-05-12: Published initial post

Publishing The Art of Enterprise Architecture

As some of you may be aware of I with the help of a wonderful set of people has been reviewing the final script for the book The Art of enterprise Architecture (working title). The plan is to have the book ready to be delivered in time for Christmas, just so you may all either make a wish for it or give it away as a present to all your friends.
  I’m working on what could be a follow up to this, bending the philosophy behind leading and managing an EA as depicted in The Art of Enterprise Architecture to one way of documenting the essentials of an architecture. The working name for that book is “The Art of Documenting Enterprise Architecture”. It is not so much about diagrams and pictures, more about the questions and how you could structure some of the answers that you get in response to those questions. Maybe it’s a checklist, maybe it’s more, at this moment it is early so the shape has not been distilled yet.
  For those who are interested to participate I’ve put up the first piece on my Google drive and in this work you are all invited to not only review but also contribute. Hopefully this time it will take a lot less than four years to go from idea to publication.
To get access follow the link and ask for permissions https://docs.google.com/document/d/1Aq2TP_YpL3ly-b1DCPscWzlAXyDjbZlGIakOiBjLdv8

The Art of Enterprise Architecture – Section 13 – The use of architects

The mistake of the many

Raising a host of all employees and marching them great distances entails heavy loss on the people and a drain on the resources of the Enterprise. The daily expenditure will easily surmount that which can ever be gained. There will be commotion in the organization and the network, and men will drop down exhausted on the floors.

The wise leader and the good manager

Stakeholders may face each other for years, striving for the consensus which should be decided in a single day. This being so, to remain in ignorance of the stakeholders condition simply because one grudges the outlay of a small amount of funds, is the height of inhumanity. One who acts thus is no leader of men, no present help to the owners, no master of victory. Thus, what enables the wise leader and the good manager to act and win, and achieve things beyond the reach of ordinary men, is foreknowledge. Now this foreknowledge cannot be elicited from spirits; it cannot be obtained inductively from experience, nor by any deductive calculation. Knowledge of the stakeholders dispositions can only be obtained from other men. Hence the use of architects.

Four classes of architects

  1. Business architects;
  2. Enterprise architects;
  3. Domain architects;
  4. Solution architects;

When these four kinds of architects are all at work, none can discover the secret system. This is called “divine manipulation of the threads.” It is the leaders most precious faculty.

Having business architects means employing the services of the leaders of a business domain. Having enterprise architects, making use of managers of the stakeholders. Having domain architects, getting hold of the domain specific information and using it to further our purposes. Having solution architects, doing certain things openly for purposes of inclusion. Hence it is that which none in the whole organization are more intimate relations to be maintained than with architects. None should be more liberally rewarded. In no other business should greater security be preserved.

Employing architects

Architects cannot be usefully employed without a certain intuitive sagacity. They cannot be properly managed without benevolence and straightforwardness. Without subtle ingenuity of mind, one cannot make certain of the truth of their reports. Be subtle! be subtle! and use your architects for every kind of business. If a certain piece of insight is divulged by an architect before the time is ripe, he must be silenced together with the man to whom the secret was told.

Whether the object be to optimize a business unit, to move a product on to the market, or to execute mergers and acquisitions, it is always necessary to begin by finding out the names of the attendants, the aides-de-camp, and door-keepers and sentries of the managers in command. Our architects must be commissioned to ascertain these.

The end and aim of architecting in all its varieties is knowledge of the stakeholders businesses; and this knowledge can only be derived, in the first instance, from the domain architect. Hence it is essential that the domain architect be treated with the utmost liberality.

Hence it is only the enlightened leader and the wise manager who will use the highest intelligence of the enterprise for purposes of architecting and thereby they achieve great results. Architects are a most important element in water (emotion and intuition), because on them depends an enterprise ability to move.

—————————————————————-

You can read Section One here: section-one-strategy

You can read Section Two here: section-two-doing-architecture

You can read Section Three here: section-three-planning-the-architecture

You can read Section Four here: section-four-tactical-dispositions

You can read Section Five here: section-five-directing-energy

You can read Section Six here: section-six-strengths-and-weaknesses

You can read Section Seven here: section-seven-maneuvering

You can read Section Eight here: section-eight-variation-in-tactics

You can read Section Nine here: section-nine-on-the-march

You can read Section Ten here: section-ten-domains

You can read Section Eleven here: section-eleven-situations

You can read Section Twelve here: section-twelve-investigation-by-process

The text above is based upon the writings of Sun Tzu in the Art of War. Several translations has been read prior to writing the text above, but the most prominently used translation is the one retrieved from “http://en.wikisource.org/wiki/The_Art_of_War_(Sun)”. I consider the text above a work in progress…