Thursday, October 22, 2009

CFO and CIO alignment

I think this item insightful - http://www.expresscomputeronline.com/20091019/management03.shtml

Alliances between the CFO and CIO will deliver better business performance i.e. aligning the economic and the enterprise architecture of the business.

CIOs have been told for years that they must demonstrate the business value of IT, but the problem is much deeper because of misaligned mindsets between the CIO and CFO.

Most CFOs are focused on business performance and outcome.

Too many CIOs (and most enterprise architects and strategy) are overly focused on being super technologist, mandating standards and designs, and being overly influencing by vendor with large budgets for executive entertainment. This over focus on technology, and too little focus on enterprise (or business).

A proper solution that ensures the key economic parameters are expressed as an intrinsic part of the enterprise architecture are key to this. These cost parameters help lead the technologists towards more of a focus on business issues and provide a neutral point of articulation between the financial and technical domains.

Thursday, September 3, 2009

Reliving my past

Over 25 years ago I suggested to a range of business users, designers, engineers, surveyors, and planners - that paper based maps, plans and designs or specialised dedicated models suited to a single audience or purpose - were not a good way to bring all the information to together (and allow it to be integrated, maintained, analysed, accessed by a wide range of different parties etc.). In those days I focused on technical computing (mapping, CAD etc.).

In those days I was talking to people who had spent a lifetime learning how to create truely beautiful watercolours that the scrapping little draws that came from that generation of CAD were the way forward.

The challenge was to get different set of people (professions) each of whom sees things from the own perspective yo see the overall picture and what is required to suit the needs to the entire constituency i.e. that if all information was made available using the same framework e.g. co-ordinate system - we could all see what was there, why it was there, what it related to etc. Design work could be migrated to as-built in a fairly painless, predictable and straightforward manner.

Conceptually now - that battle at least is essentially won (though aberrations remain).

Now I am having exactly the same discussion with people seeking to implement complex IT infrastructures (e.g. NSDI) i.e. business users, designers, engineers and planners. In case it is the meta information that is on paper i.e. the maps, plans and designs that sit and describe the: functions, the data, the roles, assets, networks of related elements etc.

Now we have a different set of people each of whom sees things from the own isolated perspective and fail to see the overall picture and what is required to suit the needs to the entire constituency.

Tuesday, September 1, 2009

NASA Deputy CIO says EA really help control of IT-related costs

NASA deputy CIO mentioned that implementing EA had really helped his agency develop a mature IT organization and control IT-related costs.

Is mention in open paragraph of this


http://www.computerworld.com/s/article/print/9137306/Building_your_enterprise_architecture_program_the_right_way?taxonomyName=Enterprise+Applications&taxonomyId=87

I had to laugh at what followed.

It started with

"I had to agree, " [once senses the author is reluctant to agree to so a prosaic goal as cost reduction]

It continued with

"...but the topic of EA is far more complex ... far more difficult to properly implement than most IT professionals realize" [whereas in fact it properly implement EA initiatives can be implemented quite simply and progressively delivery value]

It then proudly proclaimed

"...there are four main areas of EA, covering business processes, data, applications and technology. ..." [seemly forget about the bulk of the actual enterprise e.g. it goals and constraints, its products and organisation etc.]

Yes these things are important:
- capabilities, functions and processes
- business decisions/questions, information and data
- applications and services
- technologies

But the facts are that costs are directly associated with products and services (i.e. applications, services, technologies, standards and projects that change them and the organistions that support them) and only indirectly related to BP and data.

That income is related to the companies: products/services.

So if you don't understand the where the goes and where the money comes from all the knowledge of what lies in the middle is hard to apply.

Contemporary solutions IT strategic in many cases provide out of the box solutions for many of these EA issues that deliver value quickly.

Sooner or latter these EA people who saying everything is so hard and so complex (and reference obscure abstractions and methods) are going to need to realise that these thing have not worked.

Tuesday, August 4, 2009

How relevant is Six Sigma to IT

Six Sigma seeks to improve the quality of process outputs by identifying and removing the causes of defects. IT is an industry that is doing well if it gets One Sigma - isn't a methodology named and oriented at Six Sigma a little ambitious.

The very mystical terms "Six Sigma", "Black Belt" have the air of those other consulting buzz-words du-jour - TQM, BRP, Y2K. How many time are people going to be fooled by these things?

I suspect that "Black Belt" is an accidentally appropriate terms. It martial arts it really means someone who has learned the fundamentals. And for most of these "arts" real world martial (fighting in war, or in real life) efficacy is not their real orientation - they are arts, sports, exercises, etc. If one wanted to achieve martial there far faster and easier ways.

My issues is not with desire to improve outcomes by thinking how things are done and working out how they could done better. I am also sure that there are many techniques. It is with vodoo fashion branding the consulting industry applies - I object to. when most of it simply comes down to thinking carefully.



Friday, March 6, 2009

Too fat to diet, too unfit to exercise

I recently saw an email from someone at small-ish bank. Saying our BPA project has gone significantly over budget. So now isn't a good time to ask the business for money to get an SITP planning solution.

The logic of not allocating funds to Strategic IT Planning - i.e. solutions that specifically focuses on ensuring IT costs are reduced, and the scope and cost of initiatives are well understood before work undertaken, and understanding the impact of changes as they occur - when someone has just had experienced a project that has demonstrated the need for SITP systems doesn't make a great deal of sense to me.

I also frequently encounter comments to the effect that the way our strategy & architecture function works (usually as internally oriented function producting documents for their own gratification) isn't really that effective. So we are not going to explore an SITP solution that would enable this function to operate effectively? Rather we are going disband the unit and distribute the function into business units (that operate on tactical and point solutions). So we know we need to think strategically - but at present we can't do it - so for a year to two we will pretend it isn't necessary.

I see this kind of anti-logic all the time. In many aspects of life.

I am reminded of the people to whom I recommend yoga. But I am told told "I am too stiff and stressed" to do yoga, presumably they are also too fat to diet, too unfit to exercise, too uninformed to educate themselves.

If they said we like wasting money, we get off on it, it means we can buy lots of cool technologies to play with. At least one could have respect for them at one level (honesty). Or if they said we really don't understand what strategy & architecture is about or how to get value from it we are really over grown SW developers or systems engineers and our heart is in coding and playing with operating systems. One could have respect for them. Or if they said - I am looking forward to a future or obesity induced health problems, stiffness and stress related disorders - this is a just penance for past behaviour. You could see at least that they are considering the impact of their unwillingness to change their habits. It seems to me that that these people don't even seem self aware enough to do this?

I am tempted to conclude that one thing all these people have in common is that they don't have the energy, will or initiative to change. But unfortunately some of them are among closest friends - so I really don't know what to make of it.

Monday, March 2, 2009

Business analysis and visioning

I believe a simple structured way to analysis is required. I think most analysis can be organised around simple set of canonical model (Goals, Facts, Beliefs, Recommendations).

To be useful the relationships between concepts need to be weighted. But the 1st step is to understand the relationships between Goals and Recommendations (via Facts and Beliefs).

When one reads most analysis documents and tries to assemble a model like this - but usually finds large gaps and inconsistencies (which is really just feeble) e.g. the recommendations can be substainiated or the basis of them is not explicit.

This analysis may strategic or tactical, focus on a current problem or future state (visioning), it may be technical or non-technical.

Forcing the thinking into this simple model helps people understand the basis of beliefs and recommendations.

Goals: are things you are trying to achieve. Sometimes technical people also refer to these as principles e.g. non-functional requirements e.g. reliable - but in fact they are goals.

Issues: are problems you are trying to address (they are actually goals stated in a different way)

Facts: are facts i.e. they are not disputable.

Beliefs: should be based on Facts and relate to Goals/Issues (if they don't relate to Goals/Issues they are not that useful)

Recommendations: are actions based on Beliefs to achieve Goals/address Issues.

Concepts: are a grouper for things terms, patterns, principles, ideas we may refer to when we discuss Goals, Facts, Beliefs and Recommendations.

Classification systems: are ways of organising our thinking and are often based on Reference models (which reflect best practice). Classifications systems may relate to what we (e.g. be business oriented) or the materials we use (e.g. be technology oriented).

No doubt more sophisticated ways of doing analysis can be applied e.g. that considered but I think we start with a very simple approach is a good place to start:
eg.
- Visions, Strategies, Objectives, Measures, KPIs - can all be recorded as Goals
- Laws, Regulations, Market factors etc. - can all be recorded as Facts
- Causes, Findings, Implication - can all be recorded as Beliefs
- Trends - are either Facts or Beliefs
- Risks and Issues - are the failure to achieve goals now or in the future.

Sunday, March 1, 2009

Architecture vs Design

The failure to be clear about what we mean by Architecture is associated with a failure to be clear about the design process.

One of the purposes of the strategy & architecture (S&A) is to assist us in supporting the design of business solutions i.e. specific solutions owned by the business that deliver value. The role played by the S&A is one of guiding and constraining the solution, the design process (i.e. the synthetic and creative process) and supporting the evaluation of alternatives (i.e. helping measure how optimal each solution is). In addition it should ideally be used as part of a formal authorisation process.

The design process

Design involves creating an optimised solution based on a set of constraints. When designing technology solutions (including selecting technology products and services) the constraints can be considered to be three major categories i.e. the problem domain, solution domain and strategic domain.

Problem Domain
The problem domain is usually defined by a business case related to the specific business project or owner. This set of constraints may be called the requirements. The business case will usually require a business owner focuses on achieving specific business outcomes. The typically technology solutions will be just one aspect the business owner is considering.

The business owner will usually make clear the desired: business outcome e.g. value creation (or improved outcome by some other measure), time to market etc.; business services or offerings to be provided, supported or enhanced i.e. both their nature and quality; business objects and processes to be supported, enhanced (e.g. automated, streamlined etc.), developed or maintained; business control and governance considerations to be met (e.g. security, regulatory, corporate); business community to serviced; business costs and how return will be achieved i.e. what investment can be made and how the investment can be justified

Solution domain
This relates to what can be created. Our knowledge of the solution domain is based largely on historical knowledge (what we have done, what we know works etc.), our circumstances and the environment (what is available to us) and includes: what we know about how solutions are constructed e.g. best practices, heuristics, patterns; the specific skills, techniques and technical knowledge we have about systems and their operation; the technical assets we have i.e. tools, technology infrastructures (systems, software, hardware), legacies (bespoke and purchased product) and services.

Strategic domain
We can consider a there to be third set of constraints that represents the broader business requirements (i.e. the requirements that represent the sum of all the current future business goals, strategies, projects, initiatives etc.) i.e. beyond the scope of the current project, and beyond the ambit of the immediate business owner. This is what the technology strategy and architecture represents. They can be considered to be in the problem domain (as they are a set of meta-requirements) and the solution domain (to be useful the meta-requirements are usually synthesised so they can be expressed as solution domain constrains). They include: themes and visions; structures and topologies (i.e. high level layout and design); common infrastructures, principles, standards, metrics; transition strategies (i.e. interdependencies roadmaps, constraints etc.).

Often an S&A is reflected in a set of principles that can be combined with other constraints to allow design. Usually some principles are more important to the stakeholder that others (weighting principles in an objective way is very complex and not dealt with in this discussion). In practice decisions are not always made simultaneously (i.e. some decisions precede others) and trhe order in which
decisions are made influence the design.

Getting back to the design process
The process of design can be considered to involve a number of activities (that are undertaken at many levels i.e. recursively, fractaly, iteratively or in parallel). At the highest level we can think of: determining the set of constraints (e.g. requirements gathering), creating a solution by synthesising all of the constraints and imaging possible solutions (design or selection) and evaluation. These steps as different in nature (but intimately connected) i.e.
- first – determine the constraints: is essentially objective (from the designers perspective) i.e. if the business person specifies a requirement it is taken as an objective fact by the designer. It may be a subjective assessment by the business owner providing the requirements i.e. it may, or may not have been objectively determined.
- middle – design synthesis: is non-procedural, inductive, one of synthesis, creative and requires imagination, demands a holistic focus, is intuitive and relies on experience etc. the result from this step is one or more design alternatives or scenarios.
- finally – evaluate design alternatives: involves measurement, assessment, is analytical and should be objective. At major design elaboration or decisions points it makes sense to have a structured and formalised approach. (e.g. our Solution Evaluation Model or SEM). This helps ensure objectivity, transparency and traceability i.e. it helps everyone understand why a design is preferred. This understanding in turn helps educate all parties regarding the implications of specific types of constraints or requirements.

Evaluating the alternatives
A designer may review the constraints and determine a solution they prefer (for what ever reason). Once one is attached to a design there is a tendency to want to move on quickly. While this will often be the correct, and only pragmatic, thing to do (as we rely on intuition, common sense etc.) when major decisions are involved good designers will confirm for themselves that the other alternatives are inferior of the design (or that other constraints that justify their preference need to be articulated).

Alternatively a business person may look at a solution (e.g. a product) and determine it best suits their needs (for what ever reason) i.e. is the optimal solution. Once one is attached to a solution there is also a tendency to want to move on quickly. Again this will often be the correct and pragmatic course of action. But when major decisions are involved most good business people will usually seek confirmation that other alternatives are in fact inferior.
Further items will discuss some of these things in more detail: problem domain, solution domain, principls, patterns (Patterns are generic models that allow one or more design point to be achieved), heuristics and best practices, solution evaluation models.

Considering the longer term
As we are dealing with systems that are undergoing constant change we need to understand why things exist and what problems would exist if we changed what exists. This implies we need an understanding of rationales. It is only by developing this understanding that we can learn, continue to improve the rate that we change and produce better results.

On effective development of strategies

To make strategies effective for all the stakeholders the strategy needs to be able to: evolve dynamically, ensure participations, have clear transparent underlying framework (way of organizing information and making decisions), reflect best practice (learning across the spectrum of sport), allow consensus and divergence of views to be understood, and relate directly to actionable tactics and initiatives.

We can see the failure of strategy when something like the recent economic “melt down” occurs i.e. rather than us being to quickly analysis what the impact of these different externalities logically is on what we need to do – and therefore which programmes and initiatives (i.e. spending) should be adapted and how – business are forced to blind cutting or some extended re-analysis. This is because the knowledge about the exact impact and import of the assumptions the strategies are based and lost in the mists of time.

Working strategies needs to:

Produce Sustained value – This means that we need ensure that information that is captured can related and reused. That it can be refined and changed (the impact of the change or refinement is understood).

Be dynamic and current - The framework (how we do things) needs to be able to evolve dynamically i.e. so that changes we make to how we do things are immediately available. In practice this will mean a systems based solution – as it clear that with even a very small number of documents you can’t effectively (considering time and cost) propagate changes to templates and inter-relationships between the documents.

Ensure participation and engagement - The mechanism for sharing our understanding (i.e. of cause and effect) needs to be accessible – because we need to encourage as broad an engagement / participation as possible. In practice this will mean Web based delivery is important as it removes an inhibitor to engagement. It is at best imprudent to rely on people being able attend face to face meetings.

Be clear, explicit and transparent – We must explicitly define the semantics e.g. we may have goals, facts (including law and regulations, market and environment factors, demographics, etc.), germane beliefs (which should be based on facts and relate to goals i.e. in order to be germane), recommendations (which are based on goals and beliefs). We would also usually want concepts (common terms and concepts), risks (which we may choose to distinguish from risk and issues), extant assets and capabilities identified discretely. If we don’t do this when we disagree on recommendation we can’t even work out what it is we are disagreeing about e.g. the goals, the facts, the beliefs. A weakness with prose based approach both oral and documentary is that frequently the persuasive power lies in eloquence, erudition, wit or charm. These are not really sound ways to make policy. An explicit approach to semantics helps depersonalise things (often disputes arise because of issues of personality and all efforts should be made to avoid this).

The ability to analyse the basis of recommendations (based on agreed beliefs and relate to defined goals) is quite important. To allow effective analysis we need to be to understand the semantics and allowing for weighting i.e. we need to recognize that not all goals are of equal importance and recommendations don’t equally support goals, or follow from beliefs.

Reflect best practice and common - Reference models assist us in organising our thinking. They may be simple classification systems, but ideally they relate high level concepts that allow us to do inferential checks on completeness e.g. to take a trivial example if we have a reference model of services (e.g. “delivery”) and systems (e.g. “delivery tracking system”) and know in this model that “deliveries” must “be tracked” in a “delivery tracking system”. Then when we have a specific thing of service instantiated that is defined as “delivery” - we can infer that their should be a “delivery tracking system” and if nothing of this is instantiated we can infer we have an issue.

Communicate effectively with many stakeholders – we need to show people ONLY what they are interested in seeing. This is why most people won’t read long reports (unless the report is written for them). So what we really need to be able to do is produce a report for audience, from point of view. Traditional documentary approaches to this either result in a plethora of documents oriented at different audiences, on different topics and different levels of detail. Or we end up with a large tome that no wants to read (and very few will).

When we look the above we can see that documents will fail us in this exercise (as will document based Web portals) i.e.
- Sustained value – we can get information related and reused
- Dynamic and current - we can't support a dynamic framework that evolves as we learn and change
- Ensure participation and engagement - we can't ensure engagement. In fact documents will ensure most people don't engage and we can’t build consensus.
- Clear and transparent - we can't be get people to agree what the real issues are (i.e. agreements and disagreements explicit and precise)
- Reflect best practice and common - we can implement a common set of reference models i.e. it is to hard with documents (too much paper).
- We can analyse things - documents need to be read in toto.

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

Monday, February 23, 2009

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.

Tuesday, January 27, 2009

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."

Monday, January 26, 2009

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.

Monday, January 12, 2009

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.