From Business-IT Alignment to Business-IT Convergence

I’ve posted before on the emergent confluence between business and IT.  I’ve also discussed the shift from Business-IT Alignment to Business-IT Convergence as an aspect of increasing business and IT maturity.  I’ve noted (Goodbye, Shadow IT – Hello, Shadow IT) that ‘Shadow IT’, often viewed as a problem to be solved might be more appropriately recognized as embodying the clues to the new reality of business-IT convergence.

The always-impressive Dion Hinchcliffe sums it all up perfectly in his post, “CoIT: How an accidental future is becoming reality“.  Hinchcliffe repurposes Computerworld’s Scott Finnie’s use of ‘CoIT’ as referring to the ‘consumerization of IT’ to a new term, ‘Cooperative IT.”  I’d like to humbly suggest yet another interpretation of CoIT as a shorthand for “Converged IT” – referring to a world where much of the work of the IT organization has converged with the business as a deeply embedded capability.

A Vision for CoIT

Hinchcliffe suggests some aspects for the vision of CoIT as embodying:

• Decentralized (or at least distributed) governance
• IT support that scales up to the new app/device proliferation
• Business led IT solutions with an enabling infrastructure

I think these are appropriate, though many details and realities to be yet worked through.  And, I believe, while the IT leaders who are most proactive in leading this shift will make some mistakes, they will also be the first to figure out the new realities and will ultimately make less mistakes and learn more quickly than their ‘ostrich’ counterparts who either believe this will all blow over, or that they can figure it out down the road.

What do you think?  Do you agree with Hinchcliffe’s vision?  What are you doing to exploit the emerging ‘converged’ reality of CoIT?

Digital Art: ‘Convergance’ by Wilby  courtesy of Iasos.

To Centralize or Decentralize IT – That Was The Question…

What are the key issues in thinking through the perennial ‘centralize vs. decentralize IT’ question?

This post was triggered by a question I received from a CIO over the holidays (yes, CIOs and management consultants don’t take holidays!)  He was trying to deal with a number of departments which insisted on having their own IT departments, with no accountability or responsibility to anything other than themselves.  (such departments are often referred to as “Shadow IT.”)  Sometimes these departments were interested in systems that were standalone and had little external impact, but more often these systems were interfaced, and the data and processes do impact other systems outside the department.

There are a number of issues behind this, but the key variable is business-IT maturity.  At low maturity, IT tends to be highly decentralized.  This may appear to provide a responsive and ‘customer intimate’ IT capability, but the reality is it does so at a huge cost to the enterprise as a result of redundant systems, unleveraged spend and resources, and the costs of supporting a heterogeneous IT infrastructure that typically results from highly decentralized IT.

Also, as competitive pressures and the need for improved coordination and business agility cause the discrete departments to move towards increased collaboration and more effective cross-departmental processes, they inevitably find the need for a more easily shared and consolidated IT infrastructure and common capabilities.  So, as IT drives up the maturity curve, it almost always needs to centralize – to get control of IT resources, capabilities and assets, and begin to rationalize and standardize them into a more efficient and sharable platform.  Further up the business-IT maturity curve, it may be both possible and optimal to decentralize certain IT capabilities.

The bottom line is that IT (like finance!) must be centrally controlled – no exceptions. This is not just leading practice, it is the only acceptable practice, whether you are looking from the perspective of security/privacy/business continuity, or from an audit or cost effectiveness perspective.  However, central control of IT does not necessarily imply that all IT resources and capabilities have to be centralized.  To clarify this, it is useful to distinguish between those IT capabilities that:

1. Should be common and shared across the enterprise, i.e., have a value proposition of Operational Excellence (e.g., data center operations, networks, desktop support). These are typically highly centralized under IT.
2. Are specific to a given business unit, i.e., have a value proposition of Customer Intimacy (e.g., opportunity discovery, very locally specific and rapidly changing local systems such as web sites). These are typically decentralized (more so in higher maturity environments, less so in low maturity).
3. Are future/innovation oriented, i.e., have a value proposition of Innovation/Product Leadership (e.g., Enterprise Architecture, IT R&D). These are typically networked across the enterprise, with IT taking ownership of “Centers of Expertise”.  Again, this is more the case in higher maturity, less so in lower maturity environments.
4. Are governing/aligning, including IT investment/prioritization/value realization, IT funding model, Enterprise Architecture, and decisions as to what capabilities are common and shared vs. business unit specific. These are most effective when they are business owned, and are implemented from the top of the enterprise.

Of special note here is item #4.  The business-IT governance and Enterprise Architecture mechanisms are typically either missing or weak (ineffective) in lower business-IT maturity organizations, which is why low maturity organizations must first focus on centralizing IT.  As governance strengthens and become more coherent, and as Enterprise Architecture strengthens and gets “teeth”, decentralization of items #2 and #3 becomes possible and, perhaps, desireable.

How does this thesis match your own experiences?  Have you seen situations that would argue against this thesis?  How might you apply this thesis to your own situation?  What can you do as an IT professional to help drive business-IT maturity in 2009?

Financial Forensics as a Clue to Dysfunctional IT

“To understand a crime, follow the money” is a familiar principle of detective work.  Over the years, I’ve found that principle to be extremely useful in the world of IT management.  In fact, my spin on it is, “If you want to understand dysfunctional IT behavior, follow the money!”

Of course, this principle helps detectives to not only catch criminals, it helps to get the criminals punished.  Similarly, in the IT world, I’ve used the principle to both understand what is leading to dysfunctional IT behavior, and to help correct that behavior by fixing the money-related drivers.  Let me provide an example and the application of this principle.  The example is, of course, fictitious, though based on real life situations I have worked over many years of management consulting and research.

First, a caveat.  Clearly, not all human or organizational behavior is motivated by money.  However, I have found that collective organizational behavior is significantly shaped by money – by the sources of funds, valuation of returns, and measurement inherent in financial reporting.

Scenario

Higgins-Smithbottom is a global fashion designer and retailer.  The company culture values the creative geniuses who come up with the hallmark designs, and places great freedom and authority on the heads of business units.  In common with the industry, success is seen to be all about great design, brilliant merchandising and effective management of the brand – three disciplines that seem to have little to do with IT.  As such, IT is an “expense to be minimized,” a “necessary evil,” and something that the IT organization is expected to “take care of with minimal disruption to the business” so that business leaders are “free to design, merchandise and manage the fickle fashion business unencumbered by IT.”

The executives at Higgins-Smithbottom are vaguely aware of contemporary success stories such as Zara and Li & Fung, but don’t recognize the role that information and IT have in these companies success stories.

Financial Forensic Clues

1. All IT capital and expense is managed out of an IT budget – the IT resource is essentially “free” to the business unit leaders.
2. There is no enterprise-wide IT prioritization and allocation process.  Resources are essentially allocated on a first-come, first-served basis, with the regulator on business demand being total supply – when all available supply is tied up, no other demand is accepted.
3. Because IT is “free” there are no attempts to measure and track the return on IT investments.

Dysfunctional Behavior

The perspective on IT is that it costs too much and delivers too little.  Even though business heads do not “pay” for IT, they know that the bottom line is impacted by it – IT saps profits and eats into the executive bonuses.  As a result, business leaders try to minimize their involvement in IT, invest no time or energy trying to understand it, or figure out how it can improve the business.  Consequently, IT contributes relatively little to the business.  It responds as an “order taker” acting on low value requests from business silos, without an overall IT strategy or architecture.  Each response to a business order adds more complexity to the patchwork of IT systems.  More time and money is spent on inter-system interfaces than on business enablement.

When a meaningful business request surfaces for management information or business analytics, IT finds it virtually impossible to respond, due to the complex patchwork of systems and lack of data standardization.  Lack of adequate IT resourcing and responsiveness leads business units to hire their own IT resources – sometimes as consultants and contractors, other times as permanent staff.  These “shadow IT” groups exacerbate the complexity of the systems environment, and mask true IT spending levels.

IT eventually finds itself in a vicious cycle – low business demand maturity begets low IT supply maturity.  When IT does get engaged by the business for a new system, it fails to “push back” on the business demand to “automate the manual process as is – don’t make us change the process!”  IT does what it’s told, even if that means customizing the heck out of an off-the-shelf package.  The customization triples the implementation costs, and sends subsequent maintenance costs through the roof.

Lessons Learned

1. When IT is “free,” it is not valued.  When someone else is footing the bill, there’s no sense of accountability from those who should be turning the investment into a valued return.
2. Without enterprise-wide prioritization and allocation, IT optimization takes place at the business unit level, leading to sub-optimization at the enterprise level.
3. Lack of enterprise-wide prioritization and allocation is typically accompanied by a lack of an overall IT strategy and road map.  This leads to islands of automation, and over time, the number of interfaces (and costs associated with building and maintaining those interfaces) increase exponentially.  After a few years, the vast majority of IT spend is related to interfaces – i.e., it’s all cost-added, without any value-added.
4. When IT is sub-optimized for the enterprise, IT “vacuums” get created throughout the business, and nature’s abhorrence of vacuums leads them to be filled by “shadow IT” groups.  This adds to actual IT spend, even though the shadow spend is not visible in the IT budget – i.e., IT is costing you more than you think it is.
5. Being “cheap” with IT usually ends up being very expensive!

Shadow IT: The Good, The Bad, and the Ugly

I’ve posted before about Shadow IT, but I want to revisit the subject – I think it’s a big issue that needs some more air.  I’ve been reminded of this lately as I work with a client with a neglected IT capability.  A new CIO has been brought in (the first sign that a hitherto neglected IT capability is now getting some attention) and he’s asked us to help him review the global IT operating model.

Among the challenges this CIO faces are a number of Shadow IT groups – small groups of people doing IT work around the company, but outside of the IT budget, governance, accountability or responsibilities of the “official, sanctioned” IT organization.  BTW, when I come across Shadow IT groups that are known/recognized, I always wonder about other Shadow IT groups that might be lurking so deep in the shadows that they are all but invisible.

Shadow IT groups are often a symptom of unmet (or poorly met) demand.  As such, they are prevalent in low business-IT maturity environments (i.e., demand appetite exceeds supply capability, so demand creates its own supply).  Paradoxically, they are also prevalent in very high business-IT maturity environments, although we would probably never refer to them as “Shadow IT.”  More likely we’d think of them as “power users,” or “embedded IT capability” and we’d encourage and celebrate such indicators of high maturity.  So, rule 1 – it’s important to know why you have Shadow IT.  If it’s a result of low maturity, I strongly believe Shadow IT needs to be integrated into the formal, sanctioned, budgeted IT operating model.  If, on the other hand, Shadow IT is a result of high maturity, then the right infrastructure for them needs to be provided, and they should be prodded and encouraged.

Why do I think Shadow IT in low maturity environments should be eliminated?  First and foremost, because they are a symptom of low maturity.  If you are going to eliminate them, you have to commit to (and act upon) improving the state of IT capabilities.  This is, of course, a good thing.  Additionally, Shadow IT groups are often unwitting impediments to improving IT capability.  If as CIO I don’t have the entire budget, then IT spend is sub-optimized.  If as CIO I don’t have control of IT standards, processes and practices, then it is that much harder for me to improve IT capability.  It’s not that some IT capability should not be embedded in the business – it absolutely should.  But exactly what to embed, when and how to embed it are important questions that need to be thought through and the IT operating model properly “designed” (at least at lower maturity levels).  Designing an IT operating model to be something akin to Swiss Cheese, where you have to design around the holes is not efficient, and is not a good basis upon which to drive an IT transformation.

Finally, there’s a “tough love” aspect to tackling Shadow IT groups.  When I was a kid growing up in London, UK, I went to a school where uniforms were de rigeur, complete with school caps!  (Long before AC/DC’s Angus Young showed us how cool they can be!)  I was caught once too often without my school cap and was sent to the Vice Headmaster’s office for a dressing down.  Fortunately for me, he was a wonderful man with a sense of humor, a Royal Airforce mustache and manner, and a vintage Rolls-Royce to boot!  He gave me one of life’s great lessons – that it was not about wearing a school cap, per se, it was about setting and living within defined boundaries, so rebellious chaps like me could push against them without doing real harm.  It’s like a parent disciplining their children – if the discipline is absent, the child will feel unloved.  (Of course, too much discipline is even worse!)  Anyway, when the CIO (with appropriate air cover from the CEO and executive team) announces that all IT will be managed under a single IT budget, and all IT-related resources report to the CIO’s organization, this sends a message to the firm – we are raising the bar on IT!  People may not like it, but they will like the fact that someone is getting serious about improving the performance of the IT function.  I’ve often seen situations where the predictions of “Oh, this will create a real stink and lots of resistance!” was far from what actually happened.  Instead, people said, “About time – please take this group back into IT – its where they belong, and where they will have the best growth and career opportunities!”

So, if you have a Shadow IT problem, don’t be a wimp!  Tackle it head on as an integral part of your IT transformation plan.  Be ready for the noise and resistance, but don’t let it derail you!

Goodby, Shadow IT – Hello, Shadow IT

In our multi-company research WebEx call earlier this week a participant reflected on the changing attitudes to “Shadow IT” – that term IT professionals give to non-IT professionals when they ‘step into their IT professional turf’ and do stuff that should have been ‘better left to the professionals.’

The Shadow IT phenomenon is a great example of what I’ve referred to in the past as ‘sticking points’ – things you need to do to drive Business-IT Maturity from Level 1 to 2, but that if you keep doing, will stick you at Level 2 – in fact, you almost literally have to ‘undo’ them to get to Level 3.  Let me explain.

At lower Business-IT Maturity Levels, Shadow IT is by and large, bad news.  First, it’s typically a business response to a need that the IT organization is not fulfilling – i.e., it’s symptomatic of a problem.  Second, because it is typically IT activity that happens ‘in the shadows’, it often does not have the integrity or recoverability characteristics that a ‘professionally built’ solution would have (at least, in theory!)  Third, given this, after a time, the ‘one-off’ solution created by Shadow IT evolves into a mission critical system, and gets handed to the IT organization with a plea for, “Can you please sort this out and maintain it from now on?”  This sometimes creates a problem because the solution was developed by a non-supported or non-standard technology.

So, typically in late level 1, the CIO goes Stalinist and demands that all IT budget and resources be centralized under his or her control.  This allows rationalization and consolidation, and generally helps elevate maturity into the Level 2 space.  In parallel with this, the architecture group gets empowered, principles and standards are declared, technology roadmaps produced, and IT architectures created.  Welcome to Level 2.

The paradox, however, is that to get to Level 3, the power of ‘end user computing’, for want of a better term, is critical.  That’s where most of the business knowledge lies, where the business problems are felt most intimately, and where most of the ‘arms and legs’ are.  And, given that Level 2 created all that fine IT and Enterprise Architecture with supporting infrastructure, it is now possible to safely unleash the Shadow IT monster!  Rather than see Shadow IT as an evil to be tempered, it must now be seen as a force to be harnessed and directed.

You can see the challenge – in a relatively short period, perhaps 18 months or 2 years, something that was treated as a pariah must now be cherished and nurtured.  This creates a kind of mental whiplash that most people can’t easily absorb.  But I believe that you have to manage through this see-saw to get to Level 3 and the business value that is unleashed at Level 3.  Recognizing this phenomenon, and being able to dialog about it is half way to solving it.

Wecome Back, Information Center – All Is Forgiven!

 

Earlier in my consulting and research career, especially in the early-1980’s to mid-1990’s, an IT organizational construct typically called “The Information Center” became popular in medium to large enterprises.  The philosophy behind the Information Center (IC) could be captured in a single phrase, “teach them to fish so they’ll feed themselves for a lifetime.”

IC’s comprised a small group of IT professionals (typically between 3 and 15 in number), a suite of tools (e.g., so-called “4th Generation Languages” such as Focus, Ramis, Nomad, and analysis/reporting tools, such as SAS and SPSS) and, especially early in the IC movement, a place for end users to go to get access to these tools and the mainframe computers they ran on – often a room with computer terminals, reference materials, a printer or two, photocopier, and so on.

The forces that led to the popularity of the IC were:

1. Demand by end users for information that was effectively “locked” in computer files and systems.  Remember, back then, relational data bases were not common and many computer systems were batch processes with data stored on computer tapes.  Yet a great deal of money and effort had been spent creating and deploying computer systems to process transactions – a ton of data was being captured, and end users (the term of the day) wanted to analyze and make decisions based upon that data.
2. IT organizations were overwhelmed by requests, and most suffered a multi-year backlog – if you went to someone in IT with a request to run an analysis of last month’s sales performance, you might well be told, “We can get to that in 28 months – can you wait?”  I recall in those days Data Processing Managers (as CIO’s were then commonly called) often touted their application backlogs as badges of courage – “See how popular my department is!”
3. Powerful end user computing tools such as Focus and Nomad, and languages such as APL were becoming available – many of these first offered through time sharing services.  The attraction here was that you did not have to deal with the Data Processing organization, you could pay “by the drink”, and the time sharing services provided training and support.  (If this sounds similar to today’s emerging Software as a Service [SaaS] phenomenon, it did share some important characteristics.)
4. Internal computing power was getting cheaper as mainframe price/performance improved, and as cost of computer terminals came down.

So, in many respects, the IC was a response to emerging business demand (for information, reports, small systems) and evolving IT supply (tools, processing capacity).  I’ve talked before of the coming business-IT convergence, and IC’s were a very primitive form of convergence.

The good news/bad news of early IC’s lay in the fact that the end user literally came to a center.  This afforded the IC a measure of control and supervision over end user computing.  It even afforded a measure of reuse, commonality, and integrity – “Hey, Fred, I see that you’re trying to build a pricing model in APL.  Anne was in here last week doing something very similar – let’s use that as a starting point.”  (Not that APL was well-know for its reusability characteristics!)  Or, “Bill, I see that you want to create a sales commission system.  Susan was looking at monthly sales last month, and we had Data Processing create a sales data extraction routine that loads a Focus data base every week.  I think you can use the same data base.”

The bad news of the early IC model was that the end user had to leave their office and go to the center – perhaps even have to book time on the terminal, or hope that there’d be terminal available.  So, when PC’s came along, end user tools got even easier to use (Lotus Notes, Excel, Access), and the IC had created its own backlog (“I can find a terminal for you at 7am on Monday in 3 weeks time!”) personal computing really took over from IC end user computing, and today’s “shadow IT” phenomenon was born (or, at least, exacerbated).

I believe that IT circa 2017 is all about “end user computing”, though with an important collaborative and cross-enterprise twist.  Level 1 and Level 2 IT is creating an “infrastructure” of capabilities that automate and model the enterprise.  Level 3 business-IT maturity is about unlocking this incredibly rich and valuable asset and putting it back into the hands of the people that can best leverage it.  It’s also about business analytics and the power of number crunching to drive business decision-making.  Perhaps it’s time to look back at the Information Center, dust off the ideas and practices that worked and bring them into Web 2.0 time!

Time to Foment a Revolution – Part 1

In the interests of being controversial and stimulating some potentially enlightening debate, I was thinking today about “shadow IT” and their role in the world of IT organizations circa 2017.

To be clear, I’ve spent much of my consulting career helping IT organizational leaders eliminate (or at least, reduce) the scourge of the dreaded “shadow IT.”  These were both a barrier to successful IT maturation (they would not get on the standard platforms, did not really know what they were doing, hijacked available IT spend/business demand that otherwise should have flowed to the “real” IT organization) and a reminder that, in some way, IT had failed, and shadow IT had surfaced as a response to our failure.

Now, as we move towards 2017, and towards Level 3 business-IT maturity, I’m re-thinking the role and nature of shadow IT.  I stand by my prior positions on shadow IT – if you are trying to get through Level 1 maturity, you have to reign in shadow IT.  It’s all about “getting control” so you can standardize, consolidate and rationalize.  However, to get to Level 3, I think you need a reversal of position – shadow IT is good – to be encouraged and steered, rather than discouraged and eliminated.  First, this is pragmatic.  But more importantly, it’s about Level 3 IT having a solid Level 1 and 2 capability (basic platform for Level 1, and transactional platform for Level 2), on top of which the business can innovate – requiring business-embedded IT capability – i.e., shadow IT.  At this stage, shadow IT is not an admission of IT’s failure – it is a recognition of IT’s success in enabling higher value IT activities, which, by definition, are close to/embedded in business capability.

Viva la shadow IT!