Tag Archives: enterprise software

The rules of enterprise IT

As I’ve pointed out before (possibly as I’m quite fond of games{{1}}) the game of enterprise IT has a long an proud history. I’ve also pointed out that the rules of this game need to change if enterprise IT — as we know it — is to remain relevant in the future{{2}}. This is triggered a few interesting conversations at the pub on just what are the old rules of IT.

[[1]]Capitalise: A game for the whole company to play![[1]]
[[2]]People don’t like change. (Or do they?)[[2]]

Enterprise IT, as we know it today, is an asset management business, the bastard son of Henry Ford’s moving production line. Enterprise IT takes the raw material of business processes and technology and turns them into automated solutions. From those first card tabulators through to today’s enterprise applications, the focus has been on delivering large IT solutions into the business.

The rules of enterprise IT are the therefore rules of business operations. After a fair amount of coffee and beer with friends, the following 4 ± 2 rules seems to be a fair minimum set (in no particular order).

Keep the lights on. Or, put more gently, the ticket to the strategy table is a smooth running business. Business has become totally reliant on IT, while at the same time IT is still seen as something of a black art run by a collection of unapproachable high priests. The board might complain about the cost and pain of an ERP upgrade, but they know they have to find the money if they want to successfully close the books at the end of the financial year. While this means that the money will usually be found, it also means that the number one rule of being a CIO is to keep the transactions flowing. Orders must be taken, products shipped (or services provided), invoices sent and cash collected. IT is an operational essential, and any CIO who can’t be trusted to keep the lights on won’t even have time to warm up their seat.

Save money. IT started as a cost saving exercise: automatic tabulation machines to replace rooms full of people shuffling papers, networks to eliminate the need to truck paper from one place to another. From those first few systems through to today’s modern enterprise solutions, applications have been seen as a tool to save time and money. Understand what the business processes or problem is, and then support the heavy information lifting with technology to drive cost savings and reduce cycle time. Business cases are driven by ideas like ROI, capturing these savings over time. Keep pushing the bottom line down. These incremental savings can add up to significant changes, such as Dell’s make-to-order solution{{3}} which enabled the company to operate with negative working capital (ie. they took your cash before they needed to pay their suppliers), but the overall approach is still based on using IT to drive cost savings through the automation of predefined business processes.

[[3]]Dell’s make to order solution leaves competitors in the dust.[[3]]

Build what you need. When applications are rare, then building them is an engineering challenge. You can’t just go to the store and by the parts you need, you need to create a lot of the parts yourself in your own machine shop. I remember the large teams (compared to today) from the start of my career. A CORBA project didn’t just need a team to implement the business logic, it needed a large infrastructure team (security guy, transaction guy …) as well. Many organisations (and their strong desire to build – or at least heavily customise – solutions) still work under this assumption. IT was the department to marshal large engineering teams who deliver the industrial grade solutions which can form the backbone of a business.

Ferrero Rocher
Crunch on the outside, soft and chewy in the middle.

Keep the outside outside. It’s common to have what is called a Ferrero Rocher{{4}} approach to IT: crunchy on the outside while soft and chewy in the middle. This applies to both security and data management. We visualise a strong distinction between inside and outside the enterprise. Inside we have our data, processes and people. Outside is everyone else (including our customers and partners). We harvest data from our operations and inject it into business intelligence solutions to create insight (and drive operational savings). We trust whatever’s inside our four walls, while deploying significant security measures to keep the evil outside.


It’s a separate question of whether or not these rules are still relevant in an age when business cycles are measured in weeks rather than years, and SaaS and cloud computing are emerging as the dominate modes of software delivery.

Is the market for IT services and solutions shrinking or growing?

Here’s an interesting and topical question: is the market for enterprise IT services (SI, BPO, advisory et al) growing or shrinking? I’m doing the rounds at the moment to see where the market is going (a side effect of moving on), and different folk seems to have quite different views.

  • It’s shrinking as the new normal is squeezing budgets and OPEX is the new CAPEX.
  • It’s growing as companies are externalising more functions than ever before as they attempt to create a laser like focus on their core business.
  • It’s shrinking as the transition from on-premsis applications to SaaS implies a dramatic reduction (some folk are saying around 80-90%) in the effort required to deploy and maintain a solution.
  • It’s growing as the mid market is becoming a lot more sophisticated and starting to spend a lot more on enterprise software (witness Microsoft Dynamics huge market share).
  • It’s shrinking as SaaS is replacing BPO, in effect replacing people with cheaper software solutions? (Remember when TrueAdvantage, and Indian BPO, laid off all 150 of its workers after being purchased by InsideView?)
  • It’s growing as the need for more mobility solutions, and the massive growth in the mobile web, is driving us to create a new generation of enterprise solutions.
  • It’s shrinking as cloud computing and netbooks remove what little margin was left in infrastructure services.
  • It’s growing as investment in IT is a bit like gas, and tends to expand until it consumes all available funds. (Remember integration? As the cost of integration went down, we just found more integration projects to fill the gap.)

Like of a lot of these questions, it depends.

Update: Gartner finds that the worldwide IT services declined 5.3% last year, while Computer World UK tells us to expect another year of decline. How much of this is cyclic, and how much is due to a definition of “services” which could be more inclusive?

Updated: It appears that some organisations are not happy with the size and dominance of the IT services industry.

Balancing our two masters

We seem to be torn between two masters. On one hand we’re driven to renew our IT estate, consolidating solutions to deliver long term efficiency and cost savings. On the other hand, the business wants us to deliver new, end user functionality (new consumer kiosks, workforce automation and operational excellence solutions …) to support tactical needs. But how do we balance these conflicting demands, when our vertically integrated solutions tightly bind user interaction to the backend business systems and their multi-year life-cycle? We need to decouple the two, breaking the strong connection between business system and user interface. This will enable us to evolve them separately, delivering long term savings while meeting short term needs.

Business software’s proud history is the story of managing the things we know. From the first tabulation systems through enterprise applications to modern SaaS solutions, the majority of our efforts have been focused data: capturing or manufacturing facts, and pumping them around the enterprise.

We’ve become so adept at delivering these IT assets into the business, that most companies’ IT estates a populated with an overabundance of solutions. Many good solutions, some no so good, and many redundant or overlapping. Gardening our IT estate has become a major preoccupation, as we work to simplify and streamline our collection of applications to deliver cost savings and operational improvements. These efforts are often significant undertakings, with numbers like “5 years” and “$50 million” not uncommon.

While we’ve become quite sophisticated at delivering modular business functionality (via methods such as SOA), our approach to supporting users is still dominated by a focus on isolated solutions. Most user interfaces are slapped on as nearly an after thought, providing stakeholders with a means to interact with the vast, data processing monsters we create. Tightly coupled to the business system (or systems) they are deployed with, these user interfaces are restricted to evolving at a similar pace.

Business has changed while we’ve been honing our application development skills. What used to take years, now takes months, if not weeks. What used to make sense now seems confusing. Business is often left waiting while we catch up, working to improve our IT estate to the point that we can support their demands for new consumer kiosks, solutions to support operational excellence, and so on.

What was one problem has now become two. We solved the first order challenge of managing the vast volumes of data an enterprise contains, only to unearth a second challenge: delivering the right information, at the right time, to users so that they can make the best possible decision. Tying user interaction to the back end business systems forces our solutions for these two problems to evolve at a similar pace. If we break this connection, we can evolve users interfaces at a more rapid pace. A pace more in line with business demand.

We’ve been chipping away at this second problem for a quite a while. Our first green screen and client-server solutions were over taken from portals, which promised to solve the problem of swivel-chair integration. However, portals seem to be have been defeated by browser tabs. While these allowed us to bring together the screens from a collection of applications, providing a productivity boost by reducing the number of interfaces a user interacted with, it didn’t break the user interfaces explicit dependancy on the back end business systems.

We need to create a modular approach to composing new, task focused user interfaces, doing to user interfaces what SOA has done for back-end business functionality. The view users see should be focused on supporting the decision they are making. Data and function sourced from multiple back-end systems, broken into reusable modules and mashed together, creating an enterprise mash-up. A mashup spanning multiple screens to fuse both data and process.

Some users will find little need an enterprise mash-up—typically users who spend the vast majority of their time working within a single application. Others, who work between applications, will see a dramatic benefit. These users typically include the knowledge rich workers who drive the majority of value in a modern enterprise. These users are the logistics exception managers, who can make the difference between a “best of breed” supply chain and a category leading one. They are the call centre operators, whose focus should be on solving the caller’s problem, and not worrying about which backend system might have the data they need. Or they could be field personnel (sales, repairs …), working between a range of systems as they engage with you customer’s or repair your infrastructure.

By reducing the number of ancillary decisions required, and thereby reducing the number of mistakes made, enterprise mash-ups make knowledge workers more effective. By reducing the need to manually synchronise applications, copying data between them, we make them more efficient.

But more importantly, enterprise mash-ups enable us to decouple development of user interfaces from the evolution of the backend systems. This enables us to evolve the two at different rates, delivering long term savings while meeting short term need, and mitigating one of the biggest risks confronting IT departments today: the risk of becoming irrelevant to the business.

Applications let us differentiate, not!

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.