Tube Maps

Many organisations are seeking ways to better express and analyse the essence of their business architecture. The business architecture and desired changes to the business architecture are the key drivers of business transformation. Many have: capability Maps; lists of business functions, business/functional reference models, and a profusion of details in business process models (which describe in great detail the specific steps but can not readily present a useful overview). They may also have value chain views that focus on an area, product, offering. Many of these models in turn relate to the technology architecture.

Tube Maps can be used to communicate the essential aspects of the business architecture i.e. how enterprise operates as a whole on in a specific area. These views can then be used as a lens to better understand:
planned transformation, gaps, issues and opportunities. They fill a gap between capability maps (which have no concept of flow); value chains (which focus on specific narrow flows, but not organizations or enablement); BP models (which are detailed implementation oriented views with information that is important for implementation, but have too much extraneous detail for most audiences/purposes).

Tube Maps are selective in what present, often tending to focus on unique and value generation rather than internal governance and operational processes (i.e. as these process are usually fairly generic and dealt with by COTS applications). Tube can automatically generated using our methods and solutions leveraging data held on capabilities, functions, processes etc.

In a funny way it is kind of amusing all the noise about BP models (which are of course implementation specific - with their specific sequencing, roles etc.) and capability models - without any really useful discussion on what visually fits between the single capability map and the hundreds or thousands of swimlane diagrams.

Parallels can be seen in the existence of thousands of ER models and table - but no really clearly communication information models.

So what we might have is:

• Business Capabilities - 100-200 elements (usually structured in a 2-3 level hierarchy - which we present in capability maps, landscape/matrix maps etc. Often just showing the top couple of levels. These are exist independent of any implementation they are things we need to be able to do.
• Business Functions - 500-3000 elements at least one function (usually more) for each Capability (and vice versa). These are largely implementation agnostic (i.e. exactly: how, who, when, where, etc. will change).
• Business process models - 5,000-10,000+ elements, which elaborate one or more functions, are implementation specific, often presented in swim lanes (ideally surrounded by context - who, how, why, etc.)
• Use case - which elaborates the relationship between a BP element and a system/role (either via ICOM or direct). These are obviously not just implementation specific but really engineering specific views to describe the expected behaviour of systems for design or testing.

So it looks something like:

• Capabilities - Travel around city and country side 
• Functions - Go shopping, Take children to school, Go to from/work  
• Process - Go Shopping - Get in car, back out of drive way, drive to shops [navigation system has details], ... stop car, park, shop, pack,  .... drive home, ....
• Use case - stop car - break pedal - press on the break pedal (after precondition of stop pressing on accelerator) and car come to halt. If not press harder or panic/ 

You could try and record this all as different levels of BP if you really want to I guess - the Capabilities and Function do not really have the characteristics of processes. A dictionary defines process as"
"A series of actions or steps taken in order to achieve a particular end", "A systematic series of mechanize/chemical operations that are performed in order to produce something". So for something to be a process there is clearly implementation of series and sequence (which is may not exist for functions "An activity intended for/natural to a person/thing"). If I am buying a car I probably don't need Use Case (I may well not need Process models - Function will usually be enough).