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

Projects are artificial constructs and often managed in ways unsuited to enterprise change initiatives

(project management for enterprise systems needs to be suited to the task)

Much of the approach management comes from project disciplines developed and honed in the construction industry e.g. focused on building a building. Unfortunately enterprises, and many of their elements, are quite different in nature to buildings (e.g. enterprises are more like a city). This is especially so of enterprise systems. Until the differences are recognised, understood and analysed - and the project management approaches revised to better reflect the differences - project management in an enterprise will under perform on the expectations (i.e. they will not typically result in on-time, on-budget and on-scope delivery). This extends to a set of projects or programmes and non-time bounded initiatives

How buildings differ from enterprise systems

Usage is clear and doesn't change - of a building and most components of a building. Before building commences (and usually almost at conception i.e. before design commences) the expected use is clear to all parties and doesn't change substantially. That is to say that we all know what a house, garage, etc. is for (how we expect to use it); what a bathroom, kitchen, bedroom, etc. is for; what a bath, window, bed, etc. is for; what a door handle, sink tap, bed side lam, etc. is for. In all cases usage is clear and doesn't change and it is known before construction starts, and in the vast majority of cases before design starts. To suggest that all parties clearly know what an enterprise system is for (and exactly how it is to be used), what a major module is for (precisely and how it will be used), what a user interface is for, or what a UI widget will do precisely - at the start of most projects is simply untrue.

Construction of a building is largely assembly - Constructing systems (systems: development, integration, tuning, customisation, configuration etc.) are not assembly tasks they are largely design tasks. The small design decisions made by the various building trades do not approximate in scope (e.g. the extent to which the design could be got wrong) to the level of design undertaken on the fly for systems.

Building's design is defined and explicit - As a result of a clear understanding of usage, material, methods and a way of communicating about buildings (that has evolved and matured), a building's scope is very well understood before construction commences. New systems enterprise's design is very seldom defined with the same degree of certainty so in practice much of the project management is associated with design of the enterprise systems

Buildings are completed - Buildings can be built and once built are essentially complete (and often remain largely unchanged for extended periods of time). Most enterprise systems are never really complete, they continue to evolve on an ongoing basis - so while the there may be a period during which major changes are made, the nature of work does not stop at the end of a project (it may diminish, or be postponed briefly).

Buildings are more discrete externally - A building can be seen as successful by itself - and while they connect to other built-elements (things) the nature of the boundaries are, by enlarge, well understood by all parties. Another way of seeing this is to recognise that my house can be complete and useful irrespective of the state of most of the other buildings in my street - but most enterprise systems rely on a very complex web of interconnections with other systems to operate (networks, identity, office suites, printers, third party systems etc.).

Buildings are more discrete internally - Similarly the internal elements of a building can be seen quite discretely by all parties. Another way of seeing this is to recognise that my bedroom can be completed and useable - even if my kitchen is not. In enterprise systems it is far more difficult to confirm that discrete elements are working.

Technologies and materials understood - The characteristics of a materials used are well understood. Frequently enterprise systems are built using technologies that have not be used extensively before by the people doing the work (at best similar of analogous technologies, or earlier versions, may have been used). Often regulatory codes are in place reflecting what does and does not work

Methods are mature - The exact methods of design and construction are not understood or agreed to on an industry wide basis. With buildings the set of documents used to describe the building is fairly standardised irrespective of which organisation does the design and within each area the detailed documents are also well defined (structural, HVAC, electrical, plumbing, etc.). So codes of practice exist and usually WBS for sub-aspects. Compliance with best practice is by regulation and not determined by a planners powers of persuasion. This is not true for enterprise systems - practioners argue over both high level methods, and how detailed methods should be applied.

Reasonable tests are well understood - As usage, materials and methods are well understood the functional and non-functional behaviour is well understood e.g. I know I should be able to walk through a door, and that a brick that is thrown can be expected to break a window - but not destroy a column.

The reason the words "by all parties" occur so often in the above is because specialists associated with enterprise systems may assert that their level of knowledge approximates that of their building counterparts. But the issue is that everything needs to work together - so what we really need is for all parties (user, designer, construction trades, operators) to all know how everything is intended to work together. For buildings there are exceptions to all of these rules - by in large they are true - and where they are not true specialised buildings (opera houses, stadia etc. ) these projects run into difficulty as well.

So projects are, in many of the uses they are put by an enterprise, artifical constructs used to provide certainty regarding cost and time - implicitly recognising the scope is a variable. Unfortunately most traditional project management assumes scope is fixed - and often project management becomes a function that communciates how far time and cost are to exceeded.

Essentially, enterprises want to make changes to how their business operates (which can be described in a business architecture) and the technologies, assets and services they use (which can be described in a technology architecture) based on strategy (constraints, goals, strategies, initiatives, plans etc.).

What is needed is a way to describe the changes required (holistically) then to understand what aspects of change are to be made in each project silo (and where common elements are affected) and to allow analysis to be undertaken across all projects as new information comes to light e.g. usage becomes clearer, design matures (as more is learned about the materials and how they are best assembled); as boundaries with and between elements clarify; as tests of quality and success are refined. The exact requirements; exact design; and exact project definitions and boundaries and inter-dependencies emergence from mists in parallel.

The approach I advocate achieves this.

Enterprise transformations and knowledge management and the prisoners' dilemma

Why is that while objective analysis indicates that only a very small change of behaviour is required by many people in an enterprise, especially one undergoing transitions, to significantly improve the outcomes for all - but no one is prepared to make the changes.

Stages of maturity in communications - strategy, architect and governannce functions

(to communicate a simple organisational problem with a few simple pictures)

Overview
When large enterprises are going through transformation (new products, mergers etc.) documents are ineffective in communicating the complex issues (and document and content management systems can exacerbate problems). As a result people involved in transitions spend time much time in meeting, in emailing and on the phone.

Strategy, architecture and governance are roles are established, but they can't manage the knowledge explicitly, don't scale and the reliance on individuals represents a risk to the business. Modelling manages the semantics, and provide powerful analysis and visualisation capabilities, and provides a source of record (reduce the risk) - but they don't scale and most models don't suit most audiences most of the time - so as communications mechanism they fail.

A knowledge repository is required which allows information to be captured as a by-product of day to day work, analysed and presented in the way that suits each audience and allows internal people to focus on actual strategy, architecture and governance while minimising the need for external consulting services.

Documents are ineffective in communicating complex issues in large enterprises Documents which encapsulate business concepts e.g. strategies, plans, initiatives, programmes , designs etc. are ineffective in communicating to most of the people most of the time. Many people create documents that communicate things to them, and their peers i.e. from their perspective and oriented at their interests. They make documents available to others in the expectation that they will effectively communicate to different people, with different interests and different perspectives. Most people if they looked at the evidence would realise this doesn't work (i.e. it demonstrably fails).



The set of all documents contains sets of related concepts (constrains, goals etc.). The set of concepts may relate to any aspect of the business (product, organisation, location, behaviour, risk, projects, technologies etc.). In the documents, usually most of the relationships between concepts are implied and unweighted (semantics are inexplicit) - because the author or original audience would be expected to know these relationship implicitly.


In the real world people need answers to questions quickly (without lots of reading)
When any issue arises or any decision needs to be made what people want is to understand an issue, or set of issues that is currently of interest to them i.e. How the concepts are related.

If one read, understood and internalised all the related documents (assuming they can be located - and were all consistent) one may perhaps get the understanding required. Unfortunately few have the time and capacity to do this.

Document and content management systems can exacerbate the problem
Document and content management systems, or content may help maintain the set of documents - but they don't address the issue knowledge held within the documents it is not explicitly related (often it is not even very explicitly defined) i.e. the semantic is not explicitly recorded (within documents, or across sets of documents), consequentially they can't address the issue that the set of documents are inconsistent. So in a sense these systems exacerbate the problem by facilitating the publication of even more documents, and maintaining the illusion that if the documents can be located people will understand all that they contain.

Meeting mayhem follows
As the business people need to know the answers, and don't have the capacity to read all the documents - what they do is communicate amongst themselves to get a handle on the issue of interest (workshops, meetings, emails, phone calls etc.). They work out what they need to do (though it takes time) and move on - only to repeat the exercise with next issue (or on the same issue sometime latter).


Strategy, architecture and governance functions are implemented
In most organisations eventually people realise that there is an issue and they put in place people (strategy, architect, governance) who aim to consolidate this knowledge. These people may even create their own documents - that aim to consolidate information around different perspectives (there are of course an uncountable number of different perspectives that occur over time in an complex enterprise). They become someone you can ask questions of. Unfortunately their capacity is usually fairly quickly exceeded - so they become people who know a lot (but seldom enough on any topic), but produce little of value.



Strategy, architecture and governance models eventuate
Some organisations realise that implementing this knowledge management function in a person or team (and their documents) doesn't address the issue of the semantics not be explicitly understood so they move to putting models in place. Models can explicitly manage the semantics and aggregate knowledge from all the sources. The models can, in theory, now answer all the questions. However there are two problems.




Models don't suit most people most of the time
The 1st problem is that while the models may be able to answer all the questions most people don't want to deal with these complex models (i.e. so for many they don't act as an effective communciation mechanism).

Models are time consuming to maintain
The 2nd problem is that one creates a bottle neck i.e. in the effort involved in maintaining the models. Usually people start by aggregating a small subset of the knowledge in the enterprise (i.e. the inputs and outputs that relate to a small set of people and issues). People quickly realise that the more knowledge that is in the model the more powerful the models can be a relating information and answering questions. Unfortunately this increases the load of model maintenance and modelling function become a bottleneck. There are bottlenecks on both the input side (maintaining models) and the output side (explaining how to use the models to answer questions).



A knowledge repository is required
Eventually people realise what is required is a knowledge repository - which contains the information held in the models (all the models) . This allows the strategy, architect and governance functions to be effective i.e. they are no longer bottlenecks and can add much more value. The repository can be used by all parties to record information, answer questions and produce the documents that each requires.



Why consulting firms don't get this
Well they do get. It just doesn't suit them. Smart consulting firms know that if models are not used at all then the knowledge and expertise they offer will always be required (an almost endless demand for their services). If models are used - and they provide the modellers - they will likewise ensure lots of modelling work. Similarly some of internal the people tasked with peforming these functions may fear that if they used such a solution - their work would evaporate. Ironically what actually happens is that they no longer have to act as typing pool (transcribing information) and actually do what most of them are most interested in doing i.e. doing actual strategy, architecture and governance thinking.

Industrialisation of IT

(prompted by an organisation with a method for really focusing on business value)

A confluence of factors now allows some organisations to adopt dramatically new ways of getting more value from the systems more quickly - with less investment and less risk. Essentially this involves a non-incremental change (revolutionary) as aspects of IT move from being a craft to an industrial process.

The factors include: the existance in many organisations of extant suites that are capable of supporting most of the existing business processes; the adoption of standards for controlling how systems processes are orchestrated; adoption of common mechanism for systems to communicate; and maturity of the approaches to modelling processes and reporting on the execution of those processes. The acronyms associated with these factors include: ERP, BPEL, SOA, BPM and BAM.

These new approaches allow models to be created that represent how the organisation operates and that at the same time link directly to services (existing, well engineering, industrially tested and documented) in the enterprise suites. Optimising the business performance then becomes a matter of analysing the process models and

It will substantially reduce the level of expenditure that has traditionally been associated with the wanton customisation through low level coding of large application suites (e.g. ERP systems). This customisation is usually poorly conceived from a business perspective i.e. it is expensive, time consuming, risky and worst of all moves the understanding of how the organisation actually operates into code (the organisation doesn't really understand or control). What the customisation does ensure is that large development teams are required - usually provided by one of the "independent" consultants who have lead the organisation down the garden path of customisation in the 1st place. Frequently it will also require additional hardware and systems software so all the vendors of products and services win i.e. everyone wins except the end user.

The class of organisations are those whose major systems are these ERP systems (and other such systems as they mature) and scope is determined by what these suites are designed to do.

As with any revolution the people who benefit from status quo (the craft model) will resist these changes. The crafts people in this case are traditional developers who wish to hand craft systems in preference to assembling solutions from parts.

During the industrialisation of manufacturing to stop the resistance they made machine breaking (industrial sabotage) a capital crime, executed some saboteurs and deported transported many as prisoners to Australia. Almost two hundred years latter we can only hope the resistance will be less vociferous.

If organisation move to this paradigm they can largely remove IT as a blocker to change and the IT organisation can be downsized and redesigned to focus on innovation.

Why organisations struggle with managing requirements

Why do organisations struggle to improve their approach to managing requirements.

Essentially because the industry doesn't present a common view of best practice, and frequently doesn't distinguish between different approaches to requirements management – i.e. high level vs low level –, or between the different possible approaches to low level requirements management.

Ideally at a high level enterprises should have a common way of defining requirements and assessing that they are met. At lower levels the methods should diverge depending on how the requirements are to be met – and the role the enterprise needs to play.

We can think of the ways that requirements might be met under four broad headings:

• Development – where major components of software are developed
• Integration – where a number of mainly existing components are integrated
• Package customisation – where essentially an existing solution is customised, configured or extended
• Package off-the-shelf (OTS).
  

Development may be when enterprise builds a solution in-house e.g. developing in Java or C#. (the solution will fit like a glove because it is bespoke). This is usually done when no OTS packages meet the requirements or the business seeks to achieve unique market differentiation based on the solution (which often revolves around the use of some bespoke software). This may or may not involve an adjustment to how the business operates.

Package customisation is where a package or service (such as SAP) is purchased and it is customised, configured or extended (as little as necessary). In this case we usually recognise that we will need to make some adjustments to how the business operates, as presumably the package reflects industry best practice.

Package OTS is where a product or service is used as purchased with no changes made – for example MS Word. This is usually done where an enterprise does not seek to achieve competitive advantage through the use of the tool. Few businesses seek to differentiate themselves based on how well they use a word processor.

Integration may involve all of the above and how different components (including external services) from each area work in concert.

It should be clear that the ideal approach to requirements in each of these four s area differs. The failure in most requirements management approaches is that the lower level methods pollute the higher level approach. By way of analogy - the way the plumber or electrician or bricklayers needs to define what they do, and how they notate their detailed designs, is foisted upon people who simply want to describe what need in their new garage).

The approach to requirements management also needs to be aligned with the approach to project management. This introduces another issue: project management in IT.

The failure of requirements management is matched with the failures to recognise the difference between project management in IT and project management for buildings. The reality is that in IT the requirements and specifications often evolve right to the end. This is because what people want to do with the technology elements is partially determined by what the technologies can do: the technologies change behaviour. To pick to generic consumer oriented examples: a GPS navigation phone changes how one navigates, a video conferencing phone changes how one communcates (as do a texting/SMS phone, instant messaging, etc.), and Google and others have changed how we find things. By contrast, with buildings this is far less often the case: we pretty well know exactly how we want to use, say, a toilet, a door, a bed, a bedroom or a lift.

In IT delivery a great deal of the time is spent on understanding precisely what the requirements are, and therefore what the design is (including engineering calculations), what construction is required, and how things should be tested. In buildings the requirements are far more precisely understood at the start, the design is well articulated and precise before construction starts, the testing is usually more obvious (or it is covered fairly well by defined industry conventions), and so on. In buildings the scope is very well defined and the focus of the project is far more on costs, time and variance - whereas in IT the scope is seldom well defined at the start, and the focus of project management is on managing the refinement of scope (while seeing how cost and time can be contained).

For organisations in which this is not a main focus, asking how they want to manage requirements is probably unrealistic. It is a bit like a building architect asking a home owner how the plans should be drawn up, or an electrician asking the home owner how the electrical diagrams should be drawn.

So what is needed is to show some leadership . Clients need an explanation of how requirements can be managed – and how this is related to detailed SDLCs, approaches to project management, and enterprise architecture. The enterprise architecture is a logical starting point for understanding the needs as it should describes:

• how the business operates or seeks to operate, which is turn grounded in the business drivers and constraints, (which include technological, organisational and environmental considerations)
• the existing asset inventory e.g. systems, skills, services (it is also a logical bridge to operations and costs)
  
• known issues and constraints e.g. issues, risks
  
• key design standards and preferred practices e.g. standards, patterns, template

Sadly few organisations have a mature EA processes, and it is if anything less mature than the processes which it should be key to co-ordinating e.g. those associated with requirements, business cases, development, operations.