Capability maps for Business Alignment

Don't Just Build Business-IT Alignment, Map It: http://www.businessweek.com/idg/2010-07-26/don-t-just-build-business-it-alignment-map-it.html. This is a really useful item. My precise below.

CIOs need to be able describe IT functions in business terms. Alignment occurs when people have a common understanding of what's important to the business, how this relates to the business model and the supporting technology, and where to prioritize investments for measurable improvements.

Business capability maps provide a framework to capture, assess, and communicate these needs. These maps put technology strategies in the context of the business process, functions, and capabilities they affect, and help enterprise architects design application and information architecture.

There are no industry standard models or frameworks to guide architects in their development. Forrester developed a six-step process that provides the foundation to successfully build and apply capability maps.

Step 1: Identify the Business-IT Alignment Issues - interview stakeholders to get differnt perspectives. Start with IT and use the results of those interviews to refine the process before moving to the business. Analyze the interview data to find common problem areas. Validate the identified problems with stakeholders to ensure that the accurately reflect their concerns.

Step 2: Define Your Approach - Create a current-state view that includes the issues and a future-state view. Use the current and future-state views to map alignment Issues to solution options. Focus on tractable issues. Define the roles and resources needed to make the initiative successful.

Step 3: Develop the Business Case - Develop a resources project plan (showing ramp up). Identify risks and mitigation approaches. Determine tools and technologies. Develop a cost estimate. Sell the business case.

Step 4: Build the Capability Map - Determine your organising principle e.g. value streams, business functions, services to clients and define the capability framework. Validate the structure by focusing a single element and identify capabilities for that element and add details (narrative description, people, process, technology, information, business goals, metrics, and gaps). Repeat across all of the organizing elements.

Step 5: Apply the Capability Map to Identified Problems - Create a capability map view to that focus on the decisions to be made. For exmaple for investment decisions analyse performance of core capabilities that provide significant market differentiation and competitive advantage to see where investment need to be made.

Step 6: Assess Progress and Refine the Approach - Examine the work to date. Re-examine interim deliverables. Identify unforeseen issues that affected progress, and plan forward and adjust the framework based on knowledge gained.

ESTO success sealed with a KISSS?

Once again I feel compelled to suggest that we learn about how to implement Enterprise Strategic Transformation and Optimisations (Enterprise Strategy and Architecture, Strategic IT planning etc.) from another domain focused on the enterprise use of knowledge and collaboration based on that knowledge i.e. CRM.

See: CRM Success Sealed with a KISSS - http://www.computerworld.com/s/article/print/9177484/CRM_Success_Sealed_with_a_KISSS?taxonomyName=Applications&taxonomyId=18

Most people with experience in trying to change patterns of behavior know that incremental change is easier for people to accommodate. Most people with experience in trying to implement systems know that big-bang approaches are high risk. Implementing new systems for knowledge management and collaboration involves both i.e. changing behaviour and implementing systems.

ESTO solution projects also "need to be much more flexible and adaptive than general IT applications. All too often, the users don't really know what they need, and the smart ones will admit it. Even if they did know, the business rules and your company's competitive environment will change before an 18-month "big bang" project ever gets deployed. ESTO projects are not only less expensive when delivered incrementally, they are a better fit with the business needs. So it's important to get your project staff -- and the ESTO system's executive champions -- comfortable with Agile.

Personally I have issues with methods that are focused on, or derive from, SW development being applied at different levels. And I think that SW developers per se are too keen to see each problem as one that requires development i.e. to get 100% fit might require development; but using an OOTB solution that reflects best practice might get you 80% of the way there - in 10% of the time.

I think the comments on vendor roadmaps interesting - and what we really need in ESTO is an aspirational roadmap with features defined near release drops.

See other ideas from comparisions with CRM:
- http://enterprisesto.blogspot.com/2009/08/what-price-sitp-data-quality.html
- http://enterprisesto.blogspot.com/2009/07/8-dirty-little-secrets-of-enterprise.html

Virtuous circles of strategy, architecture and delivery

If we don't support a virtuous circle of use - we won't achieve much (and certainly not cost effectively).

The majority of people who need to consume an Enterprise Architecture and Strategies are business teams (owners, analysts etc.) and solution architects, designers etc. i.e. down-stream project teams wanting to do something (buy, build, change etc.). NOT other EAs and Strategists. You can see the same thing with a town plan i.e. the majority of people who consume the town plan are property owners, architects etc. wishing to do things.

Governance functions also have a need (e.g. project office, contract/vendor management, business case analysts).

Until EA can effectively understand its place in the lifecycle of think, plan, excute, operate - it will struggle.

Enterprises wish to make changes (transform, optimize) and EA is intended to guide these changes (it is not an end in itself). The changes will usually be implemented in initiatives, programmes, and projects. Those involving IT will usually have requirements, solution architectures, etc. These projects are where the rubber hits the road.

So EA needs to be consumed by down-stream projects - which will indicate their use of existing assets (applications, services, interfaces, hardware etc.), standards (products, technologies, patterns), capabilities (skills, resources) - and indicate where they will produce new assets or require new/different standards to be adopted or capabilities established etc.

Most of what one sees in a tradional EA once came from some project that drove the need for it. This is true on the business and technology side - but is usually more obvious with technology.

An EA needs to be produced and consumed both bottom up and top down.

EVP - Powerpoint fails to deal with complexity well - who would have thought

I have heartened to see this "U.S. Army discovers PowerPoint makes you stupid" (http://blogs.computerworld.com/16006/powerpoint_makes_you_stupid?source=CTWNLE_nlt_entsoft_2010-05-03).

For many years I have been presented with powerpoints that claim to communicate complex things e.g. strategies, roadmaps, architectures, transition plans etc.

I have been perplexed when on examination the PPTs turned out not to contain the information necessary to describe the complex situation being dealt with. I am then asked how do we model these - or why can't you produce a model, visualisation or report that communicates like these do. The reason is that the powerpoints are often specious - being favoured by executives, sales people and other trying the illusion that analysis has been done and sound conclusion reached based on facts - when in the facts, analysis and conclusions are at best usually disconnected. If one points out the limitation of the powerpoint source documents - one hear "Oh so you don't know how to represent this". Well the answer is that if the data is rubbish expressing in a semantically precise way will just highlight that it is rubbish. This doesn't to fly well with the executives.

I like these quotes:

"Have you fallen in love with your bulletized slides, nifty transitions, and pretty charts in PowerPoint? If so, you're likely getting more stupid ..."
"... We Have Met the Enemy and He Is PowerPoint... When we understand that slide, we'll have won the war."
"It's dangerous because it can create the illusion of understanding and the illusion of control. Some problems in the world are not bullet-izable."
"... it leads to bad decision-making, with serious consequences ..."
"... that tremendous amounts of time are spent in the military on putting together presentations, and that this takes away from true productivity."
"... [PPT] does come in handy when the goal is not imparting information, as in briefings for reporters." [or executives]
"hypnotizing chickens."

Artifacts vs Business Results

I am often involved in looking at how people can improve their IT processes e.g. in areas of strategy, architect, governance and service delivery.

Firstly let me say I am fairly familiar with principles underlying OO analysis and design techniques having started using them in the mid 1990s (before UML, and before Java). Naturally when UML emerged as a defacto standard we moved to it; and to RUP which followed soon after. Having overseen many large projects using OO analysis and design techniques I think I have some understanding of what needs to achieved.

Now an apparent digression - Almost 30 years ago when I specialised in CAD and Mapping systems I used to have to explain to Architects, some of whom had been my tutors, the benefits of CAD. They pulled out beautiful water colours and asked if the CAD system could produce them. They had mastered the skills of producing these works of art over lifetime and were justifiably proud of them. At the time the answer was "no". Of course the CAD system could convey the essential information but the way in which conveyed it was different. And of course the cost to produce any ad-hoc view (plans, elevations, details etc.) or deal with changes using the CAD system was far lower. Also the CAD system could be interactively inspected, do counts etc. What these artisans failed to grasp was that what the client wanted as business not a water colour i.e. the business result was the building, the water colour artifacts were incidental.

I now encounter the same issue with people looking at various artifacts related to manual methods of solution design - the classic being the large SAD (seldom if ever read by anyone but the author) or in strategic area some large attractive diagrams manually created with many pretty colours. People seem to think the artifacts (e.g. SAD, Roadmaps etc.) are important per se. In my view they fail to focus on the business results to be achieved e.g. a transformation to be made, or a project delivered and really examine what information is required by whom, when, where and why.

I had a lot of sympathy for those being asked to move from water colours. While they required an experienced practioner and some time produce a result was aesthetically pleasing and communicated very well to many audiences i.e. technical and non-technical (if limited to a specific point of view e.g. plan, perspective, detail, elevation etc.) I have a lot less sympathy with IT people today wasting energy trying to replicate some arcane symbols (e.g. associated with modelling logic, processes, objects or data). These also require experienced practioner and some time produce. The result are neither pleasing nor particularly communicative to average person.

Business architecture as part of Enterprise Architecture

I saw this and thought some of the quotes interesting
http://jccavalcanti.wordpress.com/2010/02/10/defining-business-architecture/

"...BA is an intrinsic component of EA, but what most people really perform in most organizations that I see is IT architecture."

"... enterprise business architecture is a set of artifacts and methods that helps business leaders make decisions about direction and communicate the changes that are required in order to achieve that vision."

"... It's our excuse sometimes that it's too complex to change quickly."

"... We really need to focus the conversation on capabilities..."

"... BA is a means by which we can engage as IT professionals with the business leadership, the business decision-makers ...

"... By having that meaningful dialogue on an ongoing basis, not just as a result of the big implementation ..."

"... understanding your audience is a big part of doing this.

"... That's why there's no, "This is the artifact to create." ..."

"... there's a missing linkage between that vision, that strategy, that direction, and the actual activities that are going on ...

"... jump from high-level strategy down to tactical daily decision-making and activities is too broad of a gap. .."

To me this supports my view that:

1. The BA is intrinsic to EA (though EA function focus on technology).
2. EA needs to support decision making and communicate what needs to be done to achieve a vision (goals, strategies, plans and down to requirements)
3. The excuse made that it is too complex to change quickly indicates a failure of EA.
4. BA needs to focus on capabilities and allow us to engage with the business leaderships (so we need to use the right language)
5. Waiting till a big project to justify the dialogue is like waiting until you are attacked to learn how to defend yourself i.e. it is just dumb
6. Understanding the audience is critical and what and how you communicate varies based on the audience.
7. There is a missing linkage between that vision and plans that live in PPT decks on the shelves and what happends on a day to day basis.

Communicating with people in languages they understand

For many years I have run foul of SW developers how have migrated into Architectural roles - but want to continue to use the techniques and languages suited to the role of OO SW development.

Open Group advocates are often some of worst as many are committed to UML - a language manifestly unsuited to communicating with most business people most of the time.

I recently read this: http://blogs.zdnet.com/Gardner/?p=3450. And saw these comments:

"To achieve business-IT alignment, architects need some way of understanding what the business is really about. ...

We need to talk to business people to understand what the business architecture is, but the business people don’t want to talk tech-speak. ...

We need to be able to talk to them in their language, but addressing an architectural end. "

And I wonder when the penny will drop that this language isn't UML.