IT Commandment: Thou shalt not confuse projects with planning

Deploying large enterprise applications is so difficult that it's become the stuff of legend. Their large monolithic nature makes for large monolithic projects.
Written by Phil Windley, Contributor

Deploying large enterprise applications is so difficult that it's become the stuff of legend. Their large monolithic nature makes for large monolithic projects. Large businesses exist simply to integrate them into the enterprise and make them interoperate with legacy applications.

IT Commandments Software as a Service (SaaS) is one of the most visible developments in enterprise applications over the past few years. On-demand applications like Salesforce.com can be purchased and deployed tactically. The same can be said of SOA deployments. Any individual service might be quite tactical in it's nature.

The problem with these kinds of tactical deployments is positioning them within the business' long-term plans. How will the SaaS application or SOA service integrate with other enterprise processes? In the long-term you could end up with a hodgepodge of automated business processes that don't work together.

In contrast, large enterprise applications like CRM and ERP 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.

To bring SaaS applications and SOA services into the fold, CIOs have to start differentiating strategic planning from strategic deployment. Large monolithic enterprise applications are both strategically planned and strategically deployed--often with much pain. Reducing that pain combines strategic planning with tactical deployment. Can your organizations create strategic plans that don't revolve around deployment projects? 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.

Enterprise architectures 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 it's the only way I know to give tactical deployments strategic context.

Our IT Commandments:
  1. Thou shalt not outsource mission critical functions
  2. Thou shalt not pretend
  3. Thou shalt honor and empower thy (Unix) sysadmins
  4. Thou shalt leave the ideology to someone else
  5. Thou shalt not confuse projects with planning
  6. Thou shalt not condemn departments doing their own IT
  7. Thou shalt put thy users first, above all else
  8. Thou shalt give something back to the community
  9. Thou shalt not use nonsecure protocols on thy network
  10. Thou shalt free thy content
  11. Thou shalt not ignore security risks when choosing platforms
  12. Thou shalt not fear change
  13. Thou shalt document all thy works
  14. Thou shalt loosely couple
Editorial standards