Tactical Deployment and Strategic Planning

This article appeared as my column for Connect Magazine in March 2005.

One of the big complaints about enterprise applications has always been their large monolithic nature. Deploying these applications is so difficult that its the stuff of legend. Large businesses exist simply to integrate them into the enterprise and make them interoperate with legacy applications. When I was CIO for Utah, for example, we started a project to use SAPs payroll system. We had to hire Cedar to install and customize it for us.

One of the most visible developments in enterprise applications over the past few years has been on-demand applications like Salesforce.com. On-demand application vendors are sometimes called application service providers or ASPs. The great thing about on-demand applications is that they can be purchased and deployed tactically. An SVP of Sales with a corporate AMEX card can order up Salesforce.com on his lunch hour and have his team using it the next day--nothing to deploy and, more importantly, no painful interactions with the CIO.

Of course, the problem with the SVP of Sales just ordering in Salesforce.com over lunch is that while the deployment is easy, the planning isn't there. How will the on-demand sales automation application integrate with other enterprise processes? Well, the SVP of Sales probably doesnt care; she just wants her team to be more productive tomorrow instead of next year. But, pushed to its extreme, you end up with a hodgepodge of automated business processes that don't work together.

Enterprise applications like SAP, PeopleSoft, or Siebel, on the other hand, are strategic in nature. To deploy one, you have to plan (a lot), budget, initiate a project, and assign people. If you're successful (and I stress if), you will have automated major parts of your business, cut your operations costs, and increased your ability to monitor your critical business processes. On the other hand, you may have also just set in stone the business process that the SVP of Sales will want to change the week after the project ends. Most enterprise applications installations are so painful that the last thing you want to do once its over is change anything.

Right now, Salesforce and its competitors are a small part of overall enterprise application space. CIOs tend to view them with interest, but don't pay much attention to them. I think that's going to change. These on-demand applications are ignorable because, for the moment, they don't have the same functional footprint of large enterprise applications. They look like niche products solving niche problems. Make no mistake, however, that footprint will expand.

At the same time, enterprise applications vendors are providing Web services interfaces to smaller and smaller pieces of their applications. Consequently, these applications start to look like infrastructure. Some people are calling them "applistructure" because its the infrastructure that you build business applications on top of. Applistructure represents large chunks of business processes just waiting to be put together in interesting ways. At some point, on-demand applications and these Web-services front ends to enterprise applications start to look functionally interchangeable.

For this to work, CIOs have to start differentiating strategic planning from strategic deployment. Large monolithic enterprise applications are both strategically planned and strategically deployed. In reality, businesses ought to plan strategically and deploy tactically. Organizations should be able to create strategic plans that don't revolve around a deployment project. Many IT shops use system deployment as their chief organizing principle and that's a mistake; it usually doesn't serve the business.

As obvious as it sounds, IT shops need to plan around business needs. This is just another way of saying that IT organizations need strong enterprise architectures. Enterprise architectures provide a context within which various groups can quickly and flexibly deploy IT services. Done right, an enterprise architecture allows decentralization of the deployment without a concomitant degradation in interoperability. This creates a way for tactical deployments to be driven by strategic goals and the result is a more flexible IT organization that's aligned with business needs.

With an enterprise architecture in place, Web services make it possible for even very decentralized organizations to achieve high levels of interoperability. What's more, enterprise architectures provide a way to manage loosely coupled organizations so that overall business needs are met. Building an enterprise architecture isn't easy, but its the only way I know to give tactical deployments strategic context.

Phil Windley teaches Computer Science at Brigham Young University. Windley writes a weblog on enterprise computing at http://www.windley.com. Contact him at phil@windley.com

Last Modified: Tuesday, 04-Jan-2005 23:40:06 UTC