Should you derive your IT Strategy from your Business Strategy? Probably not too much.

“It is a truth universally acknowledged, that every single IT Strategy in possession of great benefits, must be in want of a Business Strategy.”

It is a generally seen as ‘best practice’ (you know: those statements that are often not ‘practice’, let alone ‘best’, but that more often are things that?seem?obvious) to derive your IT Strategy from your Business Strategy. In practice, organisations often derive their IT Future State (and a road map to get there) from their current Business Development goals. IT exists for the business, we don’t do IT for IT, after all, so the idea that IT must follow the business strategy is a no-brainer, right??

Wrong.?

Or to be precise: it is one of those oversold simplifications that can do a lot of harm.

Planning for the future

Many years ago, when I was after my first non-university job, I was invited to talk to the strategic IT department of a large-ish commercial organisation. This department fed the organisation with insights on technology, more precisely: what was going to happen in that rapidly developing area of IT. In the end I went for another job, but the department was typical of the IT-strategy of the age (late 1980’s): trying to predict where technology was going was the?modus operandi ?for many organisations. Pundits and pundit-organisations were closely read and followed. The job itself seemed like a lot of fun, traveling all over the world, going to conferences, studying what was happening.

Such activities are in support of?forecasting, which is one of the mechanisms by which organisations try to get a grip on the future. More even than forecasting, organisations use a second strategic mechanism, which is?backcasting : envisioning a desired ‘future state’ and trying to get there. A third method is scenario planning, which focuses explicitly on the strategic uncertainties, and tries to build strategy that can cope with these. While I think scenario planning is part of a healthy strategic mix (but far less simple than the name suggests), I will largely ignore it in this article. Instead, I will introduce another strategy element that is a logical result of the IT-revolution, and that is not at all intuitive given how we experience IT, and that almost nobody is yet really consciously doing (as far as I know).

Forecasting

As the Arab proverb goes:?he who predicts the future, lies, even when he is telling the truth.

It is of course clear to everyone (except ‘believers’ in one or the other thing, say ‘the singularity’) that predicting the future is a risky business. For instance: I clearly remember serious pundits like IDC in the first half of the 1990’s predicting an exponential growth of the?Videotex standard based on the success of the French?Minitel ?implementation. Within four years, Videotex was forecasted to be huge, and trade magazines duly reported these predictions so organisations could start moving. What actually happened was that the world-wide-web killed it.

Videotex was not the only reasonable but failed prediction of its kind. The death of Apple was a sure prediction for many pundits during the 1990’s and well into the 2000’s. Apple is now (almost?) the most valuable company on the stock markets world wide. Around 1970, experts and pundits alike saw superintelligent computers as a certainty to arrive within 10 years.

In 1989, marketing professor Steven P. Schnaars wrote a very valuable analysis of failed forecasts, called?MEGAMISTAKES: Forecasting and the Myth of Rapid Technological Change. In his book, he illustrated that most `megatrend’ predictions say more about the time they are made, than about the time that is yet to come. As a nice example: in the 1950’s-1960’s, some pundits and scientists predicted that education would radically change thanks to jet engines and TV. The idea was that we could put TV transmitters in jet aeroplanes, and have the lectures of the best professors broadcasted to earth. That way, all the students could get the benefit of being taught by the best professors. Nonsense, of course, but the interesting thing is that Schnaars argued that these predictions were believable at the time because they were so well grounded in the?present?of that period, they represented the ‘zeitgeist ‘. TV and jet engines were the obvious, impressive, new, and fast growing technologies of the day. Hence, they were automatically seen as the shapers of what would come after. Schnaars illustrated the way this had happened time and again. The same was true for most fantasy: e.g. 2020 IT in science fiction of the 60’s and 70’s that wanted to be realistic showed CRT screens and spinning tape reels of 60’s and 70’s IT, not the flat screens and invisible terabyte solid state memory of today. For flat screens in science fiction, you need to go to a period before the massive roll-out of TV. Science fiction of that period shows flat screens, as until then, screens?were?flat and were project upon.

Interestingly, Schnaars pointed out that the beginning of the IT revolution is one of the notable exceptions. Here, the pundits were often grossly?underestimating?the effects. E.g., in the early 1940’s, IBM’s Thomas J. Watson stated: “I think there is a world market for about five computers”. In the 1970’s many IT Executives thought it would be useless for people to have computers in their home (in all fairness: they generally thought people would have terminals in their homes that were connected to central computers, so they did expect people to use ‘computing’ in their lives). Bill Gates brilliance was not so much in technology, but in strategy and vision: he saw earlier than most that computers would become very affordable and ubiquitous. But such successful predictions in technology are rather rare.

Simply extrapolating a current short term trend is what most often happens in ‘futurology’, and that is unreliable indeed. But even a serious ‘weighing’ forecasting-framework like?Delphi ?for instance has a fundamental weaknesses. Delphi will enable you to find the most likely future based on expert assessment by experts. One notable weakness is that things that are yet unknown cannot play a role (missing information problem), so your experts must guess and then are generally not so much expert, more often simple trend extrapolators. But more importantly: suppose there are 99 possible futures, 98 of these have a 1% chance of becoming reality and one has a 2% chance, the Delphi method will reliably find you that future with the highest chance of becoming reality. Which in the example given is a future with still only a 2% chance, so basically little chance at all. (Scenario planning ?addresses this issue, by the way). The ‘best’ prediction doesn’t mean a ‘useful’ prediction.

So, forecasting is nonsense?

Not at all.?

There are many things that can be forecasted accurately. An important example is demographics, the statistical study of human populations. More close to home: in IT Strategy, the ongoing growth of IT volume (in the sense of the growth of the amount of machine logic and machine data) is pretty much certain. And with that growth comes the increasing importance and complexity of vulnerabilities, attack vectors, and thus IT Security. With the increasing impact of algorithms on our personal lives and our societies, increased focus on?ethics ?and compliance are somewhat of a certainty. And passed laws that come into effect years from now are pretty much a certainty for organisations. Some of such near-certain forecasts — especially the legal compliance ones — have the following effect on organisations: Adapt or die.?

When we can forecast,?planning?becomes your instrument. We need to plan for the near-certainties that await us. If the law requires a completely different approach to privacy, or to data ownership, or to transparency of your algorithms years from now, you must plan for that future and execute that plan.

So, there are things you can do with forecasting. The most popular mechanism that is used in IT Strategy, though, is ‘back-casting’.

Backcasting

Backcasting is a completely different beast from forecasting. We do not try to predict developments to see how we should?react. We want to?make?the future as we would like it to be. We’re not ‘victims’, we?act, we’re in control. Always a nice feeling in uncertain situations, the idea that you are in control,?n’est-ce pas ?

So, backcasting visualises a ‘desired future’ and tries to create a way to get there. Backcasting (and generally this includes the ‘valid’ part of forecasting — the ‘knowable’ future) is?the?predominant mechanism used in Business Strategy. Humans are essentially forward-looking, it is in our nature to do so. And in business, the idea of strategic goals, the?development of the business, reigns supreme. There are a few reasons for this, but the main reason is that backcasting fits the needs of upper management. Apart from upper management being humans too, it is upper management’s?job?to plan strategically. A mechanism that leads to a planning is thus generally preferred above anything else. It feels like the right thing to do.

This is also true for IT Strategy. Most IT Strategy (including Enterprise Architecture) has for decades now been based on backcasting, the ‘standard model’ from the 1960’s until today has been: take stock of your current situation (the ‘current state’), think where you want to go (the ‘future state’) and then think of a program to get there (‘gap analysis and execution’). Australian researcher Svyatoslav Kotusev has impressively documented the history of IT Strategy / Enterprise Architecture frameworks by showing that they all grew out of that same planning paradigm, all the way back to IBM’s Business Systems Planning (BSP) in the 1960’s. E.g. the well known TOGAF framework came out of the US DoD abandoned TAFIM framework, which in turn was again based on earlier planning-based approaches to IT Strategy and in the end also on BSP.

The Fly in the Ointment: IT inertia

So, there you have it: our strategic thinking in IT is mostly based on a?backcasting?paradigm, and it has been for the last half century or so. We have been told — and we are naturally inclined to accept — that one should base IT Strategy on Business Strategy, on Business Development, on Strategic Business Goals. After all, what else is there? But there is a serious problem, and the problem is getting more serious as the IT revolution progresses. That problem is the ‘inertia’ of massive IT. It is getting harder and harder to?change?our IT landscapes. The reason for this is twofold:

• IT is based on machine logic and we have created unimaginable amounts of such logic. But logic has a very nasty property:?it is fundamentally?brittle . One wrong bit can crash a complete system, or at least make it not doing its function as intended. Our attempts to mitigate that problem consist generally of using even?more?IT, which is both unavoidable and ironical.
• As IT takes a larger chunk of our behaviour — be it?our personal behaviour , our organisation’s behaviour, or even our society’s behaviour’ — IT gets more interdependent. IT systems do not act in isolation: they all influence each other. Even when we separate them technically with technical architectural tricks such as event-driven design, service orientation, etc., the IT systems depend on other IT systems in a?logical?way. Our landscapes unavoidably become a sort of?loosely coupled spaghetti .

The more IT we get, the harder it gets to change it. Besides, key elements in our IT landscapes have a life span that might be 15 or 20 years on average. Our strategies, though, are much more volatile. As a result, your IT landscape has to support on average 3-5 (potentially radical) strategy changes. E.g. If your organisation decides to move from B2B to B2C (or the other way around) changing your landscape, your?architecture , is much harder than changing the strategy, or even changing the humans.?Humans are flexible. IT systems are not. ?Systems are machine?logic, remember? They’re?brittle.?And using a two-speed or bimodal approach is mostly an illusion .

In other words: in this phase of the IT revolution, we are going to be forced to look at IT Strategy in a different way.

Strategic Agility: the ability to change your?strategy

So, the more voluminous our IT gets, the harder it gets to change our IT, and the more important paying attention to the long term agility of our IT becomes. If our business strategy is much more flexible than our landscape (which it is), it becomes important to pay attention to the agility of that landscape,?regardless?of your?current?business development ideas. We need not only create a landscape to fulfil your?current?desires, we need a landscape that has to enable you to fulfil?future, yet?unknown, desires.?

Years ago, I asked a CxO of some type: “Do you want to be nailed, screwed, and superglued to your current business goals?”. “No, of course not.”, she answered. “Well, in that case,” I replied, “you should take explicit control of that aspect yourself, because if I — as lead architect — tell them they should do things in ways that are not based on the current business development goals, they rightly ask me ‘who the heck are you to tell us?'”.

IT landscape/architecture is not the first business element that only makes sense in the longer term. Build a large physical production facility and you’re looking at decades as well. But culturally, we tend to see IT as fast-changing, flexible, volatile, small and independent (these are all illusions in large complex landscapes,?growth?is fast,?change?is slow ). Organisations do not pay much attention to the ‘ability to change direction’ of IT because most people assume that IT in principle is easy to change. And that is in part true. Individual elements are often easy enough to change. But changing larger elements and fundamentals becomes increasingly hard to do. And that is true too. These days, changing a core element in your IT landscape often takes longer than building a skyscraper. While a new skyscraper may be built in two to three years, the inertia of complex IT landscapes may result in projects taking several times that amount of time. Not because the people doing the change are morons, but because the change is becoming more and more a very complex problem.

Really, the aforementioned?singularity ?is a silly simplistic early trend extrapolation. What we are in reality looking at in IT is almost the opposite: a ‘complexity crunch‘.?And that crunch is not going to be a nice experience ?for all. But, nice or not, paying attention to your?strategic?agility — the ability to change your?strategy?— will become more and more important, I think. Without it, trying to reach development goals will be a more painful exercise than it needs to be.?

What does this mean?

What it means is that you are thinking about your IT Strategy, you need to keep an eye out for?three?elements, three ‘buckets’ if you like:

• Forecasting — changes you are?forced to?do
• Backcasting — changes you?want to?do
• Strategic Agility — what you?need to?do to be able to keep?changing?in the future

All three are ‘must haves’. But the third one is ‘new’ and gets more important as brittle and hard to change?IT becomes a larger part of who we are . The first two are more or less a ‘state’. That is why we can relate them to the term ‘future state’. But just thinking about the state as it supports the?current?idea of the?future?business (are you still with me?) does not take into account that in that future you will want to change?again. And again. And again. You might think of your future as consisting of a desired ‘state’?and?a desired ‘agility’ of that state. Future?State?and Future?Agility.

Unless you pay explicit attention to the future ‘agility-while-being-in-control’ (incidentally: the key benefit/target/value of?architecture ?as far as I’m concerned) of your landscape, your?futureplans will get stuck in the quicksand of your?future?IT. And the other way around: If you are currently stuck in IT-quicksand, this is because you (or your predecessors) haven’t been paying enough attention to the fundamental agility-while-in-control in the past. As I was told once: “Architecture today is your legacy in 3 to 5 years.”. There is no easy fix, alas. And remember: because the volume and complexity of IT keeps growing, this element of IT Strategy will become more important as the years ago on.

And, let’s not forget, watch out for?Broken SAFe . Did I mention the complexity crunch is going to be a rather frustrating time?

Yes, but…

A while back, someone said to me: “You know, I get it. But frankly, isn’t being ‘strategically agile’ also something you?want to?do and/or are?forced to?do? So, isn’t it already covered? Why make a separate category?”. Isn’t the Future Agility not just a property of that Future State??

I think, there are the following aspects part of answering this:

• If the ‘ability’ elements are managed as part of the other two (or just from a single ‘business development’ view), they tend to be overlooked. The?value?of ‘strategic agility’ is long term after all (though I suspect that it has medium and short term advantages as well) and short terms is hard to overcome;
• The other two are linked to clearly tangible results. This one is different, it is a goal that’s results that?are not directly tangible.?I am reminded of ?the way architecture and solving technical debt tend to be given low priority because working on these provide?potentialbenefits, while working on — even strategic — features and defects provides?actual?benefits.
• You create a separate category if it becomes important enough to manage it separately. I think the effect of ‘IT inertia’ is getting so big, it deserves separate attention. Just like for instance something like?Life Cycle Management ?or Security;

But neither of those are inescapable arguments. That might have something to do with the fact that management, strategy, architecture, and many more elements of behaviour are more an art than a science. And if you are able to make the Future Agility of your IT landscape an element that really carries weight, and that gets more than just lip service, then be my guest, make it part of the Future State. But that will require that?the people deciding understand ?not just the business outcomes (the —?ugh ?— ‘functionals’), but also what makes a healthy IT landscape. I would suggest staying on the safe side of that one. For those organisations that have matured regarding to understanding the effect of IT, paying attention to strategic agility may become so obvious, that they can and will stop paying specific or separate attention. As far as I can see, for most, that moment has not yet arrived.

Previously published as Should you derive your IT Strategy from your Business Strategy? Probably not too much.