Monthly Archives: October 2010

How to cope with an IT transformation

Once started, an IT transformation is hard to stop. Such huge efforts – often involving investments of hundreds of millions, or even billions of dollars – take on a life of their own. Once the requirements have been scoped and IT has started the hard work of development, business’s thoughts often turn from anticipation to dread. How do we understand what we’re getting? How do we cope with business change between when we signed off the requirements to the solution entering production? Will the solution actually be able support an operating and constantly evolving business?

Transformations take a lot of time and huge amount of resources, giving them a life of their own within the business. It’s not uncommon for the team responsible for the transformation to absorb a significant proportion of the people and capital from the main business, often into the double-digit percentages. It’s also not uncommon for the the time between kicking off the project and delivery of the first components in to the business to be five years or more.

The world can change a lot in five years. Take Apple for example: sixty percent of the products they sell did not exist three years ago{{1}}. It’s not rare for the business to have a little buyers remorse once the requirements have been sign-off and we sit waiting for the solution to arrive. Did we ask for the right thing? Will the platforms and infrastructure perform as expected? Are our requirements good enough for IT to deliver what we need? Will what we asked for be relevant when it’s delivered?

[[1]]60 percent of Apple’s sales are from products that did not exist three years ago @ asumco.com[[1]]

Apple quarterly sales by product
Apple quarterly sales by product

The business has placed a large bet – often putting the entire company’s life on the line – so it’s understandable to be a little worried, and the investment is usually large enough that the business is committed: there’s no backing out now. However, the decision to undertake the transformation has been made, our bets have been placed, and there’s no point regretting carefully considered decisions made in the past with the best evidence and information we could gather at the time. We should be looking forward, focusing on how we can best leverage this investment once it is delivered.

We can break our concerns into a few distinct groups: completeness, suitability, relevance and adaptability.

First, we tend to worry that our requirements were complete. Did we give IT the information they need to do their job? Or were there holes and oversights in the requirements which will require interpretation by IT, interpretation which may or may-not align with how the business conceived the requirement when we wrote down the bullet points.

Next, we are concerned that we asked for the right thing. I don’t know about you, but I find it hard to imagine a finished solution from tables, bullet points and process diagrams. And I know that if I’m having trouble, then you’re probably imagining a slightly different finished solution than I’m thinking of. And IT probably has a different picture in their heads again. Someone is bound to be disappointed when the final solution is rolled out.

Thirdly, we have relevance. Five years is a long time. Even three years is long, as Apple has shown us. Our requirements were conceived in a very different business environment to the one that the solution will be deployed into. We probably did our best to guess what will change during the delivery journey, we can also be sure that some of our predictions will be wrong. How accurate our predictions are (which is largely a question of how lucky we were) will determine how relevant the solution will be. If our predictions were off the mark, then we might have a lot of work to do after the final release to bring the solution up to scratch.

Finally, we have adaptability. A business is not a fixed target, as it constantly evolves and adapts in response to the business environment it is situated in. Hopefully we specified the right flex-points – areas in the solution which will need to change rapidly in response to changing business need – back at the start of the journey. We don’t want our transformed IT estate to become instant legacy.

A lot of these concerns have already been address with ideas like rapid-productionisation{{2}} and (gasp!) agile methodologies, but they’re solving a different problem. Once you have a transformation underway, advice that you should hire lots of Scrum masters will fall on dead ears. While there’s a lot of good advice in these methodologies, our concern is coping with the transformation we have, not to throw away all effort to-date and try something different.

[[2]]Rapid productionising @ Shermo[[2]]

So what can we do to help IT ensure that the transformed IT estate is the best that it can be?

We could try to test to success, making IT jump through even more hoops by create more and increasing strenuous tests to add to the acceptance criteria, but while faster and more intense might work for George Lucas{{3}}, it doesn’t add a lot of value in this instance. Our concerns are understanding the requirements we have and safeguarding the relevance of our IT estate in a rapidly evolving business environment. We’re less concerned that existing requirements are implemented correctly (we should have already done that work).

[[3]]Fan criticism of George Lucas: Ability as a film director @ Wookieepedia[[3]]

I can see two clear strategies for coping with the IT transformation we have. First, is to create a better shared understanding of what the final solution might look like (shared between business and IT, as well as between business stakeholders). Second is to start understanding how the future IT estate might need to evolve and adapt in the future. Learnings from both of these activities can be feed back into the transformation to help improve the outcomes, as well as providing the business with a platform to communicate the potential scale and impact of the change with the broader user population.

There are a number of light-weight approaches to building and testing new user interfaces and workflows, putting the to-be requirements in the hands of the users in a very real and tactic way which enables them to understand what the world will look like post transformation. This needs to be more than UI wireframes or user storyboards. We need to trial new work practice, process improvements and decisioning logic. The team members at the coalface of the business also need to use these new tools in anger before we really under their impact. Above all, they need time with these solutions, time to form an opinion, as I’ve written about before{{4}}.

[[4]]I’ve already told you 125% of what I know @ PEG[[4]]

Much like the retail industry, with their trial stores, we can create a trial solution to explore how the final solution should move and act. We’re less worried about the plumbing and infrastructure, as we’re focused on the layout and how the trial store is used. This trial solution can be integrated with existing operations and provided to a small user population -– perhaps a branch in a bank, an single operations centre for back-office processing, or a one factory operated by a manufacturer – where we can realise, measure, test and update our understanding of what the to-be solution should look like, bringing our business and technology stakeholders to a single shared understanding of what we’re trying to achieve.

Our trial solution need not be on the production platform, as we’re trying to understand how the final solution should work and be used, not how it should be implemented. Startups are already providing enterprise mash-up platforms{{5}} which let you integrate UI, process and decisioning elements into one coherent user interface, often in weeks rather than months or years. Larger vendors – such as IBM and Oracle – are already integrating these technologies into their platforms. New vendors are also emerging which offer BPM on demand via a SaaS model.

[[5]]Enterprise Mash-Ups defined at Wikipedia[[5]]

Concerns about the scaleability and maintainability of these new technologies can be balanced with the limited scale and lifetime of our trial deployment. A trial operations centre in one city often need not require 24×7 support, perfectly capable of limping along with a nine-to-five phone number of someone from the development team. We can also always fail back to the older solution if the trial solution isn’t up to scratch.

Our second strategy might be to experiment with new ideas and wholly new models of operation, collecting data and insight on how the transformed IT estate might need to evolve once it becomes operational. This is the disruptive sibling of the incremental improvements in the trial solution. (Indeed, some of the insights from these experiments might even be tested in a trial solution, if feasible.)

In the spirit of experimental scenario planning, a bank might look to Mint{{6}} or Kiva{{7}}, while a retailer might look to Zara{{8}}. Or, even more interesting, you might look across industries, with a bank looking to Zara for inspiration, for example. The scenarios we identify might range from tactical plays, through major disruptions. What would happen if you took a different approach to planning{{9}}, as Tesco did{{10}} or if we, like Zara, focused on time to market rather than cost, and inverted how we think about our supply chain in the process{{11}}.

[[6]]Mint[[6]]
[[7]]Kiva[[7]]
[[8]]Zara[[8]]
[[9]]Inside vs. Outside @ PEG[[9]]
[[10]]Tesco is looking outside the building to predict customer needs @ PEG[[10]]
[[11]]Accelerate along the road to happiness @ PEG[[11]]

We can frame what we learn from these experiments in terms of the business drivers and activities they impact, allowing us to understand how the transformed IT estate would need to change in response. The data we obtain can be compiled and weighted to create a heat map which highlights potential change hotspots in the to-be IT estate, valuable information which can be feed back into the transformation effort, while the (measured, evaluated and updated) scenarios can be compiled into a playbook to prepare use when the new IT estate goes live.

Whatever we do, we can can’t sit by passively waiting for our new, transformed IT estate to be handed to us. Five years is a very long time in business, and if we want an IT estate that will support us into the future, then we need to start thinking about it now.

A prediction: many companies will start shedding IT architects in the next six to eighteen months

Business is intensely competitive these days. Under such intense pressure strategy usually breaks down into two things: do more of whatever is creating value, and do less of anything that doesn’t add value. This has put IT architecture in the firing line, as there seems to be a strong trend for architects to focus on technology and transformation, rather than business outcomes. If architects are not seen as taking responsibility for delivering a business outcome, then why does the business need them? I predict that business will start shedding the majority of their architects, just as they did in the eighties. Let’s say in six to eighteen months.

I heard a fascinating distinction the other day at breakfast. It’s the difference between “Architects” and “architects”. (That’s one with a little “a”, and the other with a large one.) It seems that some organisations have two flavours of architect. Those with the big “A” do the big thinking and the long meetings, they worry about the Enterprise, Application and Technology Architectures, and are skilled in the use of whiteboards. And those with the little “a” do the documenting and some implementation work, with Microsoft Visio and Word their tool of choice.

When did we starting trying to define an “Architect” as someone who doesn’t have some responsibility for execution? That’s a new idea for me. I thought that this Architect-architect split was a nice nutshell definition of what seems to be wrong with IT architecture at the moment.

We know that the best architects engage directly with the business and take accountability in providing solutions and outcomes the business cares about. However, splitting accountability between “Architects” and “architects” creates a structure and operation we know is potentially inefficient and disconnected from what’s really important. If the business sees architects (with either a big or little “a”) as not being responsible for delivering an outcome, then why does the business need them?

There’s a lot of hand wringing around the IT architecture community as proponents try to explain the benefits of architecture, and then communicate these benefits to the business. More often than not these efforts fall flat, with abstract arguments about governance, efficiency and business-technology alignment failing to resonate with the business.

“Better communication” might be pragmatic advice, but it ignores the fact that you need to be communicating something the audience cares about. And the business doesn’t care about governance, efficiency of the IT estate or business-technology alignment. You might: they don’t.

In my experience there are only three things that business does care about (and I generally work for the business these days).

  • Create a new product, service or market
  • Change the cost of operations or production
  • Create new interactions between customers and the company

And this seems to be the root of the problem. Neither IT efficiency, nor or governance or business-technology alignment are on that list. Gartner even highlighted this in a recent survey when they queried more than 1,500 business and technology executives to find out their priorities going forward.

Top 10 Business and Technology Priorities in 2010
Top 10 Business and Technology Priorities in 2010

Business need their applications — and are willing to admit this — but do they need better technical infrastructure or SOA (whatever that is)? How does that relate to workforce effectiveness? Will it help sell more product? Eventually the business will reach a point where doing nothing with IT seems like the most pragmatic option.

There’s a few classic examples of companies who get by while completely ignoring the IT estate. They happily continue using decades old applications, tweaking operational costs or worrying about M&A, and making healthy profits all the while. Their IT systems were good enough and fully depreciated, so why bother doing anything?

So what is the cost of doing nothing? Will the business suffer if the EA team just up and left? Or if the business let the entire architecture team go? The business will only invest in an architecture function if having one provides a better outcome than doing nothing. The challenge is that architecture has become largely detached from the businesses they are supposed to support. Architecture have forgotten that they work in logistics company, a bank or a government department, and not for “IT”. The tail is trying to wag the dog.

Defining Architecture (that’s the one with a big “A”) as a group who think the big technological thoughts, and who attend the long and very senior IT vendor meetings just compounds the problem. It sends a strong message to the business that architecture is not interested in the helping the business with the problems that it is facing. Technology and transformation are seen as more important.

It also seems that the business is starting to hear this message, which means that action can’t be far behind. Unless architecture community wakes up and reorganises around to what’s really important — the things that business care about — then we shouldn’t be surprised if business starts shedding these IT architecture functions that the business sees as adding no value. I give it six to eighteen months.