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).

FEAPO consensus definition of EA [and TOGAF doesn't help]

Federation of Enterprise Architecture Professional Organizations

Based on (http://www.itworldcanada.com/blog/the-great-debate-what-is-enterprise-architecture-resolved-in-a-new-paper/86616)

FEAPO find 80% of organizations do not successfully execute the business strategies they have. Poor strategy execution is the most significant management challenge facing large public and private organization.

EA claims to address these challenges, but there is little consensus on what EA is (e.g. what the term means, what the practitioners do, how its processes relate to delivery e.g. agile, where it should report to, etc).

FEAPO's paper “A Common Perspective on Enterprise Architecture” seems to say the following (slightly paraphrasing [e.g. to reduce obscurantism I have used "perspective" or "aspect" instead of "viewpoint", and removed some of the tautologies e.g. "change initiatives"]):

1. EA is the activities and artefacts for translating business strategy into an effective enterprise and includes creating and communicating, and refining the key requirements, principles and models describing the enterprise and enabling transformation.

2. EA's value includes articulating the strategic requirements of the enterprise including:

• models which present what all aspects of the enterprise should look like in future states, and how they support the business strategy;
• a roadmap of the initiatives required to reach those future states;
• the requirements, principles, standards and guidelines that should govern implementation

EA outcomes include:

• improving the effectiveness, efficiency, agility and structure of the enterprise;
• improving the ability of the enterprise to continuously innovate;
• rationalising, centralising, federating and improving the completeness and quality of: business processes, business information and business rules;
• aligning spending on initiatives so that they deliver the strategic intent.

EA commonly maintains:

• information describing the enterprise in different states (“target”, “future”, "intermediate/transitional) [actually there is no future state - there are only future states) 
• perspectives that span the enterprise (across various unit or functional boundaries)

EA practices should provide efficient, effective, consistent analysis, planning, design, and implementation of strategic needs.

It postulates that non-financial measure exist [which I think a bit silly, in public companies where the sole focus is on financial performance]. Strategic planning does not produce a directly measurable ROIs [which makes more sense].

Elsewhere today I saw  http://www.ebizq.net/blogs/ea_matters/2013/11/togaf-needs-a-public-roadmap.php

Someone called "Len" indicates that TOGAF is a follower not a leader e.g. "The Open Group and TOGAF will not change their concept of enterprise architecture until the community as a whole does" [which should be no news to anyone]. [TOGAF has long been captured by technology vendors and dragged down to be solution and engineering oriented]

Adrian Grigoriu says (correctly in my view that) that TOGAF  "moves too slowly in who knows what direction, while it becomes irrelevant. In the meantime, because of its clout, it hinders the development of other EA approaches." [i.e. TOGAF is more an impediment (emperor's new clothes) than anything else]

When will EAs learn traditional approach produce traditional results?

I keep seeing people advocating variations on the traditional approaches to EA that have not worked for a decade or two. Traditional approaches with result in the traditional results.

At best these approaches are often like communism - they sound sensible and if everyone did the right thing, in the right way for the right reasons - they might actually work - but that isn't the world we live in and they just don't really work.

Here are some things that don't work

• EA based on the religious adoption of frameworks (that have been around for decades with almost no examples of success). These frameworks are usually abstract high level methods that in academic sense may be correct but are so generalised that in practice they little more than common sense aphorisms. They may also be taxonomies that claim to be canonical despite the staggering changes in the nature, size, and form of the things they claim to organize. For example TOGAF reminds one of rat pie instructions (http://www.oocities.org/sunsetstrip/amphitheatre/8707/rats.html)
• EA that is a kind of software architecture or systems architecture (with its arcane notations and business alienating terminology). These initiatives are often rife with technical notations from various technical design discplines (data modelling, object modelling, process modelling etc.)
• EA modelling that produces lots of hand crafted pretty pictures and wall art. These things can, often with some difficulty be used to communicate a message, but on close inspection it becomes clear that they semioticaly and semantically inconsistent. They remind you of iconic-graphic art explaining myths or fables.
• EA done by some EA consultants (no the organisation itself). Consultant will tell you it can be done this way. NO it can't. EA can not even be done by EAs alone - it has to be done by the organization, it is an organizational activity.
• EA done for EAs as an abstract ivory activity i.e. it is not intimately connected to where the rubber hits the road. Solution architects treat it with bemusement. BCP planner marvel at its incompleteness. Its relationship to down stream executions (e.g. business requirements which in practice form one the key inputs to any execution) is at best unclear.