Tuesday, August 19, 2014

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





Saturday, August 9, 2014

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