Executive Advisory Program

Mike Rollings Blog - Moving Day

Posted by Mike Rollings

This is my last post to the Executive Advisory Blog.  Here forward I will be posting to the Gartner Blog Network.  My inaugural post is “Challenged by relevance? Make EA disappear”.  This post embodies my hope for the enterprise architecture discipline (and for that matter other business disciplines).  That hope is to contextualize messages, approaches, methods and other things we create to the decisions that must be made and the people who are making them.

All of us must learn to be deliberate in our understanding about the various types of people in our organization.  We must be deliberate in our actions to promote consistent communication after we decide what that communication needs to be and how it needs to be contextualized.  Only then can we choose methods and approaches that are truly helpful to the communication and the decisions that need to be rendered.  

Thank you for your past and future interaction.  

Burton Group’s Mike Rollings blog on GBN =  http://blogs.gartner.com/mike-rollings

EA is not the Center of the Universe

Posted by Mike Rollings

Copernicus, born 19 February 1473, started a scientific revolution by showing that the motion of celestial objects can be explained without putting the earth in the center of the universe.  A person gazing into the sky from earth perceives the stars rotating around the earth.  But Copernicus looked deeper.  He found that looking at the situation from a different perspective (from the Sun) proved otherwise.  His proof through observation overturned the perception.  This one discovery opened up a world of possibility in astronomy.

We need a Copernican revolution for enterprise architecture.  For an example look no further than the idea of looking for a better name for EA.

Tim Westbrock posted his take on Q&A at the Open Group Conference in Seattle: 

"Q1:  If Enterprise Architecture as practiced by most is really IT Architecture and Enterprise Architecture is not a term that will be embraced outside the IT organization, what should we call it?

Tim’s Answer:  Although it is not as catchy, my first thought was Enterprise Planning & Optimization.  Until something sexier or more appealing comes along, this is my suggestion. "

This question came from the Q&A in my keynote "Enterprise Architecture - Disappearing into the Business".  I was asked "if you are recommending that we stop focusing on EA then what do we call it"?  I responded that I don't care what you call it; I care that you do it.  If you focus on the right things NOBODY WILL CARE WHAT YOU CALL IT.

Tim and I had a brief discussion afterwards and he pointed out a suggestion from my talk based on my definition of EA -- a planning, optimization and design discipline that is fundamentally based on the identification of dependencies, implications and constraints.  While I am flattered that he chose my words, I don't want you to call it "Enterprise Planning & Optimization" unless you are actually doing it inside your organization.  We do not need another term to become meaningless like "enterprise architecture".

If your organization looks at EA as a techno-focused activity, then it is not because of the name you gave the function.  Most likely you are perceived as techno-focused because you are acting this way!  Also, odds are that someone in the organization has begun to fill the void left by the techno-focus on EA.  If so, then connect with them to enrich the result.  Thinking that a new name will solve your problems is nothing more than a control game.  The enterprise architecture community must let go of the idea that they are in control.  Control has never worked as a means to establish a discipline.

The best advice - stop focusing on EA like it is the center of the business universe.  Change your focus to being focused on business outcomes and to influencing better decisions that lead to to those outcomes.  Seek out ways to influence the decisions that occur (or need to occur) in the delivery chain.  Focus on helping the organization apply the discipline.  The best way to establish a new meaning to EA in your organization is by redefining what you are doing!

Come to Catalyst:  If you would like information about presenting at our Catalyst conference in Prague 19-22 April or to submit a proposal see our presenters page.

To get a discounted price of €995 use the promo code “INSIDER” during registration.

Too Much Automation, Not Enough Insight -- the redefinition of BI

Posted by Mike Rollings

Today I am working on my presentations for Burton Group's Catalyst conference "Forging Ahead: Navigating the New Normal" in Prague April 19-22.  Joe Bugajski and I will be doing the keynote for the business intelligence (BI) track -- What Can IT Do to Deliver Business Insight – Not Just Intelligence?

BI is 25 years old, yet its promise of important insight eludes most organisations. CEOs list BI as a top initiative and simultaneously lament poor results from large BI investments. One reason for this incongruence is the detrimental effects of the automation mindset and the pursuit of efficiency.  BI is aimed at the wrong thing.

For the last 239 years organizations have been applying automation as their primary tool of choice to improve production and efficiency.  An automation mindset erupted with the dawn of the steam engine in 1771 and was honed to razor sharpness by the management revolution started by Frederick Winslow Taylor.  This mindset has shaped how many have applied BI.  For most organizations, BI is nothing more than a glorified reporting tool to examine efficiency. They use BI to look in the rear-view mirror and learn about the past, but most are unable to predict upcoming events or learn lessons that will help them make decisions to navigate uncertainty.

The need for insight is not the tail (of technology) wagging the dog (business).  Management innovation is reshaping organizations perspectives about the devotion to efficiency where the goal is to reduce human involvement.  Profitable innovators are not driven solely by efficiency; they look for ways to magnify human involvement. They realize that the reshaping of organizations and management called for by the new normal thrives on how well they can foster the development of insight by humans. 

Joe and I believe that BI must trend toward a new definition – Business Insight.  Insight represents the opposite goal of automation, and it should reshape the primary purpose of most information technology organizations. We hope you can attend Catalyst to discuss this significant shift in thinking.

If you would like information about presenting at our Catalyst conference or to submit a proposal see our presenters page. 

To get a discounted price of €995 use the promo code “INSIDER” during registration.

If IT was King... (but it is not)

Posted by Mike Rollings

Maybe I'm just sensitive, but the recent McKinsey Quarterly article "Using IT to enable a lean transformation" by Nicklas Ilebrand, Tor Mesøy, and Remco Vlemmix was a disappointment.

The article started out okay, "Senior leaders can play an important role in assembling a lean program by involving the CIO more closely in designing and executing the transformation."  Definitely agree that transforming one cog in a machine that needs to be redesigned is a bad idea.

The authors continued,

"At one large European bank, executives wanted to speed the account-opening process for corporate customers...While lean techniques could address these issues, the bank had experienced roadblocks in previous lean programs, which in the end failed to deliver the hoped-for returns...Operational changes failed to gain a toehold as employees fell back into their old ways of working, and the program fizzled once the start-up phase ended...Senior managers, determined not to launch yet another stalled implementation effort, knew that IT had to play a central role in the lean redesign of the corporate-account program..."

But the conclusion did not match the story, "Because IT can help not only to coordinate program deliverables but also to spot opportunities to lower costs and boost innovation, CIOs are often well placed to lead the joint effort."  McKinsey, have you been reading your own publications?

I think the article builds a case for the following conclusions, just not the conclusion that "CIOs are often well placed to lead the joint effort":

• IT is as relevant as manufacturing, marketing, sales, and other organizations as part of a business transformation.  Leaving out a major piece of the puzzle was a fatal flaw.
• Business transformation must be led by the business to succeed, and cross-functional participation is a must.  
• Don't believe that just because you tell someone to change that it will happen without support to make it happen.
• LEAN helps you focus on an outcome.  Changing the outcome requires getting all the players in the room to figure out the new play.

This is a posterchild for "how not to conduct a transformation".  I bet the authors looked at the pieces of the story that illustrate the cross-silo coordination of technology changes and for that aspect I agree, the CIO is best positioned.  But the CIO does not rule over the domain where these other failures happened -- the business.  I just don't want to see CIOs thrown under the train as they try to push transformation when the business is not on board.

Check out the other Executive Advisory Program transformation blog posts here.

Business as Unusual

Posted by Mike Rollings

In my last post I stated, "This is my first post as a Gartner employee.  In the spirit of business as usual, here we go".  Truthfully, this is anything but business as usual, and that is good.  The New Normal is filled with business as un-usual.

Taking a page from my own research in April 2009, "Real Transformation: Why IT Change Is Not Enough"...  "Your organization’s success has been built on a set of assumptions. Those assumptions have driven choices related to every aspect of what you do and how you do it. But fundamental assumptions upon which you have built success may have dramatically altered. Like any life-changing event, this may alter what customers you serve, the products and services you provide, and the processes and information required to support a new normal".

In the new normal all organization's need to release the death grip on what you think is important based on assumptions about the past, and they must keep in mind two uniquely human characteristics. 

First is our ability to derive comfort from 'business as usual' and to let it obscure our ability to see anything other than what we 'want to see'.  Like Michael Disabato writes, "Processes provide a framework and guidance, but should not be relied on as a universal panacea. While processes must be executed to be effective, blind reliance on them in the face of changing requirements is a recipe for disaster. Likewise, metrics can be a trap for the unwary".  Human's have an ability to develop blind reliance on status quo and 'facts' -- we manufacture reality. 

Many facts are 'facts' because we have declared them to be 'fact'.  The analysis that provided comfort to the managers of financial instruments leading to the sub-prime mortgage crisis is one example.  Another piece of this puzzle about 'fact' is in front of your eyes right now -- the device that allows you to read this blog post.  The device allows you to search and find your own facts, but it also has the power to obscure them.  Many of the business and information systems within organizations present a fact that was determined by someone (or something) else.  Do you really know why the information should be trusted?  When you add the fact that many data environments have multiple pieces of data that could be considered the same 'fact' and the one selected is just one of many possibilities, then it really makes you think, doesn't it?

The over-reliance on ‘facts’ also applies to planning by past patterns.  Don't assume it is the same situation and the old-business playbook still applies.  A pattern may render an important piece of the puzzle, but assuming it is the same is dangerous.  (Also see ‘Fixing Intel’ is a wake-up call for analysts everywhere).

The second uniquely human characteristic is our ability to use our minds to use information from multiple contexts to create a new insight.  This is an amazing gift that we all possess.  But as Gary Hamel states in "The Future of Management", "The machinery of modern management gets fractious, opinionated, and free-spirited human beings to conform to standards and rules, but in so doing it squanders prodigious quantities of human imagination and initiative.  It brings discipline to operations, but imperils organizational adaptability".  Hamel's statement is not a call for anarchy, it is a call for all of us to engage the human mind and spirit to do amazing things that are otherwise impossible, and to reorient organizations so that this can happen.

I believe we need to reorient our technology focus too.  Our IT focus for the last 50 years has been to automate and to fuel the credo of modern management -- pursue efficiency ahead of every other goal.  This is not surprising, since modern management was invented to solve the problem of inefficiency.

Frederick Taylor who is regarded as the father of modern management believed that an empirical, data-driven approach to the design of work would yield big productivity gain.  Hamel quotes Taylor who maintained that efficiency came from “knowing exactly what you want men to do, and then seeing that they do it in the best and cheapest way.”   But as Hamel further illustrates, this has become a liability for organizations trying to drive innovation and to tap into the human ability for discovery.  An overt focus on efficiency and its brother automation can hobble our ability to benefit from human insight.

The new normal requires forward-looking insight versus an over-reliance on historical patterns and 'facts' that may be irrelevant.  The new normal is business as un-usual.  As we proceed, we need to account for these two uniquely human characteristics to make the most of what lies ahead.

Marginalizing Enterprise Architecture

Posted by Mike Rollings

This is my first post as a Gartner employee.  In the spirit of business as usual, here we go.

Business Process Management (BPM) is a discipline for managing business processes explicitly as strategic assets.  Richard Watson states in his Burton Group document “Market Profile: Business Process Management Infrastructure 2009” that the BPM infrastructure market is growing and it  appears immune to recessionary forces.  The BPM market continues to grow.  BPM market growth should be great news for enterprise architecture (EA), but it is not all good news.  

EA includes the pursuit of business architecture -- a representation of the collective understanding of the business model, current strategies, business functions, processes and information.  Because BPM is married to process and information then BPM should mean good things for EA, right?  Surprisingly, no!  The way that BPM is happening in some organizations foreshadows a bigger trend for EA and a bifurcation of what we have long thought EA includes. 

In organizations pursuing BPM, Business Capabilities and Business Architecture should finally take center stage -- successful examples of BPM show that they do even if they do not use these terms explicitly.  The concerning part for EA is that Burton Group’s Contextual Research Study conducted in December 2009 shows that the people responsible for these successful BPM programs do not describe what they are doing as EA.  In fact, some even say that they are still figuring out how to connect with the EA group.  WOW!  One would think that EA teams would be celebrating in these organizations, not disconnected!

The good news is that the business is doing business architecture related activities.  The bad news is that EA is beginning to disappear into the business. Why is this happening? I believe it is because the EA community continues to make EA appear "special".  EA has become just another thing that the business does not understand and therefore feels "Oh, let IT worry about that".  The special language, the pursuit of EA as a profession, and the fact that people still are trying to figure out what EA is, what it does, and what it looks like when it is successful all contribute to the marginalization of EA.

Yet, this can be a good thing for the EA discipline - practitioners just need to come to realize that EA has gone through a fundamental change and EA does not exist solely as an IT competency.

• Embrace this and feel good about it - many already have.
• Learn to describe architecture’s business contribution and value without using EA’s secret language.
• Deliberately avoid a highly theoretical approach to EA in favor of helping produce results.
• Describe what you can do to help versus describing EA.
• Help the broader audience of business and technology professionals use the knowledge of dependencies, implications, and constraints to improve their results.

As I said in my blog post "Is the business result more valuable than 'EA'?", the reason we care at all about the analysis techniques etc. in the EA bucket is because we want to improve business outcomes – not because we care what you call the bucket!  When you focus solely on the bucket it leads to ivory towers, ineffective processes, a lack of participation, and low stakeholder commitment. I would rather focus on the value to the business. The foundations of good architecture are disappearing into the business.  Go with the flow!

#EA #Gartner #BurtonGroup #BPM

Metaphors, Models, Phases, and Stages

Posted by: Jack Santos

My fervent wish for 2010 is that all the cloud hoop-la from vendors dies a slow, gracious death, and we continue to hear about real-world examples of success using new, and different, business solutions. 

What's interesting about "cloud" is that it really isn't new -- but it does reinvigorate an option that has always been there for a CIO.   Many companies I speak to are excited by alternatives and potential new ways of doing the work – sometimes cheaper, frequently faster, and often better -- see my recent Burton Group doc on "Elastic Computing" for more (if you are a client).

But a home phone voice-mail failure brought home what cloud is really all about, and how (in a small consumer based example) it really is an old dog with old tricks.  In fact, it’s such an old dog, I think we can identify stages of computing based on cloud/non cloud maturity.

Stage 1:  Do it yourself (DIY) voice-mail:  You may all remember the answering machine – an early form of voice-mail – and how we flocked to it.  Yes, tapes, mini tapes, even memory chips were different incarnations of the “home answering machine”.  Prices started high (50-100 dollars or so in the 60s – I’d hate to think what that is in real dollars today)…and many of us went through multiple incarnations.  We set it up, had it take desk space, power, and mind-share (how do I replay that message?).  Then there was network based VM, and the game changed.,

Stage 2: The “almost cheap” voice-mail:  So somewhere in the 80s (maybe late 70s), the phone companies started offering phone based voice-mail.  Voice-mail in a cloud. And everyone flocked to that.  Ostensibly cheaper – it didn’t require an initial cash outlay, although over the life of the service it was way more expensive than Stage 1 DIY.  But, being creatures of habit and installment plans, why go back?  Out of sight, out of mind, a bit easier to use, no maintenance, no desk space, no fuss, no muss.  Did we worry about security?  rarely.  Everyone trusted Ma Bell’s children, and even after caller id hacks got strangers into celebrity mailboxes, no one blinked an eye.  Some of that applies today with commercial cloud usage… cheapness is just a mirage, a trade-off…security a dream.  But most consumers are willing to accept the shortcomings.  And those that don’t just had a little less desk space available.

Stage 3: The ubiquitous, duplicitous voice mail:by the 90s, and 00s cell phones were in vogue, and – guess what – whether you liked it or not  you got an answering machine thrown in – either through an explicit charge, or as a hidden charge.  Voice-mail in a cloud, on steroids. Try to get a cell without a voice-mail account – the best you can do is turn it off – but it’s still there and you pay for it.  Now everyone has multiple voice-mails, using multiple protocols, an inability to integrate across systems (or at least an unwillingness by the carriers), and a fair amount of frustration by consumers.  Ubiquity not only has its costs, but also its confusion – and we live with that today.  Except for the ones without cell phones, and with the box on their desk.  And for cell phones – driven by mobility and anytime/anywhere access – there is no desk.

Which brings us to stage 4:  A world were some people (at least for this commodity example) still have the DIY option running (although they are few and far between since land lines are disappearing faster than the Ross ice shelf)… and “cloud” solutions are on the brink of bringing some level of sanity to the confusion of ubiquity – Google Voice is a prime example.  An answering machine of choice that can handle all the different ways of reaching you, and has one set of features – accessible on-line, integrated with email, messaging (did anyone say Unified Communications?).  This is a world where services are even more distinctly defined, unbundled, and offered over the internet. The "voice-mail as a service" stage.

This, my friends, is a stage still in the making for most compute services today;  It’s a stage that encourages entrepreneurial solutions, and solves problems in ways that weren’t  capable just a few year before. Answering machines have shown us the way

Mike Rollings– Research Director for our Enterprise Architecture service, makes the case for an even more advanced stage of “voice-mail as a service” leading to a single voice-mail service for users that works seamlessly with other phone functions.  I suppose one can make the argument that things like Google voice, rather than being viewed as just  a pure “integration engine” (not unlike the old screen scraper metaphor for desktop integration) is a step toward that. 

So what do YOU think?  Do these stages begin to form a model for computing maturity in an era of clouds?  Does the history-of-the-answering-machine metaphor hold true for most commodity services, and maybe even some non-commodity ones?

BPM #fail - Organizations adopt disciplines and people adopt approaches

posted by Mike Rollings

Last week I went to Cocoa Beach Florida to collaborate with Richard Watson, Anne Thomas Manes, Chris Haddad, and Kirk Knoernschild on our Business Process Management (BPM) research initiative.  Throughout the week we analyzed the results of our client and non-client interviews.  Many interesting insights were formed regarding their experiences, and we learned a lot from their struggle to do BPM.

One insight that I want to share with you is related to the same struggle that organization's have with pursuing enterprise architecture (EA) and service oriented architecture (SOA) -- BPM is a discipline not an approach. 

If you think that a methodology or a 'way of doing something' is the secret sauce for BPM, EA,  SOA or any other programmatic change initiative then look a bit harder.  The real secret sauce is recognizing that you are dealing with adoption of an organizational discipline -- a lifestyle change.  For these initiatives to be successful you need to get the whole body involved. 

BPM is no different.  Many struggle with finding the right approach, gaining adoption, rising above an automation mindset, and several other challenges.  Yet, all volunteer that culture is something really hard to overcome.  Culture has become our favorite punch-line to a very bad joke.  "Did you hear the one about the organization adopting _ _ _?  They could not change their culture".  Just fill in your favorite initiative, chuckle, and then commiserate with your neighbor.

It seems that organizations give up on transformation and put in place coping strategies to live within the status quo.  They give up on asking the question "should we be doing this process at all" and instead ask "how can we automate what you are doing". More often than not they give up even before trying and look for the path of least resistance.  It appears easier to go after automation, then monitoring, and then improvement.  But would you really make it any easier to change status quo? No. The net effect is further calcification. 

BPM will not make any automated process easier to change if humans never examine its relevance and value to the larger whole.  The notion that you can convince someone to change later after you have further solidified their beliefs is delusional.  Want to hear a radical thought?  Some have even figured out that doing process execution is the LEAST valuable part of the endeavor -- they are focused on business optimization. Notice I did not say 'process', I said 'business'.  Yes, like we have learned before, you can do a discipline without shiny new tools.  Tools can help, but a tool-centric approach is not going to give the organization discipline.

Repeat after me "Organizations adopt disciplines and people adopt approaches". 

For more information, Burton Group clients can refer to "Real Transformation: Why IT Change Is Not Enough".

Let's do the time warp again...

Posted by Mike Rollings

Rocky Horror Picture Show fans will immediately sing the title of this post in their head.  It's funny how the mind associates things.  The same thing happened when I read a recent article:

(Edited excerpt) "The initial reaction was anything but positive. They thought it was a horrible idea... every institution he funded demanding ever more computer power and duplicating research on those machines. At the time computers were completely incompatible and moving data was a huge chore. The resistance came about because those institutions wanted to keep control of their computer resources. But, they soon saw that hooking up to it meant a huge increase in the potential computer power they had at their disposal.  They quickly learned that there was a tremendous gain for them, and it also fulfilled the goal of cutting spending on computers".

I read this and thought it could apply to a discussion about cloud computing, decisions about shared corporate computing environments, or just about any transformative change. 

What did this quote apply to?  Forty years ago today data flowed between the first nodes of what was then known as Arpanet -- the beginning of the Internet.  Mark Ward of BBC News interviewed Dr Larry Roberts, the MIT scientist fundamental to Arpanet.  The article "Celebrating 40 years of the net" describes what happened.

Happy Birthday Internet! The story is just another reminder that human behavior is a critical aspect of change.

 

Ravaging the Industrial Commons

Posted by: Richard Watson

(Mike Rollings and I are guest posting to each other’s blog today to give our readers another perspective – check out Mike's post on role reversal at the Application Platform Strategies blog here.) 

Robert Hayes from Harvard Business School posted a provocative blog entry last week, “Outsourcing Is High Tech's Subprime-Mortgage Fiasco”. This post helpfully provided me with some new language and clarity to add my take on what Burton Group is describing as “Externalization of IT”.  The desire to use external providers to replace or augment IT functions presents a menu of options including cloud computing (at its multiple tiers), and outsourcing (including off-shoring).

Here’s my Homer Simpson one line summary of causes of the financial crisis:

Institutions did not price risk correctly because they were making too much money.

What was the lesson we learned from IT business process outsourcing (BPO) efforts, (primarily off-shoring software development) in the mid-2000s?

Enterprises did not price risk correctly because they (believed they) were saving too much money.

Many of these efforts were me-too strategies, driven entirely by short-term cost saving outcomes.  For IT organizations that couldn’t adapt, an expensive repatriation exercise for some IT functions has cost who knows what.  The costs were both hard: penalties for extracting themselves from BPO contracts, rehiring local development expertise; and soft: lack of business and project continuity, and the loss of trust with the business customer.

Robert Hayes again:

The supposed savings they expect to generate from such activities are based on costs that often do not properly reflect the damage they are causing.

Hayes is primarily discussing high-tech manufacturing, but the same arguments are valid considering software delivery.  Shifting those developer FTE numbers from the New York or London rate to the Bangalore rate on a budget spreadsheet got the CFO excited, but hid the damage caused by dismantling a (possibly distributed) team knitted closely together by culture and shared goals.  It also massively underestimated the complexity of rebuilding “industrial commons” as a hybrid of internal/external capabilities. Executive strategist and ex-CIO Jack Santos remarks “When outsourcing first started, everyone knew it was human arbitrage, and like all forms of arbitrage, the numbers eventually even out.”

When Robert Hayes says:

A company's competitive advantage is rooted in things it can do (e.g. design, make, distribute, or market) that its competitors cannot do as well, if at all. As the number of these core capabilities decreases, the company's competitive vulnerability to those that are able to master the same capabilities goes up.

The key discipline he highlights the need for is portfolio management. Not all IT functions provide us with the same value. We need to treat them accordingly.

I’m with Nick Carr on the impossibility for sustained IT-derived competitive advantage.  With notable exceptions, running an IT shop does not give you that advantage.  Sure, grinding down the cost per claim in an insurance company is supported by IT automation, but really it’s having a more optimal business process that does it.  Data transmission arbitrage that once afforded the bulge-bracket investment banks an advantage in high-frequency trading is now available to all willing to pay the exchanges for co-location space. As Carr points out, an advantage based on infrastructure rapidly accrues to all.

Please do not misinterpret my message here. I’m no IT protectionist.  And I disagree with Robert Hayes fundamental thesis that by outsourcing enterprises are “simply cashing out their intellectual assets”.  With cloud computing, we have a chance to take an amazing step towards the industrialization of our profession, a transformation even, but only if we approach it with the right mindset.

1. Do we even know the cost of our existing infrastructure commons?  For example, do you know your internal cost per processor hour, storage size, or network bandwidth? What is the lifespan of an infrastructure investment? Or what does maintenance per function cost for your existing software?

2. Do we have an architecture that is flexible enough to withstand the elimination of boundaries?  Mike Rollings has just published (Burton Group clients-only) “Planning Considerations for Externalization in Cloud Computing” and discusses the implications of removing the location, perimeter and application container boundaries that have served us well in the pre-cloud era, but can no longer be assumed.

3. Do we have a mature enough solution delivery process that values transparency, and has the right blend of formal and informal governance?

4. Can you segment those core competencies from your commodity IT processes and infrastructure? Focusing internal talent and investment on those competencies will help maintain or regain competitiveness.

5. Are we correctly managing the expectations of what’s possible from current offerings?  Chris Howard on keeping our feet on the ground:

“Externalizing IT can be a means of driving down cost, but there is no guarantee. The same risks organizations experienced with past outsourcing, for example, still exist. Organizations that view externalization as a panacea will be sorely disappointed. Cloud and SaaS options are simply not mature enough (yet) to handle the scale and complexity of enterprise computing. Immature IT shops will not gain the benefits of externalization, but are likely to incur greater costs and complexity.”

Let’s do some planning first this time, to avoid another off-shoring fiasco.