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.

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.

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.

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.

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.

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.

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.