System Transformation Portal

How IT Can Meet Business-Driven IT Requirements

By William M. Ulrich

Few people would disagree with the premise that the role of IT is to meet the needs of the business units it serves. Historically, however, the ability of IT to deliver on priority business requirements has been hampered by organizational impediments, legacy environments and a lack of supporting business and IT infrastructure. Business and IT executives must establish a pragmatic roadmap that allows business unit and IT personnel to streamline efforts to deliver real value to the bottom line.

Do IT Projects Achieve Business Value?
IT is often saddled with numerous projects that have a tendency to start and stop based on shifts in budget allocations and IT management changes. IT projects, when viewed collectively, tend to be 80% tactical and 20% strategic in nature. A strategic project delivers significant and new business functionality while tactical projects apply small scale changes to existing application functionality, user interfaces and data. For example, a number of IT projects involve placing middleware between Web-based, front-end applications and backend, workhorse applications running on a mainframe or mid-range computing system. This is called non-invasive integration and is largely tactical in nature because it provides limited new functionality.

While �non-invasive� integration projects may meet an immediate need to establish Web-based access to small pieces of backend functionality, it is unlikely that the process of building thousands of middleware links is a key goal for senior executives. Non-invasive integration lays a patchwork of Web-based interfaces on top of legacy applications. Such an approach is a second generation attempt to �put lipstick on the proverbial bulldog�. In other words, the underlying inconsistencies, redundancies and segregated functionality in legacy application architectures remain entrenched beneath these Web-based front-ends.

In other situations, project teams are struggling to re-analyze relationships among legacy programs and data structures based on the need to maintain, enhance or in otherwise upgrade existing applications. While many of these projects are important, the lack of cross-reference information and documentation can add countless hours and risk factors to the analysis and testing phases of these projects. Application data and functionality tends to be redundant, inconsistent and superfluous and this can slow application upgrade projects to a crawl.

One response to the above predicament, common in periods of economic downturn, has been to outsource application support functions. While outsourcing can lower maintenance costs, it tends to focus on short-term cost savings while sacrificing opportunities to leverage legacy applications in strategic projects. When legacy applications are handed to a third party, in-house projects needing to upgrade those applications will be, to a great degree, stymied.

Consider, for example, externally-driven projects that include HIPPA compliance (healthcare), Uniform Product Code compliance (retail), Sarbanes-Oxley Bill compliance and other regulatory requirements will force IT to apply numerous changes to their data and applications. These projects demand cross-functional, business-driven understanding of legacy applications that most companies do not have in place today. Can these projects be completed overseas by companies that understand software but lack essential business knowledge? It is unlikely.

In addition to these immediate needs, companies will eventually need to retool and redeploy legacy functionality as business units continue to push for reduced redundancy, greater functional integration and improved flexibility from the legacy applications running beneath Web-based facades and middleware environments. Middleware, for example, cannot address the need to consolidate three billing units, related applications and databases.

A Roadmap to Meeting Business-Driven Requirements
A series of steps can be pursued to more readily allow IT to meet business-driven requirements. Being able to deliver business-driven initiatives requires that IT establish certain foundational capabilities as outlined in the points below.

1. Ensure that business units and IT teams are organized in a way that facilitates open and honest dialog. In the absence of collaborative business-IT teams, business requirements may not be effectively articulated, understood or acted upon. Establishing these teams may require the creation of non-hierarchical governance structures where applications personnel reside within the business units they support. Much has been written about IT-business unit alignment and practitioners should take care to pursue approaches that avoid superficial fixes such as rearranging boxes on the IT hierarchy chart.
   

2. Work with business units to establish a clear list of goals that can guide near-term and long-term IT projects. This should involve collaborative working sessions that are unconstrained by concerns over what can or cannot happen based on existing organizational, political or personnel constraints. This can be challenging and may require external facilitation. Open communications can also be constrained by outsourcing or other plans to move IT-related work into third party domains.
   

3. Inventory and examine all planned and ongoing IT projects and tie these projects back to specific business goals. Facilitating this process involves the use of an enterprise-wide project tracking facility to ensure projects are working towards common business goals and not at cross-purposes. If a project cannot be tied back to a specific business initiative, place it on hold until one can be identified. Exceptions to this rule involve infrastructure projects that establish architectures, tools or work environments through which IT can deliver projects more effectively and efficiently. For example, an application warehouse (see below) facilitates faster delivery of projects geared at upgrading legacy environments.
   

4. Business units should employ process modeling tools to streamline their ability to feed requirements to IT planning teams. Business units have had historic difficulties in communicating what they require from IT. At the same time, users need to address inefficient or redundant process flows across business units. One approach to address both of these issues is to deploy business processing modeling, integration and automation technology into the user environment. This brings immediate benefit to the user community because it helps automate manual processes and has the long-term effect of helping IT define integration requirements and identify limitations within current application architectures.
   

5. Ensure that a common architecture is in place to deploy future applications. For example, organizations should establish IT deployment architectures based on J2EE, .NET or some combination thereof. In addition, IT should leverage development processes to enable iterative development, component-based deployment, systemic reuse and, ultimately, Web services architecture. These factors help ensure that future applications are built and deployed in a way that avoids reintroducing the inherent inconsistencies, redundancies and functional segregation found in legacy applications. A first step in this process is to work with business units to help translate business process flows into IT-oriented specifications using modeling techniques such as the �Use Case� diagram.
   

6. Create an application warehouse using repository technology. An application warehouse would typically be developed in tiered layers. For example, a first cut, high level application warehouse would correlate business units, interfaces, applications, cross-functional data stores, supplier interfaces and user interface links to business processes. A second tier application warehouse, which is normally applied to a functional subset of the enterprise, cross-references all programs, interfaces, batch jobs, data stores, database definitions and related physical components. A second tier application warehouse would additionally include functional items such as business rule, entity, component and other items that would be useful in mapping portions of an application environment to target architectures. Such an application warehouse would additionally reflect middleware interfaces and adaptors used to facilitate non-invasive integration projects.
   

7. Establish a phased plan to reduce data and application redundancy to achieve real cost savings and revenue-based payback. Two factors present systemic roadblocks to meeting business-driven IT requirements. One is poor integration and interoperability while the second is redundancy and inconsistency across business data and application functionality. Addressing these issues must incorporate a related set of activities under a larger set of goals to streamline business delivery and overall agility.

The items in this roadmap build upon each other. For example, item #7 relies to some degree on each prior step to meet business-driven IT objectives. Unfortunately, current efforts to meet the requirements in item #7 have been limited to non-invasive integration - coupled with IT downsizing and outsourcing. These shortcut solutions will not deliver real value over the long-term.

It is important for executives to view each of the steps in this roadmap as a stepping stone of a more encompassing strategy to meet business-driven IT requirements in a more effective and efficient fashion. Such an approach must stand up to management changes as well as budgetary adjustments. To accomplish this, each task along with various sub-tasks within this roadmap must deliver interim value. This will ensure some degree of sustainability in case the overall effort is put on hold while more money is secured or incoming management is sold on the overall approach.

The greatest challenge to such a roadmap is the ability to fund and deliver infrastructure related tasks. Without solid approaches and related infrastructures to support business analysis and modeling, component deployment, reuse, legacy analysis and application retooling, meeting the needs of business units from an IT perspective will become increasingly difficult. Taking a holistic approach to such a strategy, however, will yield long-term benefits and deliver the bottom line value to the business.