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]

Technology perspectives driven by vendors, fashion and ignorance

Prompted by more maddening items on orientation

Firstly let me say that I believe the following perspectives should be considered as 1st order when looking at ICT systems:
- presentation (from services i.e. they are by definition presented, to interfaces)
- information (from knowledge to data)
- process (from a capabilitity, to a function, to a process, worflow, to step/activity)
- rules (from a law, to a policy, to a rule, to a decision and control mechanism)
- characteristics (from being cool, sexy to what some might call non-functional requirements)
- organisation (from culture, to organisation, to role, to people).
- location (from country, to region to specific location)

Key 2nd order elements are:
- components (from products to objects) which can often be consider assets

I would also think that technologies (products and standards) are used by the vendor community (products and consulting vendors) to drive an feeding frenzy in some new (actually not new) area each year or so - so that some new set of things can be sold.

Orientations over the decades:

• Information - When I 1st learned to programme the focus was on memory management and jumps in assembly langauges (there was no focus on presentation).
  
• Rules - Then it was on logic and alogrithims e.g. Fortran, Algol, SNOBOL, LISP (oriented around Formulas, Algorithms, rules for processing strings, rules for processing lists).
  
• Integrated - For a while real applications were then written in langauges that considered logic (presentation was fixed by the very limited range/type of devices; location/organisation/characteristics were effectively fixed by the integrated OS/HW). This was actually quite a productive time.
  
• Information - Databases emerged and information engineering became king. Everyone forgot about function points because all you needed as information model (not).
• Integrated - Then it moved to OO (and data and logic don't exist discretely). Unfortunately the methods were usually oriented at coders not business people.
• Process - BPR lead to a brief fling with business process orientation, but it was really just a way the consultants to pack as many graduates as possible into organisations so they could document what was alreading known. In the course of this "Imaging" vendors became "workflow" vendors, before coming "BP vendors" and of course now they are "SOA" vendors.
  
• Presentation - now with SOA we can focus on another set of technical standards and products.

Sooner or latter surely people will realise that all these perspective need to be considered (i.e.
presentation, information, process, rules and characteristics) and they stop throwing the baby out with the bath water.

An introduction to reference models

An introduction to reference models. Models are ways of organised information so it can be used to answer questions. Reference models provide a consistent (and often best practice) way of organising information about something. They may be used a categorisation structure or they may be considered high level elements that are decomposed into more detail.

Determinants - few integrated sets of these exist in the public domain. Ideally one would have things such as: Legalislative and regulatory RM (LRM)

Enterprise strategy - RMs covering: goals, strategies, measures etc. some example include: FEAF's PRM (Performance RM) and one would ideally also have a Goals RM.

Enterprise operations - RMs covering: products, services, functions and processes, information and data, policies and rules, organisation structures and locations. Some examples include: NGOSS's eTOM, SID, FEAF's BRM) etc. So one would have: Functional RM (FRM), Rules and Policy RM (RRM), Information RM (IRM), Organisational RM (ORM), Services/Products (SRM).

Systems and facilities - RMs covering: systems and facilities performance (e.g. SLA templates, technology goals/principles). Some examples include service and application RMs: FEAF's SRM, NGOSS's TAM), Technology RMs: FEAF's TRM, TOGAF's TRM. The connection of these internally may be between the SRM and the functional modules/services associated with specific suites or services.

Suppliers - Some examples include: sector classification schemes; channel models; agreement topics (contract templates). This would include a Vendor and products RM (VRM)

The RMs should:
- connect within each level and between each touching levels.
- connect to detailed extant views of the enterprise e.g. the FRM may connect to existing detailed process models, the IRM may connect to data models, the PRM may connect to existing KPIs, etc.
- allow direct impact analysis to be undertaken
- allow inferential analysis to be undertaken (I will discuss this in latter entries).
- be treated a set and applied

RMs are:

1. Most useful when analysable - whenf they are related so as to allow impact analysis (both between domains, and within domains). Unfortunately many are often presented diagrammatically (great for communication, hopeless for analysis) or represented using inconsistent semantics, modelling paradigms that can't be related, or using arcane technology terms that are not meaningful to 99% of the world (e.g. use case, actor, cardinality etc.)
2. Not a silver bullet - but there is little doubt that using reference will often accelerate thinking and reduce the scope for oversight. However the value of this should not be underestimated. For many large organisations it may take a team or 1/2 people working for a year or so part time to come up with the above. More often than not they never complete anything useful.
3. Need to be tailored and used carefully - as with all things that represent purported best practice they need to instantiated in-situ (using experience and judgement) to produce something that is useful in the specific set of circumstances.
   
4. Need to be analysable from the top (and bottom) - this is why absence of Determinants RMs is so limiting as ideally these would allow one to relate the circumstances to the strategy, and then from that the strategy to the operations; and the suppliers to the systems and facilities. It is why compliance issues seem so hard (and produce such a good feeding frenzy for consultants).