Absurd use of the term "Business Use Case"

Firstly in my own defense, I should say that I first worked with objects in a computer system in 1980 and adopted OO analytic approaches for business analysis in the early 1990s and did OO development first in 1994 (no doubt poorly).

The term "Use case" seems to me to have been imported from another language by non-English speakers.  It is an arcane short hand of "a situation or scenario or use" and often in vernacular usage as "use".

It is often used by business people or executives to try and sound knowledgeable or technically savvy. Usually its inclusions results in unclear communication.

It is list of steps, usually defining interactions things (people of systems) and a system (usually the being designed) to achieve a goal.

The abstraction of the thing doing the interaction makes sense if you are the designer of the thing i.e. conceptually you don't care what does the interaction (so you call that thing an "actor" meaning that which "acts" - atypical use of the word). In most business, and in fact in most technical contexts, if you what started off with is knowing perhaps it will be person (in fact a specific role or even a specific persion) or a systems (in fact a specific class of systems, or even a specific system) record the interaction as this knowledge isn't known isn't helpful i.e. use of term "actor" just removes knowledge.

Business people would be better of saying: situation, scenario, scenario of use, business demand, business situation, business scenario, process etc. Unless they actually intend to articulate quite precisely a list of steps, usually defining interactions of things with  a system to achieve a goal. In my experience most executives certainly can't be bother with doing this - there are no steps, there is often not a goal - it isn't a use case.

If what you are describing is a specific instance (usually a set of instances) relating to an interaction with an element of technology e.g. a UI button, a mouse button, a break button, a break lever, a break disc, then Use Case makes perfect sense. It allows us to specify the expected/desired behaviour of the technology based on certain actions (and we may not know what is undertaking the action).

TOGAF - it doesn't really work, most of the time for most organizations

Some other than me pointing some issues with TOGAF. See (http://www.forbes.com/sites/jasonbloomberg/2014/08/07/enterprise-architecture-dont-be-a-fool-with-a-tool/ )


I know Vish quite and have a lot of time for him, and have a great deal of respect for his experience. Sadly think he is flogging a dead, though popular and profitable, horse. Even the most experienced advocates of TOGAF say:
a) doesn't have a great track record of success
b) you can fail if you take it "literally"?
c) it can't be applied by someone who doesn't know what they are doing
d it isn't a cookbook
e) it needs to be needs to adapted to organization (and if following a method needs expertise, adapting a method surely requires more expertise).

Or to extract some quotes:

• "TOGAF's popularity ... doesn’t have much to do with how well it helps ..."
• "many TOGAF-driven initiatives have failed, although not necessarily because of problems with TOGAF..."
• "TOGAF is not a cookbook .. it consists of: best practices, processes, principles, rules, guidelines, techniques ... a toolkit,” 
• “TOGAF can fail is when people take it too literally ... ”
• "If people are struggling with TOGAF, either they’re not adapting it for their organization, or they’re not getting people who’ve ‘been there, done that, got the T-shirt, have the scratch marks’ to help with the initiative”
• “A fool with a tool is still a fool. ”

Vish suggests 3 approaches: 1/ "...baseline ... because it’s good for cleaning up messes";  2/ "... target [business outcomes] ..."; 3/ “some baseline, then target. ... an iterative approach ...take a pain point, create that slice of EA. ...”. I would suggest that only last of these can really work. And even then it won't work if the done using the wrong tooling - because the data can't be maintained and re-purposed for subsequent iterations.

Vish does point out that information needs to be managed. But sadly TOGAF isn't an IT management solution, so doesn't help that much. In other areas people are smart enough to realise that they need good tools for managing information - yet EA teams (and TOGAF people in particular) persist with SW Engineering oriented tools, languages and methods and modelling completely ill-suited to the task (aided and abetted by OMG with its SW engineering oriented legacy and prejudice).

Jason Bloomberg is right to point to the failure of traditional EA, and TOGAF (he should look at tradition Project Management in IT, which is even more of farce).  But he seems to have difficulty with concepts of classification and understanding what the issues really are.

1. Buckets that are not buckets - he suggests TOGAF users fall into four buckets; those that achieve: very little (because the apply TOGAF incorrectly), a baseline (that helps to resolve legacy issues), help addressing specific business outcomes and those that want to deal better with change overall, and look to EA to help them become more agile. Many users: achieve very little, but do establish a baseline (that helps a bit with legacy issues) and they do address a few specific business outcomes. Most want to deal better with change overall. So it just doesn't make sense to say most fall into one of these four buckets - most don't fall into any - but sit across many.

Bloomberg fails to identify the real issue in making decisions and changes (agility). There is always a:
a) a relationship between the quality of the information available and quality of the decision
b) there is usually a relationship between the ease with which information can be analysed and interpreted quality of the decision i.e. if analysis is just too difficult it often won't be done
c) there is a trade off between speed and quality of decision
d) a poor decision made in haste, with poor information, may have unforeseen long term adverse outcomes that affect others i.e. not the immediate decisions makers or the people who implement the specifics of the decision, but those that live with the consequences (a number of wars, and social experiments, come to mind)

The challenge is finding the sweet spot i.e. or point of diminishing return. The really failure of EA is that few people address these issues how do you:
a) establish a lightweight effective way to maintain the base set of information needed for good decisions
b) use that information in decision making that rather pulling the answers out of the air (which is how most IT decisions are really made)
c) apply that information effectively to down stream initiatives and as a by-product of that application information the quality of the information available to all.
d) avoid decisions that suit an immediate political agenda with disasters downstream consequences for a broader community.
Most of these things come down to establish a virtuous cycle of information use and reuse combined with governance that balances short term and longer term outcomes.

TOGAF's problem is that it is like a condom with a hole in it - it gives the illusion of making something safe without actually making it safe. It is a EA equivalent to old medical practice of bloodletting.

See:
http://enterprisesto.blogspot.co.nz/2010/05/virtuous-circles-of-strategy.html
http://methods-and-tools.blogspot.co.nz/2013/11/what-is-wrong-with-togaf-in-practice.html

Why don't IT organizations maintain, reference and continously improve the simplest of inventies

If you large organizations who have fleets of cars:
a) if each cars cost less than $50k
b) if their can essentially continue to operate of a car fails 
c) if they have an inventory of the 100s or 1000s they have 
- the answers are usually: yes, yes and yes. 


If you ask the same organizations who multitudes or people:
a) if each person costs them less than $50k to on board and make productive. 
b) if their can essentially continue to operate if one their people fails catastrophically
c) if they have an inventory of the 100s or 1000s of people they have. Know who manages them, knows where they are, what they do etc.
- the answers are usually: yes, yes and yes. 

If you ask the same question about interfaces between systems they answers are usually: no, no and no. And often they don't have even canonical inventories of the systems  

Why classical Project Management fails to deliver for IT

Classical Project Management methods and systems fail to deliver what is needed for IT strategic planning because they are oriented at a different problem (not strategic planning or management) in a different domain (not IT). Consequently classic PPM solutions, and PMOs applying them, fail to provide some key strategic insights required in a IT and business transformation context. 

Classic project management has its roots in the built-environment (construction and engineering). The classical paradigm assumes a well defined solution scope, well defined solution impacts and focuses on defining and managing the plan i.e. what is required for execution and delivery i.e. when, in what sequence, who, etc (i.e. tasks, resources). It also assumes well defined methods for detailed delivery, boundaries between teams, and an implicit and detailed understanding of the behaviour and characteristics of materials and technologies. So essentially it focuses on tracking and predicting: costs, dates, overruns and overloads, etc. at a task and resource level.

To give a simple example when planning the delivery of a building - it assumed:

• the design of building being delivered is fairly well defined (solution scope), 
• where that building is and how it relates to other buildings, services etc. is fairly clear.
• how bricks are laid (methods for detailed delivery), how brick laying relates to wall plastering is know (boundaries between teams), we know what bricks do (behaviour and characteristics of materials and technologies)

The reality is that in IT, when considering a portfolio of transformation initiatives, key things we are trying to understand are: 

• how the transformation portfolio produces the desired business outcome
• what the portfolio of solutions (and therefore projects) looks like and what the scope of each is exactly
• how each solution (and therefore project, and sub-project) relates to other solutions and projects.
• what new technologies do, how new technologies are best applied, and how this affects boundaries between delivery roles.

Strategic planning operates at a different level of detail than execution planning. Strategic planning of the portfolio is like a property investor working out which building he will build, retire, etc. It doesn't require task level details of resources that would be require for execution - its only requires a project level allocation of classes or resources and scheduling at this higher level.

Even detailed IT project management focuses more on managing scope with an, ideally fixed, time and budget - than it does to managing time and budget to an explicitly defined scope. 

The things PPM systems excel at when managing execution are often just not applicable e.g. task sheet production, time sheet recording and tracking detailed actuals of execution tasks, estimates cost and time to complete based on task level critical paths. That is not to say they are not useful - they are just not useful for strategic planning.

What is required are multi-dimensional views of various impacts i.e. on the many aspects of the business plan, policies,  architecture, assets and agreements (and related IT policies, architectures and assets). 

More thoughts on the underlying issues is here:

Projects are artificial constructs and often managed in ways unsuited to enterprise change initiatives

Business processes and systems processes

When we describe a enterprise there are a number of perspectives we can take e.g. those relating to:

• offerings: products, services i.e. how we make money
• markets: sectors, customers, accounts i.e. who pays us money
• behaviour: functions, processes, etc.
• decisions: strategies (decision on how achieve), policies, rules, etc.
• knowledge: information, data, etc.
• communications: messages, message details, etc.
• organisation: unit, role, posotion, person etc. (who do, know, communicate, etc.

Where the enterprise is enabled by rigid systems these things will often be represented within the systems. Systems oriented people therefore have perspectives on these things that relate to their need to implement systems. There is a tendency in ICT oriented people to assume that these implementation and systems specific views should be used at higher levels for business planning, transformation and governance.

These low level implementation specific views are necessary when implementing specific changes to the details - but most of governance, transformation and planning takes places at a higher level.  

This slide show gives a perspective on the issue from a process perspective:
http://www.slideshare.net/billpoole/eba-and-bpm-7510328

Technology vendors with their huge marketing budgets have continually spruiked the languages and methods associated with implementation in order to promote their technologies (which obviously need to be implemented). With no equivalent countervailing level of promotion for higher order views of enterprises there is tendency for these technology driven methods to have a preternatural dominance. For most technologists in businesses - the specific business they are in is a transient - the technologies are the things are really attached to so they also gravitate to methods attached to technologies and technology outcomes rather than the business and business outcomes.

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]