IT Strategy

You are currently browsing the archive for the IT Strategy category.

With cloud computing, the world is not flat

2010/03/09 in Cloud & SaaS, IT Strategy by peg | Comments

Does location matter? Or, put another way, is the world no longer flat? Many cloud and SaaS providers work under the assumption that where we store data where it is most efficient from an application performance point of view, ignoring political considerations. This runs counter to many company and governments who care greatly where their data is stored. Have we entered a time where location does matter, not for technical reasons, but for political reasons? Is globalisation (as a political thing) finally starting to impact IT architecture and strategy?

Just who is taking your order?

Just who is taking your order?

Thomas Friedman’s book, The World is Flat, contained a number of stories which where real eye openers. The one I remember the most was the McDonald’s drive through. The idea was simple: once you’ve removed direct physical contact from the ordering process, then it’s more efficient to accept orders from a contact centre than from within the restaurant itself. We could event locate that contact centre in a cheaper geography such as another state, or even another country.

Telecommunications made the world flat, as cheap telecommunications allows us to locate work wherever it is cheapest. The opportunity for labour arbitrage this created drove offshoring through the late nineties and into the new millenium. Everything from call centres to tax returns and medical image diagnosis started to migrate to cheaper geographies. Competition to be the cheapest and most efficient service provider, rather than location, determines who does the work. The entire world would compete on a level playing field.

In the background, whilst this was happening, enterprise applications went from common to ubiquitous. Adoption was driven by the productivity benefits the applications brought, which started of as a source of differentiation, but has now become one of the many requirements of being in business. SaaS and cloud are the most recent step in this evolution, leveraging the global market to create solutions operating at such a massive scale that they can provide price points and service levels which are hard, if not impossible, for most companies to achieve internally.

The growth of the U.S. enterprise application market

The growth of the U.S. enterprise application market (via INPUT)

Despite the world being laser levelled within an inch of its life, many companies are finding it difficult to move their operations to the cost-effective nirvana that is cloud and SaaS services. Location matters, it seems. Not for technical reasons, but for political ones.

Where we store our assets is important. Organisations want to put their assets somewhere safe, because without assets these the organisations don’t amount to much. Companies want to keep their information — their confidential trade secrets — hidden from prying eyes. Governments need to ensure they have the trust of their citizens by respecting their privacy. (Not to mention the skullduggery this is international relations.) While communications technology has made it incredibly easy to move this information around and keep it secure, it has yet to solve the political problem of ensuring that we can trust the people responsible for safeguarding our assets. And all these applications we have created — both the traditional on-premesis, hosted or SaaS and cloud versions — are really just asset management tools.

We’re reached a point where one of the a larger hidden assumptions of enterprise applications has been exposed. Each application was designed to live and operate within a single organisation. This organisation might be a company, or it might be a country, or it might be some combination of the two. The application you select to manage your data determines the political boundary it lives within. If you use any U.S. SaaS or cloud solution provider to manage your data, then your data falls under U.S. judicial discovery laws, irregardless of where you yourself are located. If your data transits through the U.S., then assume that the U.S. government has a copy. The world might be flat, but where you store your assets and where you send them still matters.

Country-specific regulations governing privacy and data protection vary greatly.

Global data protection heat map (via Forrester)

We can already see some moves by the vendors to address this problem. Microsoft, for example, has developed a dedicated cloud for the U.S. government, known as BPOS Federal, which is designed to meet the government’s stringent security and privacy standards. Amazon has also taken a portion of the cloud it runs and dedicated it to, and located it in, the EU, for similar reasons.

If we consider enterprise applications to be asset management tools rather than productivity tools, then ideas like private clouds start to make a lot of sense. Cloud technology reifies a lot of the knowledge required to configure and manage a virtualised environment in software, eliminating the data centre voodoo and empowering the development teams to manage the solutions themselves. This makes cloud technology simply a better asset management tool, but we need to freedom to locate the data (and therefore the application) where it makes the most sense from an asset management point of view. Sometimes this might imply a large, location agnostic, public cloud. Other times it might require a much smaller private cloud located within a specific political boundary. (And the need to prevent some data even transiting through a few specific geographies – requiring us to move the code to the data, rather than the data to the code – might be the killer application that mobile agents have been waiting for.)

What we really need are meta-clouds: clouds created by aggregating a number of different clouds, just as the Internet is a network of separate networks. While the clouds would all be technically similar, each would be located in a different political geography. This might be inside vs. outside the organisation, or in different states, or even different countries. The data would be stored and maintained where it made the most sense from an asset management point of view, with few technical considerations, the meta-cloud providing a consistent approach to locating and moving our assets within and across individual clouds as we see fit.

Tags: , , , , , , , ,

One of the only two sources of sustainable competitive advantage available to us today

2010/02/19 in Business-Technology, IT Strategy, Posterous by peg | Comments

I stumbled onto a somewhat interesting post over at HBR, which talks Garry Kasparov’s ideas in the business world. This is actually quite a relevant pairing, though an old one in the tradition of human-computer augmentation.

The idea a simple one, which takes far fewer words to express than the article took.

Use information technology to augment users, rather than replace them.

IT is good at lot of tasks, and less good at others. People, too, have their strengths and weaknesses. What’s interesting is that computers are weak where people are strong, and vice-versa. Computers excel as appliers of algorithms with huge memories and an attention to detail; people are powerful, creative problem solvers who have trouble thinking of four things at once and like coffee breaks. Why not pair the two, and get the best of both worlds.

Rather than replace the users, why don’t we use technology to automate the easy (for technology) 80% of what they do. (This is something I’ve written about before.) In the chess example, the easy 80% is providing the user with a chess computer for the commoditized solution space search, allowing them to focus on strategy. The performance improvement this approach provides can create an significant competitive advantage. As Garry Kasparov found, even a weak user with a chess computer can be impossible to defeat, by human or computer.

This then provides us with two options:

  1. Take the improvement as a saving by reducing head count.
  2. Reinvest the improvement by providing our users with more time to focus on the hard 20%.

(I must admit, i much prefer the later.)

If we continue to focus on automating the next easy 80%, we’ve created a platform and process for continual business optimisation. (Improvements in search efficiency would simply be harvested when appropriate to maintain parity.) Interestingly, this is one of only two sources of a sustainable competitive advantage available to us today.

The competative advantage with this approach rests with the user, in the commonplaces, the strategies, they use to solve problems. By reifying the easy 80% these strategies in software (processes and rules) we are moving some of the competitive advantage into the organisation with it can leveraged by other users. By continually attacking the easy 80% of what the users are doing, we are continually improving our competitive position. We could even sell our IT platform (but not the reified problem solving strategies) to our competitors — commoditzing the platform to realise a cost saving — without endangering our competitive position, as they would need to go through the same improvement and learning process that we did, while we continue to race ahead.

Now that’s scary: as long as we keep improving our process, our competitors will never be able to catch us.

Posted via web from PEG @ Posterous

The benefits of SaaS (beyond low cost)

2010/02/10 in IT Strategy, Posterous by peg | Comments

I’ve already written about why I think private clouds can be a good idea. Similar arguments can be made for SaaS, and then some. A friend and I did the email-ping-pong thing and ended up with a (shortish) list of reasons why to go with a SaaS solution over an traditional on-premises solution.

  • OPEX rather than CAPEX cost. The CAPEX gulp is minimised, and the ongoing costs are tied to your own operational cost (head count, etc).
  • Faster provisioning. SaaS is can be up to 90% faster to deploy than on-premises solutions. (Weeks/months rather than months/years.)
  • No more upgrades. You’re always on the latest version, and new features are roll out organically rather than every few years as part of a change management process.
  • More focused vendor and community support. As there is only a single version in play, support efforts from the vendor and user community are focused on the version that you’re using. This also avoids the problem of getting left behind on a stale and unsupported platform (been there, done that, and have the scars to prove it).
  • SaaS provides a platform that scales organically with our organization. You’re not required to invest in additional hardware, software, and provisioning processes, letting your business focus on the business.
  • Reduced IT involvement. IT resources can focus on specific business problems rather than the care and feeding of the system.
  • Try before you buy. Instead of a traditional big license gulp at risk, sign up for a handful of SaaS seats for a few weeks and try it out. (From @shermo1.)

Any more?

Posted via web from PEG @ Posterous

Tags:

Private clouds are (not) the future

2010/01/29 in Cloud & SaaS, IT Strategy, Posterous by peg | Comments

Google (well, James Hamilton) has weighted in on the question of private clouds. As expected from a large cloud provider, James takes the position that private clouds make no sense. His reasoning is straight forward: private clouds will never have the scale of public clouds, therefore private clouds can never achieve the same price point as their public brethren. Ergo, there’s no point in building private clouds.

As I’ve pointed out before, there’s a lot more to cloud than simply reducing costs. The biggest benefit is probably the agility that cloud can bring to your IT estate, leveraging a cloud platform’s ability to codify and automate many of the management practices and create a target platform that can work across a range of deployment options, as well as streamlining hardware provisioning. Companies are also increasingly having to deal with the realities of political boundaries, a situation where the best technical solution might not be acceptable due to legal requirements (such as privacy legislation). Developing a private cloud can be a sensible move in this context.

Of course, if you want to compete purely on cost then private cloud will never hit the same price point as public cloud. But this misses the point that for many companies IT flexibility/agility is more important than cost.

Note: I was going to post this as a comment on James’ post, but comments appear to be broken.

Posted via web from PEG @ Posterous

Tags: , ,

Is “agile enterprise IT” an oxymoron?

2010/01/25 in Cloud & SaaS, IT Strategy, Mailing List by peg | Comments

Have we managed to design agility out of enterprise IT? Are the two now incompatible? Our decision to measure IT purely in terms of cost (ROI) or stability (SLAs) means that we have put aside other desirable characteristics like responsiveness, making our IT estates more like the lumbering airships of the 1920s. While efficient and reliable (once we got the hydrogen out of them), they are neither exciting or responsive to the business. The business ends up going elsewhere for their thrills. What to do?

LZ-127 Graf Zeppelin

LZ-127 Graf Zeppelin

An interesting post on jugaad over at the Capgemini CTO blog got me thinking. The tension between the managed chaos that jugaad seems to represent and the stability we strive for in IT seems to nicely capture the current tensions between business and IT. Business finds that opportunities are blinking in and out of existence faster than ever before, providing dramatically reduced windows of opportunity leaving IT departments unable to respond in time, prompting the business to look outside the organisation for solutions.

The first rule of CIOs is “you only have a seat at the strategy table if you’re keeping the lights on”. The pressure is on to keep the transactions flowing, and we spend a lot of time and money (usually the vast majority of our budget) ensuring that transactions do indeed flow. We often complain that our entire focus seems to be on cost and operations, when there is so much more we can bring to the leadership team. We forget that all departments labour under a similar rule, and all these rules are really just localised versions of a single overarching rule: the first rule of business, which is to be in business (i.e. remain solvent). Sales needs to sell, manufacturing needs to manufacture, … By devoting so much of our energy on cost and stability, we seems to have dug ourselves into a bit of a hole.

There’s another rule that I like to quote from time-to-time: management is not the art of making the perfect decision, but making a timely decision and then making it work. This seems to be something we’ve forgotten in the West, and particularly in IT. Perfection is an unattainable ideal in the real world, and agility requires a little chaos/instability. What’s interesting about jugaad is the concept’s ability to embrace the chaos required to succeed when resource constraints prevent you for using the perfect (or even simply the best) solution.

Vickers F.B. 5 Gunbus

Vickers F.B.5. Gunbus

Consider a fighter plane. The other day I was watching a documentary on the history of aircraft which showed how the evolution of fighters is a progression from stability to instability The first fighters (and we’re talking the start of WWI here–all fabric and glue) were designed to float above the battlefield where the pilots could shoot down at soldiers, or even lob bombs at them. They were designed to be very stable, so stable that the pilot could ignore the controls for a while and the plane would fly itself. Or you could shoot out most of the control surfaces and still land safely. (Sounds a bit like a modern, bullet proof, IT application, eh?)

The Red Baron: NAME

The Red Baron: Manfred von Richthofen

The problem with these planes is that they are very stable. It’s hard to make them turn and dance about, and this makes them easy to shoot down. They needed to be more agile, harder to shoot down, and the solution was to make them less stable. The result, by the end of WWI, was the fairly unstable tri-planes we associate with the Red Baron. Yes, this made them harder to fly, and even harder to land, but it also made them harder to hit.

Wizz forward to the modern day, and we find that all modern fighters are unstable by design. They’re so unstable that they’re unflyable without modern fly-by-wire systems. Forget about landing: you couldn’t even get them off the ground without their fancy control systems. The governance of the fly-by-wire systems lets the pilot control the uncontrollable.

The problem with modern IT is that it is too stable. Not the parts, the individual applications, but the IT estate as a whole. We’ve designed agility out of it, focusing on creating a stable and efficient platform for lobbing bombs onto the enemy below. This is great is the landscape below us doesn’t change, and the enemy promises not to move or shoot back, but not so good in today’s rapidly changing business environment. We need to be able to rapidly turn and dance about, both to dodge bullets and pounce on opportunities. We need some instability as instability means that we’re poised for change.

Jugaad points out that we need to allow in a bit of chaos if we want to bring the agility back in. The chaos jugaad provides is the instability we need. This will require us to update our governance processes, evolving them beyond simply being a tool to stop the bad happening, transforming governance into a tool for harvesting the jugaad where it occurs. After all, the role of enterprise IT is to capture good ideas and automate them, allowing them to be leveraged across the entire enterprise.

Managing chaos has become something of a science in the aircraft world. Tools like Energy-Maneuverability theory are used during aircraft design to make informed tradeoffs between weight, weapons load, amount of wing (i.e. ability to turn), and so on. This goes well beyond most efforts to map and score business processes, which is inherently a static pieces/parts and cost driven approach. Our focus should be on using different technologies and delivery approaches to modify how our IT estate responds to business change; optimising our IT estate’s dynamic, change-driven characteristics as well as its cost-driven static characteristics.

This might be the root of some of the problems we’re seeing between business and IT. IT’s tendency to measure value in terms of cost and/or stability leads us to create IT estates optimised for a static environment, which are at odds with the dynamic nature of the modern business environment. We should be focusing on the overall dynamic business performance of the IT estate, its energy-maneuverability profile.

Tags: , , , , , ,

Reducing costs is not the only benefit of cloud computing & SaaS

2010/01/12 in Cloud & SaaS, IT Strategy, Mailing List by peg | Comments

The wisdom of the crowd seems to have decided that both cloud computing and its sibling SaaS are cost plays. You engage a cloud or SaaS vendor to reduce costs, as their software utility has the scale to deliver the same functionality at a lower price point than you could do yourself.

I think this misses some of the potential benefits that these new delivery models can provide, from reducing your management overhead, allowing you to focus on more important or pressing problems, through to acting as a large flex resource or providing you with a testbed for innovation. In an environment where we’re all racing to keep up, the time and space we can create through intelligently leveraging cloud and SaaS solutions could provide us with the competitive advantage we need.

Sameul Insull

Could and SaaS are going to take over the world, or so I hear. And it increasingly looks that way, from Nicholas Carr’s entertaining stories about Sameul Insull through to Salesforce.com, Google and Amazon’s attempts to box-up SaaS and cloud for easy consumption. These companies massive economies of scale enable them to deliver commoditized functionality at a dramatically lower price point that most companies could achieve with even the best on-premises applications.

This simple fact causes many analysts to point out the folly of creating a private cloud. While a private cloud enables a company to avoid the security and ownership issues associated with a public service, they will never be able to realise the same economies of scale as their public brethren. It’s these economies of scale that enables companies like Google to devote significant time and effort into finding new and ever more creative techniques to extract every last drip of efficiency from their data centres, techniques which give them a competitive advantage.

I’ve always had problems with this point of view, as it ignores one important fact: a modern IT estate must deliver more than efficiency. Constant and dramatic business change means that our IT estate must be able to be rapidly reconfigured to support an ever evolving business environment. This might be as simple as scaling up and down, inline with changing transaction volumes, but it might also involve  rewriting business rules and processes as the organisation enters and leaves countries with differing regulation regimes, as well as adapting to mergers, acquisitions and divestments.

Once we look beyond cost, a few interesting potential uses for cloud and SaaS emerge.

First, we can use cloud as a tool to increase the flexibility of our IT estate. Using a standard cloud platform, such as an Amazon Machine Image, provides us with more deployment options than more traditional approaches. Development and testing can be streamlined, compressing development and testing time, while deployed applications can be migrated to the cloud instance which makes the most sense. We might choose to use public cloud for development and testing, while deploying to a private cloud under our own control to address privacy or political concerns. We might develop, test and deploy all into the public cloud. Or we might even use a hybrid strategy, retaining some business functionality in a private cloud, while using one or more public clouds as a flex resource to cope with peak loads.

Second, we can use cloud and SaaS as tools to increase the agility of our IT estate. By externalising the the management of our infrastructure (via cloud), or even the management of entire applications (via SaaS), we can create time and space to worry about more important problems. This enables us to focus on what needs to happen, rather than how to make it happen, and rely on the greater scale of our SaaS or cloud provider to respond more rapidly than we could if we were maintaining a traditional on-premises solution.

And finally, we can use cloud as the basis of an incubator strategy where an organisation may test a new idea using externalised resources, proving the business case before (potentially) moving to a more traditional internal deployment model.

One problem I’ve been thinking about recently is how to make our incredibly stable and reliable IT estates respond better to business change. Cloud and SaaS, with the ability to shape the flexibility and agility of our IT estate to meet what the business needs, might just be the tools we need to do this.

Tags: , , , , , , ,

The price of regret

2009/11/26 in Business-Technology, IT Strategy, Posterous by peg | Comments

I learnt a new term at lunch the other day: regret cost. Apparently this is the cost incurred to re-platform or replace a tactical solution when it can no longer scale to support current demand. If we’d just built the big one in the first place, then we wouldn’t need to write of the investment in the tactical solution. An investment we now regret, apparently.

This attitude completely misses the point. The art of business is not to take the time to make a perfect decision, but to make a timely decision and make it work. Business opportunities are often only accessible in a narrow time window. If we miss the window then we can’t harvest the opportunity, and we might as well have not bothered.

Building the big, scalable perfect solution in the first place might be more efficient from an engineering point of view.  However, if we make the delivery effort so large that we miss the window of opportunity, then we’ve just killed any chance of helping the business to capitalise on the opportunity. IT has positioned itself as department that says no, which does little to support a productive relationship with the business.

Size the solution to match the business opportunity, and accept that there may need to be some rework in the future. Make the potential need for rework clear to the business so that there are no surprises. Don’t use potential rework in the future as a reason to do nothing. Or to force approval of a strategic infrastructure project which will deliver sometime in the distant future, a future which may never come.

While rework is annoying and, in an ideal world, a cost to be avoided, sometimes the right thing to do is to build tactical solution that will need to be replaced. After all, the driver to replacing it is the value it’s generating for the business. What is there to regret? That we helped the business be successful? Or that we’re about to help the business be even more successful?

Posted via email from PEG @ Posterous

Tags: ,

The Value of Enterprise Architecture

2009/05/07 in Business-Technology, IT Strategy, Presentations by peg | Comments

Is Enterprise Architecture in danger of becoming irrelevant? And if so, what can we do about it?

Presented as part of RMIT’s Master of Technology (Enterprise Architecture) course.

The Value of Enterprise Architecture  

The Value of Enterprise Architecture

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,

Applications let us differentiate, not!

2009/02/15 in Business-Technology, IT Strategy, Mailing List by peg | Comments

Being involved in enterprise IT, we tend to think that the applications we build, install and maintain will provide a competitive advantage to the companies we work for.

Take Walmart, for example. During the early 80s, Walmart invested heavily in creating a data warehouse to help it analyze its end-to-end supply chain. The data was used to statically optimize Walmart’s supply chain, creating the most efficient, lowest cost supply chain in the world at the time. Half the savings were passed on to Walmart’s customers, half whet directly to the bottom line, and the rest is history. The IT asset, the data warehouse, enabled Walmart to differentiate, while the investment and time required to develop the data warehouse created a barrier to competition. Unfortunately this approach doesn’t work anymore.

Fast forward to the recent past. The market for enterprise applications has grown tremendously since Walmart first brought that data warehouse online. Today, applications providing solutions to most business problems are available from a range of vendors, and at a fraction of the cost required for the first bespoke solutions that blazed the enterprise application trail. Walmart even replaced that original bespoke supply chain data warehouse, which had become something of an expensive albatross, with an off-the-rack solution. How is it possible for enterprise applications to provide a competitive advantage if we’re all buying from the same vendors?

One argument is that differentiation rests in how we use enterprise applications, rather than in the applications themselves. Think of the manufacturing industries (to use a popular analogy at the moment). If two companies have access to identical factories, then they can still make different, and differentiated, products. Now think of enterprise applications as business process factories. Instead of turning out products, we use these factories to turn out business processes. These digital process factories are very flexible. Even if we all start with the same basic functionality, if I’m smarter at configuring the factory, then I’ll get ahead over time and create a competitive advantage.

This analogy is so general that it’s hard to disagree with. Yes, enterprise applications are (mostly) commodities so any differentiation they might provide now rests in how you use them. However, this is not a simple question of configuration and customization. The problem is a bit more nuanced than that.

Many companies make the mistake that customizing (code changes etc) their unique business processes into an application will provide them with a competitive advantage. Unfortunately the economics of the enterprise software market mean that they are more likely to have created an albatross for their enterprise, than provided a competitive advantage.

Applications are typically parameterized bespoke solutions. (Many of the early enterprise applications were bespoke COBOL solutions where some of the static information—from company name through shop floor configuration—has been pushed into databases as configuration parameters. ) The more configuration parameters provided by the vendor, the more you can bend the application to a shape that suits you.

Each of these configuration parameters requires and investment of time and effort to develop and maintain. They complicate the solution, pushing up its maintenance cost. This leads vendors to try and minimize the number of configuration points they provide to a set of points that will meet most, but not all customers’ needs. In practical terms, it is not possible to configure an application to let you differentiate in a meaningful way. The configuration space is simply too small.

Some companies resort to customizing the application—changing its code—to get their “IP” in. While this might give you a solution reflecting how your business runs today, every customization takes you further from a packaged solution (low cost, easy to maintain, relatively straight forward to upgrade …) and closer to a bespoke solution (high cost, expensive to maintain, difficult or impossible to upgrade). I’ve worked with a number of companies where an application is so heavily customized that it is impossible to deploy vendor patches and/or upgrades. The application that was supposed to help them differentiate had become an expensive burden.

Any advantage to be wrung from enterprise IT now comes from the gaps between applications, not from the applications themselves. Take supply chain for example. Most large businesses have deployed planning and supply chain management solutions, and have been on either the LEAN or Six Sigma journey. Configuring your planning solution slightly differently to your competitors is not going to provide much of an edge, as we’re all using the same algorithms, data models and planning drivers to operate our planning process.

Most of the potential for differentiation now lies with the messier parts of the process, such as exception management (the people who deal with stock-outs and lost or delayed shipments). If I can bring together a work environment that makes my exception managers more productive than yours—responding more rapidly and accurately to exceptions—then I’ve created a competitive advantage as my supply chain is now more agile than yours. If I can capture what it is that my exception managers do, their non-linear and creative problem solving process, automate it, and use this to create time and space for my exception managers to continuously improve how supply chain disruptions are handled, then I’ve created a sustainable competitive advantage. (This is why Enterprise 2.0 is so exciting, since a lot of this IP in this space is tacit information or collaboration.)

Simply configuring an application with today’s best practice—how your company currently does stuff—doesn’t cut it. You need to understand the synergies between your business and the technologies available, and find ways to exploit these synergies. The trick is to understand the 5% that really makes your company different, and then reconfiguring both the business and technology to amplify this advantage while commoditizing the other 95%. Rolls-Royce (appears to be) a great example of getting this right. Starting life as an manufacturer of aircraft engines, Rolls Royce has leveraged its deep understanding of how aircraft engines work (from design through operation and maintenance), reifying this knowledge in a business and IT estate that can provide clients with a service to keep their aircraft moving.

Tags: , , , , , , , , , , ,

Managing technology, not applications

2008/10/13 in Business-Technology, IT Strategy, Mailing List by peg | Comments

For some time we’ve been focused on the quest of slaying the business-technology alignment dragon. We don’t seem to have succeeded—at least not very often. Worse still, the rules of the game seem to be changing as we speak. Rather than manage IT as a large capital expense and asset, aligning business and IT by aligning investment, some companies are working to find and exploit the synergies between the two. Craig’s List is taking a significant chunk of the global classified advertisement market with a staff of 20 people, while Threadless is a case study of applying similar ideas to the old world business of designing, manufacturing and selling t-shirts. These organizations are so lean that they are virtually impossible to compete against.

How do they do it? What are the insights they are finding? Where are they finding them? And, most importantly, what can we learn from them? We’ve started this email as a platform to share some of our thinking. Hopefully this will provide inspiration for applying some ideas from these new school players thinking to our old school organizations.

Manage technology, not applications

We’re getting it all wrong—we focused on managing the technology delivery process rather than the technology itself. Where do business process outsourcing (BPO), software as a service (SaaS), Web 2.0 and partner organisations sit in our IT strategy? All too often we focus on the delivery of large IT assets into our enterprise, missing the opportunity to leverage leaner disruptive solutions that could provide a significantly better outcome for the business.

IT departments are, by tradition, inward looking asset management functions. Initially this was a response to the huge investment and effort required to operate early mainframe computers, while more recently it has been driven by the effort required to develop and maintain increasingly complex enterprise applications. We’ve organised our IT departments around the activities we see as key to being a successful asset manager: business analysis, software development & integration, infrastructure & facilities, and project or programme management. The result is a generation of IT departments closely aligned with the enterprise application development value-chain, as we focus on managing the delivery of large IT assets into the enterprise.

Building our IT departments as enterprise application factories has been very successful, but the maturation of applications over the last decade and recent emergence of approaches like SaaS means that it has some distinct limitations today. An IT department that defines itself in terms of managing the delivery of large technology assets tends to see a large technology asset as the solution to every problem. Want to support a new pricing strategy? Need to improve cross-sell and up-sell? Looking for ways to support the sales force while in the field? Upgrade to the latest and greatest CRM solution from your vendor of choice. The investment required is grossly out of proportion with the business benefit it will bring, making it difficult to engage with the rest of the business who view IT as a cost centre rather than an enabler.



Figure 1

Unfortunately the structure of many of our IT departments—optimised to create large IT assets—actively prohibits any other approach. More incremental or organic approaches to meeting business needs are stopped before they even get started, killed by an organisation structure and processes that impose more overhead than they can tolerate.

Applications were rare and expensive during most of enterprise IT’s history, but today they are plentiful and (comparativly) cheap. Software as a Service (SaaS) is also emerging to provide best of breed functionality but with a utillity delivery model; leveraging an externally managed service and paying per use, rather requiring capital investment in an IT asset to provide the service internally. Our focus is increasingly turned to ensuring that business processes and activities are supported with an appropriate level of technology, leveraging solutions from traditional enterprise applications through to SaaS, outsourced solutions or even bespoke elements where we see fit. We need to be focused on managing technology enablement, rather than IT assets, and many IT departments are responding to this by reorganising their operations to explore new strategies for managing IT.

Central to this new generation of IT departments is a sound understanding of how the business needs to operate—what it wants to be famous for. The old technology centric departmental roles are being deprecated, replaced with business centric roles. One strategy is to focus on Operational Excellence, Technology Enablement and Contract Management. A number of Chief Process Officer (CPO) roles are created as part of the Operational Excellence team, each focusing on optimising one or more end-to-end processes. The role is defined and measured by the business outcomes it will deliver rather than by the technology delivery process. CPOs are also integrating themselves with organisation wide business improvement and operational excellence initiatives, taking a proactive stance with the business instead of reactively waiting for the business to identify a need.



Figure 2

The Technology Enablement team works with Operational Excellence to deliver the right level of technology required to support the business. Where Operational Excellence looks out into the business to gain a better understanding of how the business functions, Technology Enablement looks out into the technology community to understand what technologies and approaches can be leveraged to create the most suitable solution. (As opposed to traditional, inward focused IT department concerned with developing and managing IT assets.) These solutions can range from SaaS through to BPO, AM (application management), custom development or traditional on-premises applications. However, the mix of solutions used will change over time as we move from today’s application centric enterprise IT to new process driven approaches. Solutions today are dominated by enterprise applications (most likely via BPO or AM), but increasingly shifting to utility models such as SaaS as these offerings mature.

Finally a contract management team is responsible for managing the contractual & financial obligations, and service level agreements between the organisation and suppliers.

One pronounced effect of a strongly business focused IT organisation is the externalisation of many asset management activities. Rather than trying to be good at everything needed to deliver a world class IT estate, and ending up beginning good at nothing, the department focuses its energies on only those activities that will have the greatest impact on the business. Other activities are supported by a broad partner ecosystem: systems integrators to install applications, outsourcers for application management and business process outsourcing, and so on. Rather than ramping up for a once-in-four-year application renewal—an infrequent task for which the department has trouble retaining expertise—the partner ecosystem ensures that the IT department has access to organisations whose core focus is installing and running applications, and have been solving this problem every year for the last four years.

This approach allows the IT department to concentrate on what really matters for the business to succeed. Its focus and expertise is firmly on the activities that will have the greatest impact on the business, while a broad partner ecosystem provides world class support for the activities that it cannot afford to develop world class expertise in. Rather than representing a cost centre in the business, the IT department can be seen as an enabler, working with other business to leverage new ideas and capabilities and drive the enterprise forward.

Tags: , , , , , , , , , , ,