IT Organization Circa 2017

There are characteristics of Level 1 and low Level 2 Business-IT Maturity that allow (cause?) the IT environment to become overly complex, and with that complexity comes high cost and low agility.  This complexity is a killer sticking point for getting to higher maturity. 

Let’s first try to understand what it is about the lower maturity levels and why they foster complexity.  Below is a simple form of the Business-IT Maturity model introduced in my second post.

Note that Level 1 demand tends to come from individual business units and functions, rather than by end-to-end business processes.  Recall that this is a business as well as ITmaturity model, at Level 1 the business tends not to be very process-oriented (there are, of course, some notable exceptions, but even then only for “signature” processes that are core and differentiating to the firm).  So, this siloed demand, and IT’s Level 1 “order taking” behavior is met with siloed supply.  (Remember the point in an earlier post that the more mature consultative and business partnership oriented behaviors tend only to become commonplace at mid-Level 2 and beyond).  Also note, that Enterprise Architecture does not really take hold until mid-Level 2, so all this siloed demand has no overarching business process architecture against which to bounce off and react to.

Consider a situation where division/business unit “a” needs a manufacturing planning system (MRP), as does division/business unit “b”, as does “c”, and so on.  The next thing you know, you have many MRP systems, all configured differently, often from different vendors, running on different hardware platforms.  I had one client who even had trouble producing an accurate count of their MRP systems – they got to about 47 different systems around the world, and gave up trying to count.  (They are now in mid-Level 2 maturity, and aggressively moving to global common processes and systems).

We can imagine the complexity of just maintaining that many different systems, and the resource inefficiencies in doing so.  Now imagine you want to add a data warehousing layer – think about the data feeds and interfaces that must be built and maintained.  Suppose that in Level 2, the business, perhaps forced by market conditions, quality problems, or simply by the need to take out cost, decides to implement lean manufacturing approaches.  The underlying systems and platform complexity becomes a daunting barrier – typically perceived as “an IT problem.”  Of course, it is, in many respects, an IT problem – unfortunately created by IT’s natural response to business demand.

There are zillions of other aspects of this complexity, and the reasons for it.  Early Level 1, COBOL or RPGII might have been the programming language of choice.   Later in Level 1, this was supplemented by a Fourth Generation Language such as FOCUS, RAMIS, or MANTIS.  Early in Level 2, C++ was the new language of choice, then Java.  Each of these “flavors of the month” languages left behind them legacy systems, legacy programming and testing tools, and all the other trappings of a development environment to be maintained.

Below mid Level 2, the notion of Programs as opposed to Projects is not well formed, so there is little sophistication in finding and managing the inter-relationships and dependencies between projects, adding to the complexity in the legacy environment.  Make a simple change to one system, and there may be hundreds (thousands?) of “knock on” effects to other systems and interfaces.

Then there is the complexity of change upon change of technology infrastructure – DOS to Windows to NT to XP Professional; Novell to Microsoft; Microsoft to Open Source; TCAM to VTAM to TCP/IP.  The changes go on an on – each leaving a layer of technology and the baggage it implies.  Oh, and then there’s the many acquisitions that are never fully integrated.

So, how do you break out of this complex environment, leave the boat anchors behind, and move nimbly into Level 3?  The answer is in some respects deceptively simple.  I’ll get to it with a story.  About 15 years ago, I was running a multi-client research project on IT transformation.  One of the big success stories back then (with several Harvard Business Review case studies) was BP oil.  They had grown through acquisition and all the other inevitable sins of Level 1 to the point where their IT infrastructure was exceedingly complex, costly and a constraint on business agility.  I was moderating a panel at one of our research workshops.  One of the panelists was a senior BR IT executive – a rather dour Scot with a heavy Scottish brogue.  Someone asked him, “How did you deal with all the legacy systems?”  He said firmly, in his heaviest Scottish accent, “Och, aye – ya just have to kick it in tha teeth!”  And with this one line, he really captured the key truth here – you have to have absolute, take no prisoners, executive determination – a “just do it!” approach to change.  He even told us about a giant CDC mainframe dedicated to scientific computing (for analyzing seismic data).  The IT leadership team had a strong suspicion that most of the scientific computing had migrated to desktop supercomputers.  To prove the point, after several attempts to get people to respond to inquiries about who still needed the CDC machine went nowhere, they simply shut it down, and waited to see who screamed.  One month later, nobody had whimpered, let alone screamed and several million pounds worth of hardware and annual operating costs were decommissioned.

How to you deal with the overly complex IT infrastructures facing many IT shops today?  You just have to kick it in tha teeth!