System Transformation Portal

Synchronize Rapid Response Projects with Architecture Transformation

By William M. Ulrich
Originally appeared in Cutter Consortium Executive Update September 2003

Users complain that IT responds too slowly to their most critical and urgent needs. IT tends to respond with high cost estimates, extended feasibility studies and multi-year delivery windows. In response, users have created their own solutions ranging from spreadsheets to quick and dirty applications. These short-term solutions, regardless of who has implemented them, tend to be poorly synchronized with IT sponsored, long-term architecture transformation projects  and this can hurt business performance.

Business users and IT professionals have good arguments on both sides of this issue. IT needs to look beyond the near-term so that legacy architectures can be more effectively consolidated and upgraded to meet growth in business demand and changing markets. This can distract IT from being able to respond to near-term options. Yet business units, particularly users on the front lines of the enterprise, have numerous ideas on how to gain better efficiencies in delivering more value to the customer, reducing costs and increasing revenues. 

So how do executives deal with this seemingly difficult challenge? Having a business-IT strategy that can be turned into a long-term plan of action is clearly one step. But IT must also offer rapid response teams to meet the critical demands facing users on a day-to-day basis and then leverage these projects into long-term opportunities wherever possible. This three-pronged strategy will allow IT to better synchronize its long-term project directions with more immediate needs of the business community. 

Get a Business-IT Strategy
The most important component of being able to tie rapid response efforts back to an overall IT strategy is to actually have a stated direction. This of course relies on having a business strategy and being able to turn this business strategy into a strategic direction for IT. Unfortunately, people tend to get in the way of achieving objectives in this area.

Business users and IT are frequently at odds with each other with neither side seeming to appreciate the challenges facing the other side. Addressing this challenge requires that business units articulate an overall strategy and share that strategy with IT. IT, in turn, must respond by setting an overall direction that meets these needs. For example, if a segment of the business is being deemphasized, there should be little effort on the part of IT to invest extensive time and resources into applications on that side of the business. Too often, however, IT is out of the loop on these issues. 

To truly understand what is needed on the front lines of the business, IT must embed analysts within various business units. Analysts in this situation would relocate to and work closely with users in the trenches. These business-IT analysts (note that the term "business" precedes the term "IT") are responsible for "getting under the covers" of business challenges and limitations. The requirements surfaced by these individuals must be fed back into the overall strategies being developed by centrally coordinated IT planning and architecture teams.

Central IT planning, based on decentralized input and ongoing feedback, meets two requirements. The first requirement is to obtain and synchronize input from front line users. This ensures that business issues most critical to people in the trenches are addressed in a meaningful way. The second requirement is to ensure that IT architecture teams understand where the business is going from the top. In this way, IT can ensure that mergers, acquisitions, new market entry and new product launches are reflected in near-term and long-term information architecture evolution. 

Deploy Coordinated Rapid Response Teams
Having a grand plan ensuring that IT drives application and data architectures, application packages, middleware, Web services and other areas in the right direction is only part of the puzzle. IT must still be responsive to opportunities to reduce costs and drive up revenues in business units today and this requires a rapid response capability. 

A rapid response capability is extremely important because much of what a business requires surfaces from these types of efforts. For example, one such project may eliminate a number of spreadsheets that business analysts developed to track sales trends. Legacy applications did not support this type of tracking and the IT organization was years away from delivering new system capabilities to address tracking data across disparate legacy applications. 

A rapid response project, in this example, would create a Web-based application with a common user front-end to capture legacy data, integrate it and present it in a way that satisfied a variety of users across a number of business areas. In doing so, hard to audit and even harder to manage spreadsheets could be eliminated from the equation. The resulting application incorporates multi-user requirements, streamlines sales trend tracking and provides a means for sales teams to more rapidly identify and close new sales prospects. 

The IT team in this scenario delivered a rapid application that eliminated laborious user tasks, brought greater efficiency to the sales team and allowed the business to capitalize on sales opportunities that might have otherwise been lost. IT has also increased its own standing within the business community by delivering near-term value to the bottom line. 

Use Rapid Response Projects as Transformation Baseline
If the above example was simply a dead end project that was to be later usurped by a large-scale transformation project, IT could still claim credit for providing short-term help to a credible business challenge. But such a project could also serve to highlight other opportunities that IT could leverage within the grander scheme of architectural evolution. 

Assume that the cross-functional application built in the prior example came into common use across several business units - some of which are redundant due to prior merger activity. The process of crafting this common front-end could provide IT with insights into how back-end legacy applications and databases may be brought into alignment with front line user requirements. When insights gained through user analysis and front-end development are coupled with the fact that IT planning teams were looking at a legacy architecture consolidation effort over the long-term, certain opportunities surfaced.

IT may discover, for example, that the needs of these business units are not as disparate as first thought. IT may also discover, through further analysis, that back-end application data and functionality could be segregated in a way that allows all relevant and affected business units to use the same system along with common data structures. In other words, IT may have found that a project could be launched to rationalize and merge sales data, consolidate common functions, isolate unique functions and create a common back-end along with new front-ends to complement the sales tracking front-end created earlier. 

This may sound a bit like the "tail wagging the dogļ" but it really embodies a grass roots approach to augmenting central IT strategies with the realities of the front-line business requirements. Coupling rapid response projects with long-term requirements allows IT to bring new levels of capability to front line users while incorporating new requirements and lessons learned into longer term architecture plans. This in turn builds business-IT partnerships that may not have existed in the past and ensures that everyone is moving in the same direction regarding IT's ability to deliver real value to the business bottom line.