People get hung up on the word "Architecture"

In the inclusion of the word "architecture" in different a set terms seems to lead to some confusion that as the terms share the "A" word that ipso facto they have a lot in common.

People seem to think that the operative word in each of these terms - Enterprise Architect, Systems Architecture, Service Oriented Architecture, Solution Architecture, Infrastructure Architecture - is "Architecture" and this implies some kind of commonality of person, approach, skill set etc. When in fact the orientation is differs considerably and the the focus should be on the non-A word e.g. "Enterprise", "Systems", "Services", "Solution", "Infrastructure".

If we talked about "Designing an Enterprise", "Designing a building", "Designing a car", "Designing a town" - we would not think that per se these activities share a common method, common skills, common tooling. We may recognise that at the highest level there could be some common principles and that lessons could learned, and some techniques transferred, between these - but that would be about as far as we would go.

The "A" word means master builder. Historically a "master" would start as an apprentice, work for many years under a "master" progressively learning what worked and what did not (and developing extensive experience in the domain and materials) - and would eventually become a "master" themselves. Now people seem to disphemistically degrade the "A" by applying it to any design activity.

It seems to me that often the "A" is used to imply an air grandiloquence

Why do people accept these absurd new ... x formats for documents

It seems to me that the main reason for these new non-standard document formats pptx, docx - etc. is to force people in using a new document editing tools. The use of these tools will in turn hopefully force people to use a new operating system. This in turn may force people to upgrade their HW. All these changes will require more services i.e. installation, integration and training.

Now I know why the vendors of the document editing tools, operating systems, HW and services think this is an excellent idea. I just can't for the life of me fathom what why businesses fall for it.

No one has been able to explain to me with any conviction the benefit (e.g. the return), but everyone is aware of cost (investment). So how the ROI work exactly? So why do people do it?

I am constantly reminded of a Dilbert cartoon I saw long ago.
• Dilbert: I have to turn this fifty-page proposal into a one-paragraph executive summary for our CEO.- It's impossible.
• Dogbert: Simple. - How about "Give us three million dollars so we can buy cool technology, pump up our resumes and escape this festering boil you call a company
• Dilbert: I feel obligated to say something about our customers.
• Dogbert: How about "I'm glad I'm not one of them.

We can't blame the vendors. There job is to sell things (vend) hence the name.

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.