Jeremy Petersen

Subscribe to Jeremy Petersen: eMailAlertsEmail Alerts
Get Jeremy Petersen: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn

Related Topics: CIO/CTO Update

CIO/CTO Update: Article

SOA, BPM, CEP: How to Get IT Budget in a Tight Environment

Focus on Driving Business Value

This article originally appeared in NOW Magazine, which retains all rights.

Follow the author at or

You’re in a squeeze. How things ultimately shake out is not relevant right now, because you need to act right now. Work still needs to get done, systems need to stay running, and you must continue to keep pace with your competitors.

The analysts are projecting enterprise IT spending in 2009 to range from minimal growth to declines. Yet companies should “not wait for signs of a return to growth to begin planning for business growth,” according to Gartner analysts at a recent symposium.

“Unlike the (days of the) era—where IT was perceived as wasteful—organisztions now view IT as a way to transform their businesses and adopt leaner operating models,” said Gartner analyst Peter Sondergaard. “IT leaders that are called on to reduce 2009 IT spending should do so in a way that will not impede the organization in the future.”

So IT budget is not going away. You know that you can still can get it. But how, and how much? What strategies and tactics can you take to get the IT budget you need in a tight environment?

Underlying any answers to these questions is the principle that solutions to the global economic mess must always, to some degree, return to IT.

It is IT that will bring efficiencies to your organization, and it is IT that will keep you in touch with customers, analyze their needs, and act upon those needs.

Examples spring to mind. Specific company names cannot be mentioned because companies are insanely protective of revealing their secrets to competitors—yes, IT does still matter.

But it is worth noting that over the past several months one can find documented evidence of achievements such as these two:

· A major tire manufacturer effected a 5% increase in sales simply by lowering its stockouts. This also produced a 20% reduction in inventory, and an increase of 22% in its service levels.

· A household goods conglomerate also focused on stockouts to bring enormous change to its supply chain costs. Invoice deductions fell 45%, products reached shelves more quickly. Now, 80% of company orders are automated through a new B2B purchasing process.

Additionally, you’ll find real-world anecdotes from a major entertainment CEO whose company can now “run promotions without having to retrofit everything,” a telco CIO who has built “a bridge between disconnected islands of information,” and another CIO from the transportation business who effectively tracks “hundreds of millions of shipment events as they move through our system.” Keep that word “events” in your mind; it will occur later in this article.

And never forget the quantum leaps that are always achievable even in tough economic times. Look to documented examples of trading analytics now being performed in 5 seconds, compared to 30 minutes in the past. Or 15-minute supply chain updates, compared to an industry norm of 1-day not so long ago.

Data warehouses are now being refreshed in a day instead of a month. And certainly you’re aware that new phones are now activated within the hour, rather than the days it (annoyingly) took in the past.

Is Architecture the Answer?
How do companies aim for dramatic results such as this? Because surely this is the way to keep the IT budget coming your way. One way to address the problem is through the archtectural approach.

The architect’s role in working with projects that span organizational silos is to stand back and look at the interplay among systems, information, business processes--and the people involved in them. Observing the interplay, a simple question arises: Do all of these pieces fit together smoothly and provide the solution that the business requires?

IT managers are often incentivized to deliver local optimization within their own particular silo. But an information architect must take the global view and strive for global optimization. To see across the silos, architects must therefore understand end-to-end processes and questions about these processes:

  • What does each silo involved in a particular business process need to do.
  • What changes need to be made on the development side?
  • What operational changes need to be made to execute the business process?


Yet none of this matters if architects lose focus on getting business value out of these processes. It means something like shrinking the timeframe for designing or changing a business process from weeks to hours. This sort of dramatic change requires improvements that impact multiple silos.

But it also requires a very clear, upfront understanding of what magnitude of improvement is desired or required. This may seem like an obvious point, but it is nevertheless one that is often overlooked.


As the prominent architect and book author Paul C. Brown has noted, “If you want a 5% improvement, just make people marginally more efficient and you’ve succeeded. If you want a 50% improvement, you better take half of the work that was formerly done by people and automate it. If you want a 95% improvement, you better be taking that formerly manual process and completely automate it, using people only for rare cases of exception handling.”

The high-level design (ie, the architecture) remains critical, to ensure that everyone is reading from the same, detailed playbook. Within that context, it is essential to take a real long look at automating processes.


The human touch will never disappear from successful businesses. As we sit here today, we can look back onto decades of research into computer cognition, artificial intelligence, expert systems, and all the utopian and dystopian scenarios envisioned by computers getting “smarter.”


But as the author Terry Winograd has noted recently, computers will never be committed to doing the right thing. Give it what you think is every possible option to provide a specific action while serving customers, there will always be some new contingency that only a human being can handle and will want to handle.

So the idea of process automation for customer service remains valid, as long as there are humans around to manage these systems and get involved directly when necessary.


Brown also advises architects to remain aware of “the spectrum from implementing raw functionality on one hand versus a fully fault-tolerant, high-availability solution on the other. The latter approach can cost 4X as much as simply delivering raw functionality, so it behooves organizations to be very clear where they want their costs to fall within that broad price range.”