IT Strategy – Page 4

The hype cycle vs legacy…

May 27, 2011 by Alan Inglis

I am going to talk about a consequence of the hype cycle that seems to be missed by many. I will use an anecdote to illustrate the point…

About 10 years ago, I was engaged on a short assignment to review a new technology organization’s customer service programs. The company had grown rapidly in a new market that was now maturing. They had 3 customer service systems. They had 4 main customer groups served through 4 sales channels. Each channel used different business processes to execute the same activities and accessed all three systems. The IT solutions had grown organically with the business and were a mess! But now, with the market maturing, there were mainstream solutions from major suppliers that could replace these systems that were starting to constrain the business. However, the cost of resolving this, $15M, was seen as too expensive.

A few years later, the organization had lost its competitive position, had moved from number 1 to number 2 and was taken over by a foreign competitor entering the market. With a more complex product portfolio, more customer groups, a more complex sales model, the customer services systems were now seen as a major constraint to business growth. I happened to be engaged through another consultancy to look at the problem again. This time the cost of sorting it out had grown to $80M. Again the executive board decided that this was too expensive.

Recently, the organization merged with a major competitor. I heard that they had embarked yet again on a program to replace their legacy customer service systems. The market is now much more complex with many more products, it is also more competitive with tighter margins. The systems have grown in complexity since the last attempt to sort them out. I suspect the cost this time will be $150M or more. A ten times increase in cost in ten years. More importantly, the organization was the market leader 10 years ago but now it is in 3rd position with a likely drop to 4th.

The key point is that everything that you build before good practice emerges is likely to be poorly designed and poorly built. It should be thrown away and you should start over. If you don’t you will inevitably perpetuate bad practice. Future development will be compromised because time pressures to deliver tactical business change and the constraint of the legacy. And the cost of replacing it to deliver strategic business change will grow over time.

Sometimes I wonder why there is so much legacy. The answer is obvious if you overlay the adoption cycle with hype cycle…

So what are the lessons:

It is never too late to sort out your legacy
Don’t build on bad practice
The so called first mover advantage can be a handicap
Build knowledge before building solutions

2011 CIO Agenda – A. M. Best’s BestDay Podcast

January 20, 2011 by Chris Curran

Print PDF 2011 CIO Agenda Podcast Transcript Listen to the podcast or read the summary below. The interview was conducted by Best Review Editor Lynna Goch. LYNNA: Chris is here today to talk about the results of a survey conducted with 724 senior business and IT executives from large companies that he wrote about in his article Cloudy Future (requires free subscription) that appears in January’s issue of Best’s Review. So Chris, in your article […]

If you liked this, you might also like:

What is Your Internet of Things?

November 18, 2010 by Chris Curran

I’ve seen the number 4.6 billion pop up a few times lately. Any ideas? It’s the approximate number of mobile phones globally which is about 69% of the worlds population. It’s the explosion of phones, particularly smart phones that are internet addressable, that is pushing the limits of the internet itself. It’s also these devices that are generating massive amounts of data. For more mind blowing statistics on the explosion of data all around us, […]

If you liked this, you might also like:

IT Strategy Paradigms: Ways to understand and develop IT strategies in a Coherency Management Context.

August 25, 2010 by Peter Sjølin

What is an IT strategy I have been able to identify two major approaches to articulate IT strategies. The first major approach is the typical MIT Sloan School of Management approach that support the issues of a some how detached IT strategy from the corporate strategy. The strategy is build upon the assumption that IT […]

Can IT Make a Competitive Difference: From a Coherency Architect’s Point of View.

August 9, 2010 by Peter Sjølin

The Introduction Erik Brynjolfsson and Andrew McAfee has written the paper “Investing in the IT That Makes a Competitive Difference” that was published in 2007 in by Harvard Business Review. The paper deals with how enterprises deals with competition in the United States. McAfee & Brynjolfsson argues that most enterprises are in state of hard […]

Should the IT Strategist role disappear with Enterprise Architecture?

July 15, 2009 by Serge Thorn

Many companies in their IT department have two units: IT Strategy & Planning and Enterprise Architecture. As regularly these are two different people managing these units, there is a high risk this ends up in serious conflicts.

The IT Strategist needs to understand the organization’s overall business strategy and is supposed to develop a comprehensive IT Strategic Plan that aligns with the business strategy (linkage, support of goals and objectives, etc.). He will continually assess all areas in the IT department to make sure their efforts and initiatives support this IT strategic plan, highlight gaps and identify alternatives to close gaps. During the development of the IT Strategic Plan (creation and maintenance of a detailed project plan (schedule, WBS, etc.) for the development and execution) , he interacts with various IT and Business Governance committees, and supports the execution and the evaluation of that plan.

How much is this different from one of the role of any Chief Enterprise Architect?

Among various roles the Chief Enterprise Architect ensures that the organization’s strategy is understood and acted on. Ideally, he should contribute to the strategy itself. He also has to understand, advocate and support the organization’s business and IT strategies.

Enterprise Architecture should be used to develop an IT Strategy. The EA team is in charge of implementing an EA program, which involves articulating the desired future state, understanding the current state, identifying the gaps between the two states and developing approaches to close these gaps. The team is leading the creation or evolution of the EA function or program, including the coordination of an appropriately balanced pursuit of enterprise business, information, application, technology and solution architecture viewpoints. Understand new technology future IT directions and how they can Impact the business.

When creating the new architecture (blueprint or high level architecture) which is based on the business goals and directions, they will identify new technology options and key finding from IT assets mapping and technology as-is mapping. The gap analysis will document each element that we mapped in the current state and translate this into roadmaps with dependencies and assignments: group gaps into projects, write one page of project high level analysis, assign resources to projects and creating a road map.

MODAF Acquisition Views will help to define these projects including dependencies.

FEAF in section 4 EA Transition Strategy / TOGAF Phases E (Opportunities and Solutions) and F (Migration Planning) describe similar activities.

Enterprise Architecture is a bridge to make the connection between business side planning and enterprise IT strategy making. When successful it delivers the IT strategy documentation.

The role of the IT Strategist should be split into two sets of activities (Enterprise Architecture and PMO (project management office) and does not make anymore sense when an organization has these two units.