Strategic Planning and Tactical Deployment in the Applistructure


One of the big complaints around 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, we started a project to put in SAPs payroll system. We had to hire Cedar to install and customize it for us.

Meanwhile, another development is enterprise applications is on-demand services like Salesforce.com. The great thing about on-demand applications is that they can be 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 interaction with the CIO.

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. Of course, if you're successful (and I stress if), you have automated major parts of your business, cut your operations costs, and increased your ability to monitor your business. You may have also just set in stone the business process that the SVP of Sales wants to change the week after the project ends.

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. To understand why, let me differentiate strategic planning from strategic deployment. Large monolithic enterprise applications are both strategically planned and strategically deployed. The problem with the SVP of Sales just ordering in Salesforce.com over lunch is that while the deployment is easy (call it tactical), the planning isn't there. Pushed to its extreme, you end up with a hodgepodge of automated business processes that don't work together.

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." This applistructure represents large chunks of business processes just waiting to be put together in interesting ways.

To make use of this applistructure, there are two things that have to happen. First, vendors need to create business models that allow smaller parts of their large applications to be heated up on demand. We also need to see an increase in the number of business processes that are available in the on-demand model. Right now, you're pretty much limited to salesforce automation, some call center services, and payroll. There will be more.

Second, and more importantly, organizations need to be able to create strategic plans for their business 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. 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.


Please leave comments using the Hypothes.is sidebar.

Last modified: Thu Oct 10 12:47:21 2019.