System Transformation Portal

By William M. Ulrich

Collaborative development is not just a catch phrase or fad, it is an essential shift in the way IT delivers value to a business. This shift is already underway. Information delivery cycles have been shrinking since businesses began rejecting seven-year projects that rarely finished on time and almost never delivered what was needed seven years later. Development has, by necessity, become iterative and, by definition, must be collaborative.

Corporate business requirements are driving companies to reevaluate and retool business processes, customer and supply chain relationships, and the information systems enabling these processes and relationships. External and internal business requirements have magnified corporate dependencies on critical information systems. Unfortunately, systems development environments and legacy architectures cannot support the growing demand for more flexible and agile information system solutions.

To address the need for more flexible and more responsive information systems, organizations need to establish a development environment that fuses business requirements, development activities, emerging technologies and legacy architectures. Synthesizing these diverse disciplines into information solutions requires collaboration among a wide variety of people. Companies that utilize collaborative development solutions will turn business requirements into operational applications more quickly and effectively than companies that do not utilize collaborative solutions. These applications enable business-to-business (B2B), business-to-consumer (B2C) and various internal IT initiatives.

Information management is at a critical crossroad. While business pressures to build better systems more quickly are growing, development environments, technology, processes, legacy integration and collaborative thinking have matured to a point where enterprises can meet these demands. This will only happen, however, if executives examine how to synthesize and focus the collective power of new technology, processes and skills on the challenges at hand.

This paper builds a case for collaborative development based on current business trends and requirements. It also outlines what businesses can do to leverage collaborative development to support critical business initiatives.

IT Challenges and Opportunities

Businesses are being confronted by tremendous challenges in managing information and harnessing new technology. At the same time, organizations are in a position to capitalize on significant opportunities in addressing those challenges. The challenges stem from business and technical issues that need to be addressed in a coordinated fashion and generally fall into the following categories.

1. Mergers, acquisitions, heightened customer expectations, supply and distribution chain integration, and other factors contribute to an environment where companies need to connect people, systems and data together in response to a myriad of business requirements.
2. Users and customers are no longer willing to wait years or even months to see results from IT projects. Business users want short-term results that conform to their requirements.
3. Replicated and fragmented legacy data structures slow deployment of new systems and frustrate customers who cannot get fast, accurate information from the systems that are supposed to be serving them.
4. Poorly integrated legacy application architectures contain many of the operational rules needed to support new systems integration and deployment. Unfortunately, these systems were written using coding languages, database management systems, TP monitors and control structures that are incompatible with modern development skills and technologies.
5. There is a shortage of technical skills needed to build scaleable Java, XML and HTML solutions. Many programmers are only familiar with legacy environments.
6. Business, IT and third party professionals lack the collaborative techniques and skills needed to develop collective solutions to these challenges in the timeframes required.

These challenges are not insurmountable. In fact, the solutions needed to address these issues are available to companies today if they are willing to take the initiative to turn these challenges into opportunities.

For example, heightened user and customer expectations could mean that business professionals are more prepared and willing to work with IT to meet these challenges. The fact that business units are no longer willing to wait for IT to spend three months building the perfect solution is likely to pressure IT into streamlining design, development and testing to accommodate changing requirements. Ultimately this will mean that more projects will be successful and that IT will build respect across functional business units.

Legacy challenges can also be viewed as opportunities. Analysts can analyze, consolidate and reuse legacy data structures using various technologies. Legacy systems are a rich source of business rules and ultimately reusable components that can be incorporated into new systems during the design and development process.

Executives can also address the IT skill shortage by integrating legacy systems into the development cycle. This can be accomplished by reusing extracted legacy business rules in component-based application architectures.

Finally, collaboration among business, IT and third party professionals has been long overdue. Working in teams, facilitated by collaborative development environments, allows business and IT professionals to deploy more effective and long lasting solutions within a variety of existing and future information systems.

Collaborative development environments offer companies a vehicle for responding to increased demands for flexible systems that deliver critical business functionality to internal and external users. In addition, the Web has transformed user and customer expectations, how they view information systems and the way in which IT delivers solutions to those users and customers.

Numerous external demands drive the business case for collaborative development. Distribution channels are shorter, suppliers are an integral part of most business models, competitors are cooperating through electronic exchanges and customers can more easily shift allegiance to the competition. These challenges must be addressed in significantly compressed timeframes � or revenues and profits could suffer. Clearly the business is driving the demand for new Web-based applications in timeframes that could not even have been imagined a few years ago.

In response to these challenges, businesses are revamping business processes, particularly where these processes extend into supply and distribution channels. This demand and response model is depicted in Figure 1. As analysts redesign and realign business processes, legacy systems can no longer support these processes. For example, a customer order triggers a series of end-to-end transactions including order processing, fulfillment, inventory adjustments, billing, shipping and collection functions.

Figure 1: External business demands drive the need for 
changes in business processes, systems & data.

Each of these processes relies on a variety of stovepipe applications and databases that were not collectively designed to function in a seamless, real-time manner or interface with transactions originating outside the legacy environment. To deliver business solutions in the face of these challenges, companies must build and deploy scaleable, enterprise class e-business applications and incorporate these systems into existing information architectures.

E-Business systems differ from traditional systems in several ways.

• E-business systems need to incorporate external supplier-, distributor- and customer-driven business processes. For example, as supply chain management shifts to third party consortia, many of the business processes and related system functions associated with tracking materials or products will move from an internal business unit into an outside consortium. E-business systems must be able to integrate with these external processes and systems.

• Customers, distributors, suppliers and competitors have heightened expectations for and visibility into the reliability and performance of e-business systems. A developer does not know who might be using an e-business system because such a system is accessible over the Internet. This undefined user base will have higher expectations because Internet use is ubiquitous and many of these users lack the workaround skills or patience found in users of more traditional in-house applications.

• E-business systems should leverage existing IT investments in data and application server technology. Because these new systems are rarely designed to stand alone, integration is a must. Integration includes the capability to access legacy data stores and utilize application server features such as configuration control, logging, security and other services.

• E-business systems must integrate a multitude of diverse, internal business processes as well as the data supporting these processes. Because e-business systems automate business functions that cross a multitude of business functions, these systems must integrate with business processes across a variety of functional areas.

• E-business systems must access, invoke and integrate disparate transactions from a variety of in-house, legacy applications. Legacy applications, the vast majority of which are defined in non-Java languages and environments, must be incorporated into e-business systems because these systems still automate most of a given corporation�s business rules.

• E-business systems must be implemented in a fraction of the time allowed for past projects. Today, users are much less tolerant of long delays between business requests and the delivery of a system. Delivery window expectations have shrunk from years to weeks.

• Users require e-business systems on demand, yet usage patterns are unpredictable. Users dictate usage patterns. Not knowing who is ultimately accessing an e-business system means that usage patterns cannot be predicted. Unanticipated high volume usage could stress a system beyond the system�s capability to respond.

Organizations rushing to deliver e-business systems in constrained timeframes and environments have a tendency to shortcut business requirements and systems design activities. Attempting to expedite project deadlines by compromising analysis and design specifications can be extremely costly to a business. Poor requirements and specifications definition can actually extend the time it takes to deliver an acceptable system to the business community.

Research supports this assertion. A study by Barry Boehm at companies that included IBM, GTE and TRW demonstrated the high cost of letting problems slip through the requirements and design phases of a project. As shown in Figure 2, the relative cost of fixing system errors in latter phases of a project was quite a bit higher than fixing those same errors at the requirements and design phases of a project.

Figure 2: Relative Cost to Fix an Error in Development Cycle

Restating these numbers in dollars underscores the implications of these findings. Assume that a requirements analysis error takes a business analyst an hour to fix and costs $500. Finding and correcting that same error after the system goes into operation would cost between $20,000 to $500,000. These costs are likely to be understated because Boehm only studied finished projects and did not consider the roughly one-third of projects never completed. Poorly stated requirement and design specifications would have been even more costly within these cancelled projects.

Similarly, the effort needed to fix a $500,000 problem would consume more time and resources than the effort needed to correct a $500 problem much earlier in a project�s life cycle. This study demonstrates that requirements and design shortcuts only serve to draw out delivery timeframes and increase related costs.

The e-business challenge, simply stated, requires organizations to develop systems faster and more effectively than ever before, while incorporating continuously shifting business requirements from a wide variety of users inside and outside the enterprise. A collaborative development environment allows a company to meet this challenge.

Essential Elements of Collaborative Development

Collaborative development blends technology, people, processes and strategy to create an environment in which systems are delivered, upgraded and managed in reduced timeframes and with better results than has historically been the case.

A collaborative development environment combines and leverages teams, processes, component-based architectures, development environments and technologies, legacy applications and data, infrastructure management and external resources to meet business goals. Essential elements of collaborative development are summarized below.

Collaborative Team Structure
Blending business unit, IT and third party professionals to effectively meet the goals of a specific project or ongoing information initiative is at the heart of a collaborative development strategy. Collaborative teams make the technology work, but are also enabled by the technology. Management will need to focus on collaboration as a key element of delivering quality systems in constrained delivery windows. 

Process Definition & Deployment
Processes must be agile yet incorporate enough rigor to provide guidance to business and IT design and development teams to ensure that essential tasks have been included in a given project. Process definition and deployment should be integrated into development technology and provide guidance to participants throughout a project life cycle. 

Component-Based Architectures
Components are self-contained units of software that consist of its own data (or state) and logic (code). Components have well-defined connection points within a component framework and are designed for reuse across an information environment. A component architecture describes the major components within an environment and defines relationships among components.

Application Development Environment & Technologies
Various development technologies support different phases of the systems development and management life cycle. These technologies should share information in a way that enriches the contribution of each technological offering. An application development environment facilitates information sharing among business users and IT. Such an environment integrates various development technologies while providing a useful development interface for different user classes.

Legacy Application Extension
Most companies have a large legacy application portfolio containing millions of lines of code. These same companies also use Java, XML, application servers, Web Services and component-based development environments for new development. The science of connecting these environments has been limited to integration products that allow e-business systems to trigger back-end transactions. To respond to critical business requirements, collaborative development must go beyond back-end integration and address legacy issues at the design stage. 

Data Integration
Accessing and integrating corporate data structures into newly deployed systems is a continuing challenge for most organizations. Data integration is an essential element of collaborative development because it cuts to the heart of numerous business challenges. Data integration should be incorporated into requirements and design discussions early in the development cycle. 

Architecture Management
Few companies have a long history in managing component-based architectures. In fact, the track record for establishing and managing reuse in general is not a good one for most IT organizations. Collaborative development requires architecture management to incorporate reuse, new architectures, development technologies and legacy integration on a large scale.

External Resource Utilization
Companies need to interface with external resources including outsourced or application service provider (ASP) applications. Development teams are also beginning to access Web Services to incorporate portable components into in-house applications. Collaborative development becomes even more important when internal business and IT units need to integrate and coordinate with external entities.

Collaborative Environment: Synthesizing the Parts
Collectively, each of the above topics must come together to embody a collaborative development environment that leverages the strengths of people, processes, legacy applications and data, new architectures and technology, and external resources. It is important to view collaborative development from a big picture perspective where the collective value of each of these elements combines to deliver critical business functionality when and where it is needed most.

Business, IT and third party professionals should consider better ways to collaborate in order to streamline the development cycle and increase the quality of application systems. Development environments enable information exchange between business and IT, but communication and collaboration is ultimately a people issue.

Senior IT executives should work with business executives to develop a shared vision of the importance of collaborative, cross-disciplinary business, IT and third party teams. Instead of launching a reorganization effort, executives should charter business and IT managers, analysts and technicians with the responsibility of forming teams needed to meet high-priority information requirements.

The demand for new processes, new business functionality in automated systems, improved access to legacy data and an increased dependence on technology mean that business executives are likely to be more amenable to cooperating to accomplish these goals. IT must leverage this as an opportunity to change how business professionals perceive IT in delivering value to the business by creating new business opportunities, streamlining costs or helping deliver business strategies. 

Who should be on a Collaborative Team?
Teams can be project focused or revolve around an ongoing infrastructure support initiative � such as architecture management. Infrastructure support functions should not be left out of the team building process. 

Collaborative project teams can be built around new projects or projects in process. Projects focusing on new systems requirements are an ideal starting point for launching a collaborative team-building effort because these projects begin with a fresh set of participants with high morale and a clean slate. 

Existing projects can also benefit from collaborative team-building exercises. Numerous projects are in trouble because they lost their focus or never established their primary purpose. Taking time to refocus and rebuild relationships will help get projects back on track � or uncover deeper issues behind why the project is in trouble.

Infrastructure teams, which include architecture groups, technical support functions and a wide variety of other areas, will find it useful to undergo team-building exercises as well. Participants, managers and entire teams may find that they might be better organized in different ways based on group review and the motivation to self-organize � with management oversight.

Building Collaborative Teams
Individuals chartered with building collaborative teams will need to educate and motivate business executives, management and analysts into working as a team. Various ways to improve communication and collaboration include situating IT personnel in applicable business units, employing outside facilitators, creating social time so teams can get to know each other and holding off-site working sessions. Management should encourage project teams to experiment with ways to improve collaboration among teams focused on delivering information solutions.

Off-site working sessions let teams self-organize away from day-to-day pressures. For example, a development team could spend two days off-site to clarify their purpose and build relationships. People could share what they believe is the most important factor in making the project a success. The team would then draft a set of operating principles based on these success factors to guide ongoing project activities.

A typical project purpose might be to "Create an e-business system that consolidates customer data into a single invoice that can be accessed by customers through the Internet." A sample principle might say "All project requirements, designs, plans and results can be viewed by any project participant at any time."

Teams should determine what works best for them. Management should not impose their view of collaboration on the team. Forced collaboration is counter to the underlying intentions of collaborative development. Teams should be encouraged to share success stories with other teams. Team formation and creating a shared purpose are fundamental elements of collaboration and can be enhanced dramatically through collaborative processes and technology.

To systems developers the term "methodology" can conjure up images of form-filled, multi-step procedure guides or on-line manuals. These old-style methodologies can elongate development projects and have therefore been abandoned by many companies. In abandoning methods in general, however, development teams have sacrificed the degree of rigor needed to keep projects in line with their essential purpose.

Business and IT design and development teams still require an appropriate degree of rigor to ensure that critical steps are taken at the appropriate stages of the development cycle. This includes identifying certain deliverables for the analysis, design, coding, testing and deployment phases of the project. Infrastructure teams should ensure that basic processes are defined, incorporated into the development cycle and deployed within an automated development environment.

Figure 3 lists a set of principles drafted by the Agile Alliance, a group of methodologists who promote minimal degrees of rigor to keep projects on track. Under these principles, which apply to a variety of different types of processes depending on the project and environment, customers receive ongoing value in the form of functioning systems delivered over interim periods of time. Managers focus on enabling teams to deliver quality software for indefinite periods of time. The team focuses on technical excellence, avoiding unproductive activities and delivering quality work.

Figure 3: Agile alliance principles - 4/1/2001

One example of an agile process is called extreme programming, which focuses on accelerating up front design activity and spreading design work throughout the development cycle. This approach reduces the time in which it takes a development team to move from the design phase into a functioning system.

Another technique applied in extreme programming is to perform tasks concurrently whenever possible. For example, if part of the business design has been completed, developers may begin implementing the system while fleshing out additional business requirements in other areas.

Another extreme programming concept is "pairs programming" where programmers work as two person teams. While this concept may appear to be counterproductive on the surface, it eliminates the need for post-development code reviews � a process that has always had questionable value, even when it was actually employed. Pairs programming also allows strong technical talent to transfer skills to more junior personnel and works based on the idea that two heads are better than one. This approach catches errors during the coding cycle and allows for a broader range of implementation techniques.

Iterative development is a particularly important concept for development teams trying to remain as agile as possible. Under iterative development, a system sub-function is created, tested and delivered to a business user. Additional system sub-functions are added on an ongoing basis. Changes to previously implemented sub-function designs are called refactoring. There is no such thing as "scope creep" because scope is set in increments that can be implemented in a period of weeks. Changes in requirements are an accepted and even welcome part of this process.

One of the biggest conceptual shifts in extreme programming is the idea that testing is performed throughout the development cycle and not at the end. One precept is that a line of code is not developed unless a test case has been written for the function being automated by that line of code. Spreading out the testing process increases the stability of the resulting application system by catching errors early in the cycle.

Another concept involves separating the development process from the runtime environment. This avoids having to retrain people in multiple operating systems, hardware or application servers, maintains development process consistency and productivity, and leverages personnel across multiple projects.

Extreme programming and other agile processes must be deployed under a larger framework to ensure that certain protocols are followed based on standards set by architecture groups and other infrastructure teams. This ensures that disparate development teams conform to corporate data models, language guidelines, data exchange formats, hardware platforms and other architecture requirements.

Development processes must by definition be agile enough to be deliver value to customers on an ongoing basis, be accepted by development teams, provide enough rigor to keep projects on track and be incorporated into automated development environments and technologies.

As defined earlier, components are reusable system or business functions that developers can use to reduce the time it takes to create or upgrade application systems. Because reuse shortens the development process over handcrafted systems, designers and developers should focus on reuse whenever possible. The concept of reuse is definitely appealing to companies as Web-based development increases.

Due to the diversity of users and the newness of Web-based environments, e-business systems are the target of constant change. Handcrafted systems with long development lead-times must give way to component-based development in which developers assemble and upgrade systems from reusable components. An enterprise component architecture facilitates component reuse, a concept that is emphasized throughout the development cycle. A developer must first seek out existing components for reuse and only build new components if no existing component conforms to the design specifications.

The benefits of component reuse are considerable. Not having to create basic security, data access, configuration or other housekeeping functions saves programmers from spending time on menial tasks. When reuse concepts are extended to components that perform business functions, development teams can derive even greater value from component-based architectures.

If one development team in one business unit creates order processing components, a second business unit requiring those same functions should reuse as many components as possible. This allows order processing functions to be implemented consistently across business units, reduces initial development time and ensures that maintenance changes to these order processing routines are reflected across all the business units that utilize that functionality.

Another major benefit of component reuse is that it allows non-Java or legacy programmers to derive and then assemble components into applications. This capability expands the resource pool of available programmers capable of assembling e-business systems. Extending the technical resource pool across a broader range of developers is a capability that is obtainable when companies manage components effectively and broadens the range of sources from which components may be obtained or derived.

Component Management
Components are stored in component containers, which would be deployed via an application server under various component technologies. For example, an Enterprise Java Bean (EJB) is a component-based application server. Such servers provide support for a distributed component model by providing utility components and making it easier for a developer to understand and access components during the development and upgrade process.

In general, client components support interfaces and server components support business functions. Client components address visual presentation, user input and output, and any localize functionality. From an enterprise perspective, client components can be downloaded to the desktop system as required by an application. Security is one feature supported at the client level.

Server components can be viewed from the perspective of the container storing them, the business logic they perform or how they are packaged. Developers are most concerned with the business logic a component performs so that they can gain the greatest benefit from reusable functionality across the development environment.

Component management is accomplished through application servers, which includes container management and deployment support. An organization employing component-based development must be careful to take the time to define and deploy a component management environment.

Components Sources & Collaboration
Components can be obtained from an application server, accessed via Web Services, developed by Java programmers or derived from legacy environments. Application servers typically deliver basic system functions as described earlier. Web Services involve the concept of accessing remote components from third parties to build or upgrade in-house applications. Web Services provide small chunks of reusable code, use XML messaging facilities and are highly useful when developers require industry standard components that perform functions such as currency translation, geographic calculations or other functions that are universally consistent.

Programmers can create new components, but should do so only after ensuring that a component does not already exist to perform that same function. A rich source of business logic is embedded within legacy systems. Deriving legacy-based components is discussed in greater depth later in this paper.

With the diversity of components and component sources available to development teams, it is important for these teams to work together and with central architecture teams to derive the greatest advantages from component reuse. For example, if one development team has already gone through the effort to build customer billing functions, another development team should note replicate this process. Component-based architectures are valuable because of the concept of reuse and if reuse is not achieved then the value is blunted.

Collaboration is a major requirement here because development teams must share the collective knowledge of component availability. Application servers assist with this process, but it is up to development and infrastructure teams to ensure that the value of component-based architectures is evenly distributed across the development environment.

An application development environment synchronizes e-business design, development and deployment activities across a spectrum of business users, analysts, third parties, designers, developers and implementation personnel. Synchronization of development activities helps ensure that businesses get what they want from IT and is an outgrowth of collaboration.

A process-enabled application development environment provides access to design and development products, component libraries and external resources. This environment, depicted in Figure 4, enables individuals, with proper clearance, to visualize task flow and readily exchange project deliverables across the systems development and management life cycle.

Figure 4: Application development environments allow users
 and IT to share information across development cycle.

When users, developers and third parties openly communicate and share information through such an environment, it results in a highly streamlined development process that retains the integrity of business requirements through the implementation phase of the life cycle.

Development project information includes business models, design specifications, test plans, code, test results, integration plans and implementation results. This information may be shared within a project team, which includes business participants, or across project teams depending on what a given team is trying to accomplish.

Sharing information within a single project team for a development project facilitates the iterative development concept promoted in extreme programming. Business analysts can specify requirements using the Unified Modeling Language (UML) and send these over to the design team. The design team could review these requirements and draft a quick set of designs and test plans to communicate how they would envision implementing those requirements. User analysts could then review and comment on these designs and send them back to the design team.

The design team would submit these designs to developers and the developers could concurrently share their comments with the designers and the users. This process would continue through the coding, testing and implementation phases of the project. Under this scenario, none of the participants is ever out of the loop as the system evolves through a series of iterative interactions among users, designers and developers.

Putting more information into the hands of developers allows them to analyze requirements more effectively and save a good deal of development time by catching errors during development phase of a project, prior to entering production.

Sharing this same type of information across multiple design and development teams has added benefits. For example, one project team might have a dependency on work being done by a second project team. This is not uncommon in large IT environments, but many times developers are too busy to share detailed project status and related information across business units.

If the first project team points the second project team to their requirements, specifications, data models, component strategy, test plans, code and test results, the second team could garner enough information to synchronize development activities. This approach also works in scenarios where a large development team has been broken into sub-teams based on project functions and sub-functions. Under this scenario, users, designers, developers and managers could examine the work being done at each stage of one or more parallel sub-projects.

Because these technologies function in Web-based environments, these teams can be virtually aligned and include external resources as well as internal participants across geographic locations. This type of environment facilitates scaleable collaboration within and among teams.

Application Development Technologies
A variety of development technologies facilitate the efforts of designers and developers within an application development environment. These technologies support the creation and deployment of large-scale, component-based applications and include business specification, application and data design, programming, code generation, testing and various integration solutions.

Requirements specification technology allows business analysts to communicate with design teams in a way that is more succinct and less ambiguous than has historically been the case. UML, for example, facilitates the creation of business requirements in a neutral format that can then be shared with design teams.

Design specifications take the form of data models, design templates, system flow diagrams and program specifications. Designers should have the capability to develop various designs, employ design templates where applicable and share these designs with business users and developers. Designs may also be passed to code generation facilities to ensure that the code resulting from these designs reflects the integrity and intent of those designs.

Certain products support the assembling of components from various environments across an enterprise. This ensures that components being integrated into an application are identified and consolidated in an efficient manner. Component assembly is an important element in projects where reuse opportunities can be derived from a variety of component sources.

Application development technologies include editors, code generators and interactive debugging products for languages such as Java, XML, HTML and other modern languages as well as for various legacy languages. Code generation technology works by interpreting design models and creating code that is meets the specifications set forth in the design.

One important aspect of an integrated set of application development products is the ability to populate design changes into code and code modifications back into design specifications. This capability is called "synchronized development" and allows business requirements to remain synchronized with application designs and systems throughout the development and maintenance cycle.

Testing products support the tracking of activities during the actual execution of an application and facilitate tracing problems within a system or a component. Other products support change control tracking and application asset management.

The ability to integrate development technologies under an application development environment is very important for development teams who have a strong commitment to the collaborative development process.

Legacy Application Extension

In a typical company, legacy systems represent tens of millions of lines of code with a replacement value in the billions of dollars. A legacy system is any technology that has evolved over the past 50 years and manages information in a production environment. This includes systems built using Cobol, Fortran, Assembler, C, C++, Java, 4^th generation languages, screen-scraping technology, middleware or other development software. Worldwide, there are more than 180 billion lines of Cobol code alone according to Gartner Group.

These systems are essential to the success of any enterprise with a major investment in legacy applications. At the same time, these companies need to develop new Web-based applications to support e-business and related initiatives. These new applications invariably require access to legacy data and operational business logic. According to Gartner Group, 80% of application development projects over the next three years will include legacy extensions.

New development projects must leverage valuable legacy business rules in new development initiatives to ensure that strategic systems meet ongoing business environments in less time than it would take to recreate those rules from scratch.

One common approach for leveraging legacy applications in e-business projects uses enterprise application integration (EAI) technology to trigger back-end transactions. This approach addresses integration after the fact, segregates new systems from legacy environments and does not promote reuse. EAI also hinders long-term, large-scale upgrade options to new e-business systems and back-end environments.

A better way to integrate new applications with legacy systems is to address reuse during the design and development cycle. Legacy systems offer a rich source of untapped business rules that can be componentized and reused in the development and deployment of new systems. Some people have argued that legacy business rules do not apply to new e-business requirements. This is a major misconception.

While many legacy systems do not support cross-functional access to stovepipe data and transaction-based environments, they still contain much of the business logic needed to enable high volume, scaleable e-business transactions. Redeploying legacy business rules into a component-based architecture addresses these concerns.

Using legacy systems as a source of reusable components reduces development time by avoiding business rule re-specification and reduces replication of operational systems functionality. Legacy reuse also facilitates the redeployment of programming professionals not trained in Java to e-business projects. As with other aspects of collaborative development, legacy reuse needs to be planned and coordinated throughout the development cycle.

Legacy Business Rule Componentization
Legacy systems componentization involves decomposing systems into business functions and sub-functions and extracting selected business rules from those systems. Analysts can then categorize extracted rules, reconcile redundancies and compile them into components for use by development teams. The capability to compile Cobol code to run as an EJB component is available today, which means that core business functionality can be incorporated into strategic applications. For purposes of legacy business rule extraction, the following definition of a business rule applies.

A business rule is a combination of conditional and imperative logic that changes the state of a business object or data element.

Only about 20% of the source code in a given system can be considered business logic. The remaining code deals with the physical constraints of the environment. This is the main reason that wholesale migration of entire systems into Java is ill advised. Selected reuse of business rules, however, can yield highly productive results and involves the following steps.

1. Identify the types of business functions of interest.
2. Identify where these functions exist in various legacy systems.
3. Decompose these functions into sub-functions.
4. Identify the source code of interest.
5. Disregard irrelevant implementation dependent logic.
6. Extract selected business rules based on the functional criteria for the new system.
7. Consolidate redundant rules and eliminate discrepancies between these redundant rules.
8. Compile the legacy code into reusable components.

Legacy systems componentization repackages embedded systems intelligence allowing new systems to reuse that logic to meet strategic business requirements. Development efforts can meet new requirements more quickly and more effectively by incorporating legacy components. This is superior to attempting to replicate decades of embedded legacy business logic from scratch.

Companies should enable developers to address new development and legacy systems integration under a single strategy that fully synthesizes legacy systems and new development integration into the systems design and development cycle. Anything less compromises the future of e-business solutions in major enterprises.

Data Integration

Most e-business applications require access to legacy data. Fortunately, back-end data integration solutions allow systems to access legacy data from Web-based applications. Data integration approaches vary, but typically involve accessing legacy data structures via interface technology that is launched from the application system. This approach is useful for Java applications attempting to access relational databases. Other options include extracting and integrating legacy data into newer, more accessible formats.

Analysts may determine that legacy data needs to be consolidated or cleaned up prior to being accessed by a new system. Data-related challenges rate very high in the ongoing concerns of management and include redundancy, fragmentation, integrity issues and inconsistent definitions across business units.

Data redundancy means that a phone number, customer number, employee number or some other vital piece of information is defined in multiple places. One long distance provider, for example, spent weeks trying to re-synchronize its databases to reflect that a business customer was indeed switched back to that company.

Data fragmentation occurs when overlapping data is distributed across multiple databases and business units. This is an issue when an application requires cross-functional access to data that is not consistently defined at an enterprise level and cannot get that data from a single database. Some back-end data integration products provide limited support for this level of fragmentation, but most complex data fragmentation issues cannot be resolved by real-time data integration technology. A separate project may be required to address cross-functional fragmentation if this data is critical to a project.

Data integrity means that invalid data is being stored within fields that have been poorly edited or maintained. Data inconsistency on the other hand means that a customer in one business unit is not a customer in a second business unit. Data inconsistency is one of the most imposing challenges to cross-functional e-business systems deployment.

Addressing these challenges may involve more than just linking applications into back-end systems. Analysts may need to consolidate or reorganize certain data prior to deploying new applications that use that data. If this is the case, collaborative approaches are essential.

If, for example, a company wants to create a common view of order processing data, it would require working with multiple business units, the data architecture group, application analysts and any third parties with ownership in the data issue. Data analysis and integration is one area where cross-functional collaboration is not a luxury but rather a critical part of the systems deployment process.

Architecture Management

With budget cuts and cost cutting back into vogue, organizations need to focus on high payback IT projects that will allow them to leapfrog the competition. Delivering strategic new systems that leverage legacy applications and have unimpeded access to legacy data requires an architecture management infrastructure. Without such an infrastructure, organizations will not be able to deploy a scaleable reuse strategy.

Creating such an infrastructure is a significant challenge and one that demands collaboration across IT functions within and outside of the enterprise. With legacy environments loaded with redundant functionality and data, organizations must begin to put a management infrastructure in place for coordinating and leveraging reuse across corporate and externally shared infrastructures.

An architecture management infrastructure requires enterprise-wide coordination of development technologies, application servers, Web Services, development processes, component-based architecture, data architecture plans and legacy reuse strategy. This infrastructure does not restrict collaborative development teams but rather enables and empowers development teams to use the latest technology, processes and approaches in delivering collaborative business solutions to the enterprise.

Management should charter an architecture team with establishing an architecture management plan and facilitating its deployment. This team should have cross-functional business unit, IT and third party representation. This team would also be responsible for setting an example of how internal and external business and IT professionals can collaborate on a strategic architecture project.

External Resource Utilization

To fully leverage collaborative development environments, organizations should extend the reach of collaborative infrastructures beyond traditional enterprise boundaries. Web-enabled development products allow organizations to collaborate with suppliers, distributors, customers and competitors. With the expansion of ASP, outsourcing and Web Services strategies among IT organizations, the need for collaboration is even greater than when IT-related activities and systems were confined in-house.

For example, analysts may determine that a new system needs to reuse legacy-derived application components, but the legacy applications have been outsourced. Collaboration with the outsourcing firm is essential. Management will need to accommodate this requirement within outsourcing service level agreements so that the outsourcing firm has a clear understanding of their role and project expectations.

Another external resource consideration involves synchronizing development approaches and technologies. In the past, consulting companies took ownership of development projects and deployed technologies that ran counter to in-house development standards. When the consulting firm departed, the enterprise was left with a system that was not integrated with in-house applications and could not be maintained using standard development technologies. New systems, regardless of who develops them or where they are maintained, must fall under a development architecture that is synchronized with in-house standards.

Other external resource considerations include finding ways to leverage external analyses, design specifications, reusable components, Web Services, XML and test plans that may be available from third party sources. The architecture management team can play the role of facilitator and serve as a resource for identifying the best ways to obtain, coordinate and manage these external resources. This would avoid a scenario where, for example, twenty different development teams all individually sought to obtain Web Services from multiple vendors with no coordination.

Another area requiring collaboration of external resources involves synchronizing data interchange with third parties using XML. This typically requires determining industry standards and defining how those standards will be implemented among trading partners. A similar challenge involves shifting business processes and application functions into supply chain consortia. These relationships are highly collaborative by definition and involve internal business and IT units working with suppliers and competitors to achieve processing synergies.

Collaboration, by definition, must extend to third party participants, yet this is the one area where senior executives seem to abdicate oversight roles by telling third party service providers that they "do not care how they get the job done as long as it is on time." Management, working with the architecture management team, should seek to synchronize external resource utilization activities once the collaborative development environment has been rolled out internally.

The Collaborative Environment: Synthesizing the Parts

Management must emphasize the criticality of coordinating and deploying development technologies, processes, and related data and application strategies under a collaborative environment. Taking a comprehensive view of these factors will allow IT to streamline the creation, integration and management of critical application systems while leveraging the skills, data and applications already in place.

New development technologies, integrated development environments and the automation of processes within these environments will raise the effectiveness and efficiency of development teams enterprise-wide. Synthesizing these three factors should be a high priority for management and cross-functional architecture personnel. Processes should support the technology and the technology should support the processes.

Conflicts in the use of these facilities should be dealt with by the architecture team and not glossed over. Many times conflicting information regarding standards, software, processes and other factors turn development teams into battlegrounds that deter from the primary purpose of delivering, maintaining and managing application assets. Management may not realize that this is happening, but it does. Business and IT managers must recognize these conflicts and address them.

The role of people within the collaborative development environment is a critical factor that cannot be overlooked. Business units, IT and third parties have not always had good working relationships in many companies. This must change in order for collaborative development to succeed. As stated earlier, forced collaboration does not work. Many of the techniques discussed, including self-organizing, offsite sessions to clarify a project�s purpose and principles, changing where people are physically located and using external facilitators can help smooth the way for improved collaboration among development team participants.

Companies that launch and nurture collaborative development environments will reap significant benefits in leveraging internal and external information resources across the business community for decades to come. On the other hand, organizations that continue to develop handcrafted applications, where reuse is limited and resources are strained, will slip farther and father behind their more nimble competitors.