Approaches need to be instantiated to be useful

-->Introduction
Approaches need to be adapted to the environment in which they are to operate. The initial adaptation may be to an enterprise and the approach may be further adapted to specific units, uses or projects within an enterprise. Knowing how an approach should be adapted usually requires and understanding the principles underlying the approach and experience in applying the approach in a range of different circumstances.
Some approaches have a 1st step that is to undertake instantiation, so one could consider these generic approaches to produce results universally. The reality is that frequently the instantiation doesn’t really take place, often because the practitioners lack a sufficiently robust understanding of the principles and issues. This often results in attempts to follow a generic set of steps by rote.

Why care about approaches
Most knowledge oriented organisations want to achieve: quality results, continuous improvement and excellence of execution. Well defined approaches are critical to achieving these things. An approach ensures services are delivered in a consistent and repeatable way, and assists in classifying and collating knowledge (including in some cases artefacts).
Approaches are also used as a mechanism for reflect best practice (steps that are known to be required, techniques that work etc.). An approach may often involve best practices from several areas e.g. an approach to strategy & architecture may involve useful elements of a number of EA “frameworks”, elements of programme & project management disciplines, etc.

What do we mean by approaches
An approaches includes a process (a sequence of operations i.e. a set of steps), a set of tools and techniques, sets of constructs and artefacts (e.g. deliverables ), a number of roles. Approaches should:

• be based on principles, patterns and exemplars so that they can be easily adapted (e.g. for organisations or projects).
• be supported by appropriate tooling (systems, solutions, tools), semantics (language, notation, syntax and format) and associated techniques are key to the effective use of approaches that aim to deal with complexity.
• provide an overview for experienced practitioners. It should not be expected that anyone other than an experienced practitioner, or someone mentored by an experienced practitioner can successfully apply the approaches as attempts to obviate the need for the judgement are doomed to failure ).

Approaches can always be improved and we need to constantly assess approaches for gaps, areas of improvement etc.

What do we mean by experienced practioners
Experienced practioners are a critical to the successful implementation of approach. They stay abreast of industry and academic developments. They seen success and failures, both appling the approaches themselves and having supported others in applying them. Ideally they are open minded and realise that in immature disciplines in particular the various apparently divergent approaches being advocated by different groups may all have insights to offer. They are able to QA the results of an approach. And s a result of all of the above they are able to instantiate an approach.

What do we mean by an instantiated approach

Approaches need to be adapted to reflect many things including:

• culture and language – both the social and organisational cultures (including of course regulatory and legislative environments), and the terms and terminology being used

• size and nature of the organisation – clearly an approach suited to 1 person or a small team may differs from an approach suited to a large team, enterprise or sector

• focus and orientation – approaches are often oriented at achieving set of goals and measures. The priorities (of the people seeking to apply the approach) and therefore how the approach should be applied varies. We could think of gross measures e.g. are we more focused on cost (to own, operate etc.), time (e.g. speed), risk avoidance (e.g. robustness, safety), etc. Clearly the approach to constructing road transport solutions differs in different circumstances e.g. formula one cars, urban transport, rural transport, fuel economy rallies etc.

• tooling and technology – many approach are defined independent of the tooling and technology. This usually mean: the approach in generic terms (that may be hard to understand or ensure consistent application of the term), and that the approach may not take advantage of the features and benefits of classes of technology.

When an approaches has been instantiated we should have a succinct unambiguous set description of what needs to be done, by whom, how, where and when, using what etc.

Notes on terms
Approach - I prefer the term approach to the term method (or methodology).
Constructs - Systems, database, models, technologies etc.
Deliverables - A Miessian view of deliverables distinguishes work products (which are not delivered per se) from deliverables that are the final products delivered.
Exemplars - Examples are believed represent best practice
Approach overview - check lists, templates, exemplars, tips on techniques memory joggers etc.
Approaches with expertise - an approach is not a silver bullet

Strategy and architecture must enable action to be useful (e.g. transformation, optimisation)

The purpose of strategy or architecture work is to either support a change or to manage risks. In either case for S&A work to be useful - it must enable decisions to be made that result in correct actions. The risks are often focused on regulatory and compliance issues (e.g. stay out of gaol, stay in business) and the changes often focused on outcomes (e.g. value, performance, profit etc.).

Too often S&A work is undertaken as a philosophical exercise - where the love of knowledge for its own sake seems to be objective. Sometimes it is used by sophists to support a pet project, technologies etc. In neither of these cases is it useful.

For many years I worked on projects. These projects all aimed to achieve transformations or optimisations (reduce cost, increase revenue, reduce risk, improve outcomes etc.). I think of "transformation and optimisation" (T&O) as long latinate words for shorter simpler English words "change and make better". There is much research that shows that large complex projects are seldom well delivered. There is also good research that indicates that the fundamental issues are the failure to deal effectively with complexity (e.g. complexity in the organisations, complexity in the task sets, complexity in the technologies or materials).

My focus on Strategy was based on a belief that successful T&O projects required better approaches to knowledge management and business decision making. These approaches need to deal with the complexity of the issues, the multiplicity of stakeholders, the nature of the enterprises involved.

This is one of the reasons I have called my venture ESTO i.e. to acronymically preface the goal (TO) with the key enabler (ES). There are other reasons for ESTO - that I won't go into here.

Enterprise Architecture can't be done by Enterprise Architects (it needs to be done by the Enterprise)

Enterprise Architects keep wondering why their Enterprise Architecture initiatives fail.

They find all sorts of people to blame e.g. internal sponsor, business units (autonomy), vendors, economy, etc.

The real reason they fail is that in most cases the Architects fail to lead and coach the Enterprise so that the Enterprise can record, develop, extend and analyse how and why it operates (including its use of technology). Rather they attempt to do the Architecture for the Enterprise (or get consultants in to do it).

It is a little like employing someone to diet or get fit for you. It is unlikely to change you (or the Enterprise) unless you (or the Enterprise) does it.

What does it take to be good at Strategy and Architecture

What is required for you to be good at something e.g. strategy and architecture.

I think there are at least 5 things that you need:

• aptitude - S&A requires an innate ability to see patterns, form abstractions or generalised cases (organise, classify), to think laterally. Aptitude can't be easily taught. In most arts a key thing is the ability to accurately perceive.
  
• experience - S&A both rely to some extent on a mix of wisdom and common sense. Common sense seems to be quite uncommon, but as one makes mistakes - if one pays attention, one can acquire it. Perhaps the understanding below could be considered to be covered under the heading of experience - but I mean experience in a far broader sense. It involves learning a multiplicity of disciplines and life skills. Experience is also something that can't easily be taught (despite what MBAs may suggest) - some things needs to be experienced. It is what help tell you that something doesn't feel right even if you can't articulate for the time being why.
  
• understanding the environment and technologies - S&A in any field needs to be cognisant of the realities of what can be achieved in the environment in question using the materials available. This can be learned. It may take a while to internalise it depending on the domain but if you don't know you can usually rely on the expert advice.
  
• understanding the tools and techniques - S&A needs to be done using tools, methods and techniques actually orient at the type of S&A you wish to do (e.g. those suited to collecting information from the audience and communicating to the audience). This can be learned - and it doesn't usually take the long.
  
• willingness to keep learning and keep thinking - to reinvent, to reconceive, to question.
  

My current focus is enterprise strategy and architecture. But my original focus was building architecture and design. Anyone who has seen good architecture knows the architect needed:

• aptitude - and I would content it is clear to anyone in any school of art or architecture that some people have talent and others don't.
  
• experience - I was always told and now believe that architects don't reach maturity until they are at least 40.
  
• understanding the environment and technologies - sadly some architects keep forgetting the need for this (and left to their own devices produce building that leak, fall down, can't be built, or excessively expensive etc.).
  
• understanding the tools and techniques - architects have developed over hundreds of years sets of artefacts to the communication they require (plans, elevations, sections, details, specifications etc.). More recently over a few decades they have translated these techniques into CAD and come up with new ways to communicate (animations, simulators of various kinds etc.)
  
• willingness to keep learning and keep thinking - few can imagine a successful architect that doesn't have this trait. Nor a good town planner that lacks it.
  

When I realised IT was a fashion industry

When I realized with horror I was working in a fashion industry called IT
I first worked with a partially object oriented (OO) system in early 1980s. In the early 1990s I met a sage old Welshman who taught me how OO could be applied to the solicitation, analysis and recording of business requirements. He had a sound method and language for doing this that was very effective with business people, and that provided useful information for technology oriented people such as developers. Then a number of the more popular methodists sold their souls to a commercial venture and the focus of OO analysis was irrevocably re-centred on approaches ill-suited to business users. My Welsh OO mentor treated this with surprising equanimity and said “well of course we are in a fashion industry".

fashion – a vogue or trend, a prevailing mode imposed or favoured by those whose lead is accepted; attention to the latest trends, something in popular favour

I immediately bristled at this. I had always regarded IT was an engineering discipline (scientific, methodical, logical etc.). Over time I realised that I was living in the past.
When I learned programming at school in the mid 1970s it was taught by our mathematics tutor. At University the IT department existed within the mathematics department, and was lead by people who focused on logic and numeric methods. Most of the people with an interest in computing had developed the interest as it was necessary for their scientific discipline e.g. from nuclear physics to acoustics.
I had pretensions of being an artist, and instead majored in architecture. I lived for years with a fashion designer (and experienced the opening of boutiques, the emergence of collections, etc.). So I thought I could distinguish between science, art and fashion.
I didn’t have much time for the fashion industry i.e. how anyone could take seriously "yellow is in this season". What does it mean? It means that everyone has enough of the blue-stuff we sold last year, so to sell more we need to convince them blue is no good, and thry have to buy our new yellow-stuff. Or that blue-stuff always looked awful and we only just realized it. To me fashion at worst a sophisticated form of deceit; and at best played on human weakness, gullability and insecurity (the need to follow the flock), and in the process promoted gratuitous and wasteful consumption.

So when someone suggested IT was a fashion industry, I took offense. When I calmed down I realised that he was right. Much of IT had moved from being something like a science, or an engineering discipline to a fashion industry. Where something is in season - and things that were perfectly good last season are now eschewed for no real technical rhyme nor reason.

Fashion industries need to make people believe that what they own (or know) is no longer acceptable so they feel compelled to buy some new thing that has been produced (or conceived of). Marketing people in the USA in the 50-60s sought to change the appearance of car models each year (despite the negative impact on cost and reliability, and the unnecessary engineering, etc.). Of course this cancerous influence on the car companies will likely lead to their demise.
Fashion being prominent when utility is easily achieved and the rate of technological innovation is low (shoes, clothes etc.). I think it is inappropriate in an industry such as IT where there is so much still to be achieved and where real innovation continues at such pace (and I think it remains inappropriate in the global car industry).
Once people bought accounting systems now everyone needs an “Enterprise Resource Planning” system. Preferably one designed for a major manufacturer and advocated by a fashioable “independent” consultant. Perhaps people can’t justifying paying so much for accounting systems?

An enterprise PC’s main legitimate use is to: access enterprise systems, some word processing, work on a few spreadsheets, and enable email and Web browsing. As these requirements haven’t really changed what drives the upgrade cycle i.e. the adoption of new software and worse still new document standards, which in turn drive the neeed for new hardware and configuration services?

It is miracle of modern marketing that someone managed to make people care about an operating system (OS). Almost every significant electrical device has an OA (or several of them in a multiprocessor system like a car). Yet in with no other electrical appliance from an iPod, to a phone, to a game systems to a VCR to car does the average person really know the name of the OS, or care about it, nor would they dream of upgrading them (and this is in fact how it should be).

There may be nothing wrong with indulging an interest in fashion e.g. for clothes, cars or technology, if you do so with your money. At least in this item I won’t say fashion per se is bad, but it is an indulgence. The same is not trued if you do it with other people’s money, and pretend it is driven by necessity.

Vendors of course drive fashion industries so they can sell things. That is their role, hence the name “vendor”. The real problem however is not the vendors. Part of the problem is the people who know (or at least are paid to know) there isn’t a real reason to discard old technologies, or methods – and are spending other people’s money. Most of all it is the consultants and professional prognosticators (those whose lead is accepted ”, who need to lift their game – and tell the truth about IT’s dirty little secret.

In others item I write further about the adverse impact fashion on: design; development methods; analysis; etc. For now I will leave you with a quote:

I could discern omens of nothing newer than the old fate
of the sequacious: to be for ever at the mercy of the
exploiting proclivities of the bold and buccaneering in
their bullying and greed.
[Prelude to Waking, by Miles Franklin, 1950]