Stretching the IT dollar through business process differentiation

Depending on which research study you read, 50% – 80% of IT budgets go to sustain existing efforts which doesn’t leave much for new development. That has forced a significant level of pragmatism on the types of applications being developed. On top of scrutinizing application backlog, the use of SOA continues to evolve which means IT has to carefully think through both what to build and how to build it. For most organizations, initial uses for SOA were aimed at solving intra-enterprise integration challenges. Now the focus is beginning to shift from service enabling existing applications to developing new composite applications that meet specific business goals and also extend to the edge of the connected enterprise whether they run on the Internet, the plant floor, or from a mobile device.

 

A typical organization has two or three business processes that truly differentiate the business (core processes). The rest, while they may be mission critical, are functions that keep the lights on but don’t provide competitive advantage (commodity processes). For a retailer, having the right product on the shelf in the right store at the right time at the right price is the difference between success and failure. In IT, there is a temptation to automatically associate high availability demands (mission critical) with strategic importance. Keeping the AP / AR systems up and running is critical, but that is unlikely to define business success.

 

As IT organizations think about the limited amount of resources they can devote to new applications, it’s imperative that they invest in the processes that differentiate their business. Many organizations will find that those processes, their corporate secret sauce, are things that are inherently proprietary and will likely require a custom developed application. I would argue that Fed Ex™ differentiated itself early on through the real time tracking system. Their secret sauce (in addition to reliability) was giving customers web based visibility on a package’s progress. Since there was no off-the-shelf application for providing this functionality, it had to be built from the ground up.

 

Service Orientation has the promise of addressing a couple of key problems – development productivity (reducing backlog) and organizational agility (making IT more strategic). One additional benefit that could potentially be more important than the other two is the focus on model-driven implementation which forces much deeper knowledge of the application logic. What good is a core process if over time visibility into the workflow is lost?

 

A simple litmus test might to evaluate a few things and see where you score:

· What is the total spend on all applications that fall into “core” vs. spend on “commodity”?

· In the Application dev queue, what percentage of those applications are core vs. commodity?

· Does the organization think about the outsourcing model in two levels – relationship with vendors supplying “commodity: goods and services vs. the relationship with vendors that supply “core” goods and services?

Comments

• Anonymous
  June 11, 2007
  At TechEd last week, we spent a lot of time talking to Developers and IT Managers regarding the themes