If and when you can help people with strategy, architecture and transformation challanges.

In deciding if one can help people improve how they do strategy, architecture and transformation challenges the decisions are:

1. Do they recognise the need for a strategy and architecture - as a platform for informed decision making on transformation and optimisation initiatives. If they don't then point them at the material that explains why and leave them for a year or two.
2. Do they recognise the current document based, and often consultant lead, approaches to strategy and architecture as mechanism for decision making for transformation and optimisation fails. It fails for everyone but the consultants and the perhaps the authors of the documents. If they don't then point them at the material that explains why and leave them for a year or two.
3. Do they recognise that systems architecture and software engineering  methods and modelling (e.g. those aligned detailed modelling e.g. ER, BP)  to strategy and architecture are oriented at wrong things for the wrong people. If they don't then them point at the material that explains why and leave them for a year or two.
4. Do they recognise that what is required are wisdom management solutions where all stakeholders can access information in ways suited to the tasks they perform, so that industry best practice can be supported by task specific solutions that all leverage off a common view of the enterprise are required to make rapid and cost effective progress (or do they want to reinvent things for themselves because at heart they are want-to-be taxonomists, methodologists, architects or developers). If they don't then them point at the material that explains why and leave them for a year or two.
5. If you get here - you can explore with them issues associated the cultural changes in the organisation and look at solutions and methods that support decision making and knowledge accretion.

The bottom line is you can't help people who don't want to be helped - and the 1st they need to make (for themselves) is to recognise there is a problem and they need to do something. See the 12-step programme for treating addiction to failed ways of doing things.

Remember Planck's Principle (not his constant) - "A new scientific truth does not triumph by convincing its opponents and making them see the light, but rather because its opponents eventually die and a new generation grows up that is familiar with it."

12-Step program for Enterprise Architects

EA seems addicted to labour intensive work done with unsuitable tools or in documents.

You could imagine a session - where I stand up in front my peers and say "Hi, my name is Michael Ellyett, and I am an Archaholic addicted to using tools and methods that don't work for my enterprise... "

Here are some initial thoughts on how to overcome this addiction - based on programs that work for other addictions.

1. Admit that what we are doing doesn't work. It makes you feel good but doesn't do anyone much good in the long term

2. Recognise that something beyond what we do and use at present is needed to restore us to sanity.

3. Make a decision to think rationally about why we are failing. Rather than pretending it is all OK, or will be OK next time, or blaming others.

4. Make searching and fearless inventory of what we are doing and why.

5. Admitted to ourselves and others the exact nature of our wrongs.

6. Put aside our semi-religious beliefs in framework and methods that everyone says should work

7. Work out how to do things that actually contribute to goals others have

8. List all of work we have done badly that could have been done better.

9. Make amends by telling the people we have worked for and with that we recognise the error of our ways, apologise for our past failing, and are committed to breaking our addiction to tools and languages we are addicted to - but that don't work for the enterprise.

10. Continue to take personal inventory and when we were wrong promptly admit it.

11. Seek through honest and open communication to improve our thinking on what is required

12. Having had an intellectual wakening as the result of these steps, and try and carry this message to others.

Sustained value from strategy and architecture work

The world is full of people who say they can do strategy and architecture work - maybe they can, maybe they can't.

I don't believe it can done in a such a way as to produce sustained value and lead to self-sufficient organisations unless it is done in the right way, with the right tooling. I have never seen anyone, anywhere do this.

Giving some point advice e.g. a list of programmes to be initiated, a list of changes required etc. - no matter how pertinent and correct isn't quite the same thing. Where point means relating to this problem, with these goals, in this situation at this point in time.

What I mean by sustained value is a strategy and architecture that can be kept current, used to analyse what should be done as circumstances change (regulatory, market, technology etc.) and what I mean by self-sufficient is the organisation can maintain, integrate, extend etc. the knowledge of their enterprise and its environment represented in the strategy and architecture. Albeit that they may call on some expertise for extending the scope of depth of its application. (Cf. "give a man a fish and you feed him for a day, but teach him how to fish and you feed him for a lifetime").

If we compared this to a town plan - what I am say is:
Giving some point advice (e.g. build this infrastructure or don't build the airport there) - no matter how pertinent and correct the advice may be - is not the same thing as providing a city a mechanism for maintaining information that will allow them to make these types of decisions in future. In the 1st case maybe I don't need a co-ordinate system (a framework), a map, sets of building codes and standards, places to record information on the existing situation (assets, features) and expected changes (demographics, technology, projects) etc. - I can all this in my head, articulate the relevants aspects in my report and make my recommendations. The problem is that most of critical knowledge wouldn't be available for the next decision. What I would have done is made myself more valueable - good for me, not so good for the client.

Few would mistake the giving of this point advice as establishing a strategic and architecture capability. However this mistake seems commonly made in IT.

CIOs need to adapt to the new world

In this item "Most CIO dinosaurs heading for career ice age" the author correctly identifies the need "what's needed is distributed decision-making, rapid response, the use of ad hoc teams, and leadership through collaboration rather than authority."

A question that follows from this is what decision support systems are required to enable this behaviour - certainly not the Excel/Visio/Powerpoint/Email mix that is used by most of the IT organisations to manage the knowledge needed to make decisions.

Nor the specialised tools/languages/systems oriented a various silos e.g. CASE tools and modellers (assured to alienate most non-developers), BP modellers (that operate discretely), CMDBs (with their detailed inventories of current state) or to confuse the issues by putting all ones hopes in yet another paradigm e.g. SOA (having witnesses that past paradigm's function, 4GL, client/server, data, object, etc. haven't solved the problem).

So what is required is a mechanism that allows knowledge to accrete, for all to participate in the gathering an use of information.

This requires some CIO leadership as it requires:recognition that some changes are required i.e.
- current silos of data (and worse still documents) don't work
- a small/minor behavioural change is required by many people i.e. where the record information
- a systems solution is required to enable the behavioural change and integrate the data held in silos.

Many CIO abnegate the need for any significant change and hope that existing strategy and architecture functions (themselves suffering from being yet another silo) can solve the problems within their ambit.

Knowledge needs to be collected from natural owners within the enterprise

This items starts with a high level summary with a few pictures. Following that there is a detailed discussion.

Summary high level summary
Asking all the people looking at single model doesn’t work:

Each person has a different model (data and way of looking at it) they are mainly focused on:

Asking people to deal with models with data in it they don’t understand (or organised in a way they don't understand) won't work well
:
Asking people just to deal with data they do understand will work:

This allows us all to have the models we want composed of data that others can interact with (i.e. examine, keep current etc.)

Detailed discussion

The problem
Most people accept that a critical need of large, complex enterprises is to effectively manage their knowledge about how they operate and seek to operate. Without this knowledge they can't make informed decisions about how to make transformations. Models of the enterprise contain knowledge and support decision making. However, modelling has almost universally failed to deliver on its promises and to be effectively adopted as a way of managing knowledge to transformations in large enterprises.

This article draws on a decade of experience working with a wide range of clients undertaking transformations in many geographies and sectors. It looks at the question of why modelling by itself fails to provide an effective solution for enterprise decision making. Future articles will explore the characteristics of solutions and strategies that work.

Independent, separated data for modelling
To support business transformation, enterprises need to develop decision support solutions of which models are an essential component. For this approach to be effective, it is important to be able to separate the enterprise data from the models which represent the data. There are two reasons for this: the nature of models and nature of organisations. We'll look at models first.

MODELS
What do we mean by models?
Models are particularly useful for answering questions. So modelling is often used in design and planning when many alternatives are being considered. Models can also often be used to create visual representations, which have the power to provide an immediate perspective on a lot of data. The way something is modelled depends almost entirely on the purpose of the model: that is, on what you expect to learn from the model, and to some extent how you want to visualize things.

Models consist of data elements related in fairly complex ways: objects, properties of objects, relationships between objects, calculated values, and so on. As they are always designed to achieve a purpose – and no one model can achieve all purposes, – data-elements will usually appear in many models, each with a different purpose (At this point we could discuss metadata and how it is maintained. That, however, along with semantics, ontology, taxonomies, patterns and so on, is best avoided in an introductory article)

More precisely, I use the term model to mean semantically explicit representations of some perceived reality. For example, models may be presented visually as diagrams (but clearly most diagrams are not models). Or they may be presented numerically or textually: for example, a cashflow spreadsheet and a project plan are both models.

Personally I remain skeptical of most things purporting to be models that are presented in text documents, drawings, or presentation tools such as Word, Visio, and Powerpoint. Why? Because it is too easy to make things look the way you want them to look – and this is harder with real models. Of course talented people, as well as lazy people, can create models that don’t represent reality. But fortunately these are usually fairly easily tested.

The inherent multiplicity of models. An analogy from architecture
The way things are modelled depends on the questions to be asked of the model. If we think about something we are all familiar with, such as a building or a city, we can see that the way we model it will vary depending on the question being asked. Here are just a few examples of the questions asked of buildings:
- usability: What will the user experience be like? For example: What will it look like? (data on: light sources, surface textures, transparency and translucence) How it will behave acoustically? (data on: materials' acoustic properties, and the location and disposition of build elements, noise sources)
- availability: How resilient will it be? How will it behave in distress? (data on: the nature of the materials and how they respond to stress, how building elements are connected, etc.); how it will behave in an earthquake (data on: Structural properties, connections etc,); how it will behave in a fire? (data on: how materials with heat, how they combust etc.)
- cost to create: How much will it cost to establish? (data on: materials, products, volumes and surface areas, etc. Product and material costs, labour rates etc.)
- cost to own: How much will it cost to maintain and operate? (data on: thermal properties, service costs and lifecycles, energy utilization, ongoing costs for services, etc.)
- capacity: How it will perform with respect to throughput? (data on: elevators' performance and their patterns of use, vehicular and ambulatory egress patterns and loads)
optimization: where should things be for optimal performance, e.g. space planning? (data on”costs of people and things, degrees of interaction, etc.)
- value: How much value it will generate? (data on: rental properties e.g. useable floor space, rental rates, etc.)
- greenness: What will its carbon footprint be and how can this be reduced?
- connectivity: How well will WiFi will operate in the building and how can this be improved?

So, what does this tell us about modelling things
To answer the questions we may wish to ask about a building many different types of models may be required. The questions reflect different criteria or constraints that need to be considered in design and planning. The way things are presented and answered reflect the level of interest of different stakeholders: property developer, property owner, property occupier, real estate agent, various construction trades, and so on. Each stakeholder is the natural owner of some data. The multiplicity of models needed has important consequences for the data on which they are based.

Some data-elements are common to many models. For a building, these might be the number of floors, the location, the major walls, etc. Other data-elements are unique to particular models, for example a range of material characteristics, how things are connected, market characteristics, physical characteristics of the location, and so on. And inevitably, we will find that data-elements originating with one particular model need to be reused in another; and probably augmented or renormalised to enable the models to be properly correlated.

The success of our suite of models is going to be critically dependent on collecting and organising the data effectively. The set of models may well represent the sum of our knowledge of the building, but they are not necessarily a good way to manage that knowledge.

The data will come from many different stakeholders, who are often the natural owners of the data As we discuss later, it's important that the various stakeholders can contribute with needing to understand each other's models and domains.

What kind of data will we need to model an enterprise?
The building analogy illustrates that it is unlikely that we can ever define a-priori a canonical set of data-elements which will suffice for all our models. The nature of the questions determines the data required. Notice how carbon footprint and WiFi performance feature in the list presented earlier: despite the fact we have been building for millennia, new questions – and therefore new data requirements – continue to emerge from changes in our environment and behaviour. As with buildings, we need to understand enterprises from many perspectives:
- how our users (customers, partners, employees) will perceive and react to us
- how resilient our process and systems will be
- how much changes will cost to make
- how much things will cost to maintain and operate
- how things will perform, where things should be (data, systems, people) for optimal performance
- how much value will be generated (by products, services, systems).
And, as with buildings, the success of our management of the knowledge of the enterprise is going to depend on effectively collecting and maintaining data contributed by many different stakeholders.

ORGANISATIONS AND PEOPLE
Fragmentation of interests in complex organisations
In an enterprise many people will be interested in things from many different perspectives: economic, operations, organisation, product, market, contracts, and so on. They will be interested in these at different times: now, next year, and in the future. Most of them, while having a broad interest in many aspects of the enterprise, will only have a detailed interest in, and definitive knowledge of, the specific subset of the enterprise they are focused on.

So while many people may be interested in the services an enterprise provides, some will be interested in these at purely a business level and others interested in the technical aspects, some will be interested in costs associated with a service, some with how the service is delivered (procedures, policies, information), some more with who or what performs the service, some with what agreements are associated with the services. And so while many people may be interested in a particular service, few will have definitive knowledge of all its aspects. This is clearly less true in very small enterprises, those that have a very slow rate of change, or those that are intrinsically very simple. In what follows we are really talking about large, complex enterprises with an ongoing need for change.

Fragmentation of models
Often a specific set of data-elements is first considered, and captured in a structured and semantically explicit way, when something is being conceived, planned or changed and an appropriate model is needed. Later these data-elements, whose initial purpose was design and planning, are reused in different ways by other models (reporting, etc.). Eventually when things are operationalised the data-elements are updated by different groups with different interests.

In this situation the form of the data-elements tends to be tightly coupled with the specific purpose and implementation of the original model. This militates against most other people interacting with the data-elements. It is not that most people are not able to understand the model if it is explained to them – it is that they don’t want to understand a model created for a purpose different from their. That is, they don’t want to invest time and energy learning about data and relationships that are, from their perspective, extraneous.

So for most people, only interested in a small subset of the data contained in a complex model, the model will be too complex for them to grasp, or contain too much extraneous data. The model will seem like a complex monolithic assemblage of data not necessarily well suited to harvesting the data for reuse. It is certainly not something most people will feel comfortable updating. This is especially the case if the people are not modellers by nature or not familiar with the modelling tool or technology that was used.

The more generic the modelling tool, the worse this problem is. That is, the more the alien tool becomes an obstruction to shared understanding. Ironically, this obstruction is commensurate with the potential ability of such tools to manage knowledge.

Types of tool
Generic modelling tools (such as meta-modellers, spreadsheets, etc.) allow users to define their own semantics (Though, obviously, meta-metamodels constrain these types of tools). These tools are useful because of the broad set of semantics they can deal with and the way they allow business people to model in a language that makes sense to them. This means that if an insurance company wants to model a policy or a claim, or an entertainment organization wants to model a theatre or a theme park as objects – with specific properties, relationships, calculated values, and so on – then they can.

By comparison, dedicated modelling tools deal usually with a very narrow set of semantics. A planning tool, for example, might essentially deal with just tasks and resources; a data modelling tool with just a half a dozen object types; and so on.

The tool impedance problem – an example
A spreadsheet is a modelling tool that most of us are familiar with. Spreadsheets can be used to create complex models. They are also effectively, in a business sense, meta-modellers. The objects that can be represented are constrained (by validation, formatting) and the relationships that can be defined are limited (to formulas, lookups, etc.), but a set of business semantics can be defined.

Many of us are quite capable of using spreadsheets and creating such complex models. Yet when someone presents us with their complex spreadsheet containing lots of data and many relationships representing business semantics – and they ask us to review it and perhaps update some data – most of the time our reaction is “I don’t really want to the spend the time understanding your model, just tell me what you want to know”. This is a reasonable reaction.

Which brings us back to data independence
The unavoidable conclusion here is that there must be neutral way, independent ofany modelling paradigm, for updating the data-elements represented in a model. A way that suits the interest and level of understanding of each person or role expected to be involved. A way, moreover, that ensures the data-sets are available for use in models of every kind: in other words, that make the data fully reusable. Only then will we have a virtuous cycle of data use and update that will result in knowledge being accreted as a natural by-product of day-to-day behaviour.

CONCLUSION
We have described the reasons that enterprise modelling has so far delivered less than promised. The problem so far has been that the datasets represented in models have not been visible in a form independent of models. The data have not been reusable by all models, all tools, and all people with an interest in them. The result has been incomplete and ineffective management of the knowledge, making models to expensive to populate and keep current.

Solutions to this problem will be the subject of the next article.

Limitations of documents - and why consultants like them

Documents are ineffective in supporting the operationalisation of processes, and the management of knowledge, about complex enterprises.

Accounting processes and knowledge
Imagine the accounting process - if it was implemented using documents (Word, Visio, Excel) i.e. if I am a simple organisation I could create invoices, make payments, create balance sheets, calculate tax, do reports, keep track of assets, answer questions from my customers on what they owe, etc. Now if I were the accountant - I could do this work using documents if the number of elements (invoices, payments etc.) were few, the rate of change of information about by assets was slow, and there were not many people asking questions or changing things.

Now if I were the accountant - I could do this work using documents if the number of elements (invoices, payments etc.) where few, the rate of change of information about assets was slow, and there were not many people asking questions or changing things.

I would effectively either do it using documents (Word) where the semantics are not explicit (e.g. where rate, hours and charge are just in written in the word document) or in a model (e.g. which calculates charge from hours and a table of rates). Clearly the model would allow me scale more quickly (make me more productive). This might encourage the business to see the value of the models and get me to extend their scope so I could record other information and answer new questions.

However as the number of elements I have to dealt with increases, the rate of change increased, and the number of people I have to communicate with increased. I will quickly become a bottle neck i.e. typing everything in to my models (or worse still documents).

Clearly I would be come a bottleneck. It would take a very large teams of clerks to get through the work - and still we would not be that quick at answering even simple ad-hoc questions. Now to do the job properly I would of course need sound methods and structures (frameworks) - but they would not make me efficient or agile.

Document and content management systems could exacerbate the problem - if it allowed lots of people to send me word documents about things that I had to deal with i.e. turn into invoices, payments, etc. It might give the illusion that the all the knowledge is being managed - but I would just get swamped.

The answer for a complex business must be a system (accounting) which allows information to be captured as a by-product of day to day work (entered by people at source), analysed and presented in the way that suits each audience (i.e. the system provides reports directly to people who need them). This has the advantage of meaning I don't require a team or clerks and the accountant can be removed from administrative tedium to focus on more strategic decisions.

Of course this would not suit the person who sells me the teams of clerks (consultants) to do this work - because now I would not need most of them.

Technology processes and knowledge
Critical knowledge about an enterprise is knowledge of: the environmental constraints (market, regulatory etc.); and how the environment affects the business strategy (goals, strategies, plans, products etc.), and how the strategy affects business operations (processes, people, information, etc.); and how technologies supports the business operations; and what changes are planned to all of the above. Some of the knowledge is required for operations and some for decisions on possible changes.

It used to be that the number of elements (systems, reports, applications etc.) were few, the rate of change of information about the assets was slow, and there were not many people asking questions or changing things (because usage was limited and constrained).

The number of CPUs per person in a business seems a reasonable proxy for complexity. Thirty years ago there was perhaps 1 CPU for 1000 people (e.g. in a thousand person organisation), twenty years perhaps there were 10 (for the same organisation), fiften years ago perhaps 100, ten years ago perhaps 1000 (as everyone had PCs) and now perhaps 3,000 (various servers, PCs, phones, NW devices etc.). So the complexity has increased by perhaps a factor of 3000 (i.e. 300,000%).

Now if I were the CIO and IT team - I could do this work using documents if there were few elements, a slow rate of change, and I were not asked about changes that often. Certainly thirty years ago, twenty years ago and perhaps fifteen years about - but over the last 10 years things have started to get too complex.

IT has become a bottleneck i.e. typing everything in to my models (or worse still documents), or often just keeping knowledge in our heads.

I need large teams of clerks to get through the work, I am not answering most simple ad-hoc questions. I get told that methods and structures (frameworks) are the answer - but no one can make them work.

Document and content management systems give the business the illusion that the all the knowledge is being managed - but actually I can't join the dots.

Of course the consultants in the areas (BA, BP, EA, Systems Analysts, Data Analysts etc.) are happy as I have endless need for them. Funnily enough none of them mention any systems based answers (unless they sell me a bureaux offering locking me into them).

Enterprise processes and knowledge need to be supported by enterprise systems
One can clearly see how enterprise recognise the need for enterprise systems in other areas as they have become complex and critical. It now needs to be recognised that processes for strategy, architecture, governance and transitioning of IT (and arguably the entire business) needs to be treated as an enterprise problem and provided an enterprise solution.



See related item: http://ict-tech-and-industry.blogspot.com/2008/08/stages-of-maturity-in-communications.html

IT Business Alignment

In a recent A&G magazine item "IT-Business Alignment" identifies IT-Business alignment as a top a concern amongst CIOs.

It is suggested the top enablers to alignment include: Senior executive support for IT;
IT understanding the enterprise's business environment; Business units’ understanding of the enterprise IT environment; a close partnership between IT and business; IT plans linked to business plans; good communications between IT and business; Business units's support (including staff and investment) for enterprise wide IT initiatives; Clear predictable corporate goals and directions; Business units sharing (not competing for) IT resources; IT and the business governance; Business units’ prioritization of IT needs; Clear ownership of IT-business alignment

It is suggested that: “Business people must recognize the most important thing they can do is act as a sponsor for an IT initiative...To do that, they need the IT management team to come in with specific ideas. Business executives are usually more than willing to support
them, but the initiative must come from IT.” I think that the reality is that business people can see that IT has not got its own house in order and simply don't trust IT. To say that “Business people must recognize ...” seems to me a little rich. I think "the IT unit must recognize that the business doesn't relly trust them and they need to come in with specific ideas on how to win trust, and that this IS an initiative must come from IT.”

So until CIO's take the initiative to put in place solutions that will ensure that they can communciate i.e.
- what they understand the corporate goals and directions to be (and how these link to business plans)
- what IT seeks to do and why clearly to senior executive (including IT plans linked explicitly to business plans)
- the enterprise IT environment to the business
- their understanding of the business (via their views of key relationships e.g. environment, goals, projects, operations and technology)
- how they have addressed IT governance.
- their model for prioritizing IT needs based on the business plans.
How can they expect to win the confidence of the business?

If they seriously think (being IT professionals) that they way to enable this communication is to use sets of disconnected Office suite documents (plans, project definitions, systems diagrams, process models etc.) - they must be dreaming.

See: http://ict-tech-and-industry.blogspot.com/2008/08/stages-of-maturity-in-communications.html
http://ea-in-anz.blogspot.com/2007/10/improving-its-reputation-and-alignment.html
http://ea-in-anz.blogspot.com/2007/09/why-dont-most-it-processes-work-well.html