Chapter Twelve. Integration Methodology

Software entities are more complex for their size than perhaps any other human construct, because no two parts are alike. . . . If they are, we make the two similar parts into one, a subroutine, open or closed.

Frederick P. Brooks, Jr.¹

1. Frederick P. Brooks, Jr., The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (Addison-Wesley, 1995), p. 182.

A Lean Integration methodology cannot be “bought”—it must be cultivated and evolve from the ground up. When we talk about “buying” a methodology, we mean adopting a prescriptive collection of software development life-cycle techniques, tools, and templates. The issue is that the packaged “off the shelf” methods are virtually all project-based and don’t address the issues of sustainability and continuous improvement that are the cornerstones of Lean Integration.

The Lean Integration methodology is concerned not just with building quality solutions, but also with establishing the processes to sustain solutions indefinitely in a production environment. Integration requires a specific methodology that is distinct from project management, software development, or application architecture methods. Integration does indeed leverage techniques from each of these and other disciplines, but it requires a unique collection of methods in order to achieve sustainable positive results.

It certainly is possible, and highly encouraged, to adopt selected tools or techniques from the Open Source or supplier communities since there is little point in reinventing the wheel for basic activities or methods that have been proven to be effective. But much of the value of Lean, and the attribute that differentiates it from other methods, is the culture of continuous improvement and organizational learning, which demands that each organization develop its own approach.

This chapter provides an outline for how to establish a methodology for a specific organization. It also compares and contrasts Lean and agile methods and provides a case study in keeping standards as simple as possible. The chapter closes with a case study that shows how a consistent project methodology can be successfully adopted across independent business units in a highly distributed and diverse organization.

The scope for integration methodology is the enterprise system-of-systems, but this term can be applied at different levels. It usually refers to an entire corporate entity or government agency, but it could also refer to a subsidiary of a corporation or to a collection of entities operating as a supply chain within an industry. In any event, the significant point is that an integration methodology comes into play for multi-application integration efforts and not for single applications. Some large applications are themselves complex enough that they use middleware technologies to facilitate integration of the application components, but the process of integrating components within a system should not be confused with integration across systems.

Table 12.1 lists the levels of maturity in an organization with respect to the organization’s commitment to the level of integration. As the level of maturity increases, the focus of design and corporate information flow becomes more vital to the lifeblood of the organization. As integration standards become ubiquitous and second nature to developers, information becomes more free-flowing and natural.

Table 12.1 Integration Methodology Maturity Model

The primary challenges that an integration methodology must address are not only to deliver projects that implement integrated solutions, but also to ensure that multiple integration projects that may be in progress simultaneously do not conflict with each other, that different project approaches can be supported, and that the integrations will be sustained once the projects are over.

Many organizations tend to overlook the interdependencies between projects and ongoing management efforts. For example, once the integration team for a given project completes its work, it typically hands off each component of the integrated solution to the various functional teams which then maintain their individual pieces of the solution. Over time, the smoothly operating interdependencies between components (which existed at the time of initial deployment) begin to deteriorate. Independently managed elements change without clear end-to-end visibility of the impact.

Creating a sustainable model to build, coordinate, and maintain integrated solutions requires three main ingredients: a defined methodology for each integration project, governance checkpoints to ensure that projects conform to the standards and that they don’t undermine or conflict with other integration projects, and a methodology to sustain the integration solution after the projects are completed. The rest of this chapter presents a collection of activities to guide an organization in developing and evolving a “custom fit” integration methodology.

Activities

As depicted in Figure 12.1, six steps are necessary to set up a sustainable integration methodology. Each step is explained in detail in the following sections. Note that we define here the steps to establish an umbrella integration methodology that still permits individual projects in the enterprise to use different methods.

Figure 12.1 Integration methodology activities

The graphic implies that implementing an ICC is a waterfall, or strictly sequential, process, but it is more accurate to view it as a first-time-through series of activities. All of the activities must evolve over time and are subject to continuous improvement disciplines. Nonetheless, there is a more or less sequential nature to first establishing the integration methods:

1. Implement the ICC: An ICC is a prerequisite for a Lean Integration practice, so this is the first step.

2. Define the enterprise standards: Define the core standards for architecture, technology, and development that must be adhered to regardless of what project methodology is adopted.

3. Select the project methodology: Select a default or standard project integration methodology for the enterprise, and define governance checkpoints for each integration project, regardless of whether the standard project methodology is used or if an alternate methodology is adopted.

4. Transition the project to the ICC: Establish processes to transition integration accountability from the project team to the ICC for ongoing management of the integration dependencies.

5. Maintain the metadata: Maintaining metadata about integration dependencies and data lineage is one of the ongoing responsibilities of an ICC as applications and their dependencies change.

6. Control configuration changes: Establish an ongoing process to manage the changes in applications and their implications for or impacts on other applications.

Step 1: Implement the ICC

Implementing the ICC should be considered a project in its own right. In other words, define the requirements for the desired target state in terms of people, process, policy, and technology dimensions; develop a step-by-step plan to close the gap between the current state and future state; assign responsibility to a manager to implement the plan; and monitor and control the ICC launch implementation to ensure that it stays on track.

An ICC organization could be established quickly in as little as 90 to 120 days if there is a compelling case for rapid implementation such as a top-down directive or pending corporate merger. Alternatively, an ICC could evolve more gradually over a period of several years by moving through several organizational stages (best practices, technology standards, shared services, and central services), with each stage adding greater scope and responsibility.

Choosing the right ICC implementation requires answering questions about the services the ICC should offer and understanding the current organizational culture, financial accounting processes, and human resource allocation. Consider the benefits of an ICC implementation versus the costs and risks of a project silo approach. Choosing the right model is significant because a good ICC will grow in importance to the organization.

When choosing an ICC model, keep in mind that each type is applicable to a different set of business requirements. A company might well evolve through the various models. Some factors to consider include

• Organization size

• Business value/opportunity planning for an ICC implementation

• IT strategic alignment

• Urgency/bias for action

An ICC may be implemented quickly or it may evolve, but in either case a plan should be developed. Table 12.2 shows a sample 120-day plan with specific milestones for each 30-day period in four tracks that address the people, process, policy, and technology dimensions.

Table 12.2 Sample 120-Day ICC Implementation Plan

Step 2: Define the Enterprise Standards

Standards for implementation should fall into categories, for example, architecture, technology, and development. During the actual implementation, standards are developed for areas of integration development. As well, linkage to existing internal standards should be established.

There is a widespread problem of which many of us (including ourselves at various times over the years) are guilty: overengineering standards. We certainly see examples of overly complex specifications from the standards bodies, but even internal corporate standards can succumb to the same trap of developing overly complex and unimplementable standards.

A core Lean principle in regard to developing standards is to define the minimum number of things that must be the same so that everything else can be different. In the foreword to the book RESTful Web Services by Leonard Richardson and Sam Ruby, David Heinemeier Hansson admonishes against “what the merchants of complexity are trying to ram down everyone’s throats.”² It is not clear from his brief foreword who exactly Hansson (creator of Ruby on Rails) considers to be the “merchants” who are creating complexity. While there are indeed people and organizations that benefit from excessive complexity, we’re not as cynical as Hansson and wouldn’t give suppliers, standards bodies, or industry analysts as much credit for a premeditated complexity strategy that the term merchant suggests.

2. Leonard Richardson and Sam Ruby, RESTful Web Services (O’Reilly Media, Inc., 2007).

A number of forces create excessive complexity:

• The obsession with creating standards/protocols that are all-encompassing and deal with every possible situation

• The desire for consensus and harmony, resulting in the inclusion of everyone’s point of view—even if some of them are not rational

• Weak discipline associated with the hard work of weeding out nonessential elements

• Poor reference architectures that don’t provide a clear ME&C structure, thereby leaving lots of room for interpretation and overlap

None of these vulnerabilities is a unique attribute of the software vendor community or the standards bodies; these are human qualities to which everyone is subject.

As Samuel Johnson once said, “If I had more time I would have written more briefly.” The fact is that the IT world is indeed complex, but it is the job of the Lean Integration team to do the hard work and take the time to make it simple for others.

The architecture of the Web, REST (which stands for “representational state transfer”), is a great example of the success of simplicity. While you might be able to get away with a more complex set of standards in your enterprise (especially if you have a strong central group that carries a big governance stick), any complex standard becomes increasingly harder to leverage effectively the bigger you get.

It is important to distinguish between “project standards,” which are defined by the methodology selected in step 3, and “enterprise standards,” to which all projects must conform. In addition to enterprise standards for technology, interfaces, information exchange protocols, and data definitions, the enterprise standards must also define the governance checkpoints that each project must follow. These checkpoints provide the mechanism to ensure that projects don’t conflict with each other and that they conform to the enterprise standards.

Clearly documented enterprise standards are one of the best opportunities for establishing the ICC’s value as a governance group. This will help in areas of resource utilization and service management and in reducing support costs.

Step 3: Select the Project Methodology

Building an ICC involves developing an ongoing discipline and support group around integration services and capabilities. This ongoing competency is independent of project methodologies and provides the support infrastructure for sustainable data and process integration.

Step 3 is the task of selecting a default or standard project integration methodology for the enterprise. Despite the fact that a standard may be defined, it is important to note that different integration projects may use different methods. For example, if you contract with a systems integration firm to serve as the prime contractor for a large project, that firm will almost surely insist that it use its own proprietary methodology since it is a key source of value.

Nonetheless, the ICC must be prepared not only to support the standard enterprise project methodology, but also to be flexible enough to support other projects that may be using other approaches. Step 3 involves defining governance checkpoints for each integration project, regardless of whether the standard project methodology is used or if an alternate methodology is adopted. Recommended checkpoints for waterfall-style projects include

• Completion of the project charter

• Approval of funding

• Identification and selection of the methodology for a given project

• Completion of high-level design, including the definition of all integration dependencies

• Completion of a detailed design and impact on shared technology components

• Start of integration testing

• Approval to migrate changes to production

• Post-implementation transition to ongoing support groups

Each of the defined checkpoints should specify who will perform the review and how (i.e., peer review, committee review, management review, etc.) and what documents or artifacts are required.

The approach for supporting projects that use agile or iterative methods is somewhat different. Agile methods focus less on documentation and formal handoffs and instead rely more on in-person communication and demonstrable results through frequent releases of incremental functionality. See the following section on agile versus Lean methodology for a more detailed discussion of this topic.

Step 4: Transition the Project to the ICC

After each project is complete and ready to be transitioned, the solutions are turned over to the ICC for ongoing management of the integration dependencies. Items to transition include

• Project artifacts/drawings

• Data extraction and transformation rules Testing plans/results

• Reusable rules and objects

• Metadata sources

• End-to-end data flows and process dependencies

The ICC is responsible for identifying the actual transition deliverables and determining the timeline or phase of the project when specific items are due. The focus is not only to determine integration points, but also to manage ongoing maintenance.

Note that in addition to transitioning the “integration” dependencies to the ICC, the project team must also be prepared to transition ongoing responsibilities for the project to other IT groups (e.g., application maintenance, network, security, etc.).

Step 5: Maintain the Metadata

Maintaining metadata about integration dependencies and data lineage is typically one of the ongoing responsibilities of an ICC. As applications and their dependencies change, it is important to incorporate any changes that occur in various systems as a routine part of ongoing maintenance of the metadata that describes each of the components and their relationships.

More information on this topic can be found in Chapter 13, Metadata Management.

Step 6: Control Configuration Changes

Controlling configuration changes is also one of the key ongoing responsibilities of an ICC. A process must be in place to manage the changes in applications and their implications or impacts on other applications. The goal is to focus on the integration aspects of new changes as well as the configuration of the integration systems that support them.

More information on this topic can be found in Chapter 17, Integration Systems.

Summary

The Lean Integration methodology involves the process of selecting, developing, and sustaining an ICC model; coordinating and monitoring multiple projects as they are being executed; and sustaining the integrations once the projects are completed. The ICC model provides the integration governance over application systems as they are developed and progress through their life cycle.

Agile versus Lean Methodology

Agile principles and Lean principles have much in common. This section addresses the following questions:

1. Do agile methods complement or work against Lean Integration? In other words, what is the degree of alignment between agile principles and Lean Integration principles, and how would they work in an Integration Factory context?

2. Can Lean Integration support an agile project methodology? For example, an Integration Factory may be supporting multiple projects at any given time, some of which may be following a waterfall methodology and others an agile methodology. Is this a problem and should the factory have different processes for the two project types?

To begin, we need to provide a high-level overview of agile. Wikipedia defines it this way: “Agile software development refers to a group of software development methodologies based on iterative development, where requirements and solutions evolve through collaboration between self-organizing cross-functional teams. The term was coined in the year 2001 when the Agile Manifesto was formulated.”³

3. Wikipedia, August 2009, http://en.wikipedia.org/wiki/Agile_software_development.

The Agile Manifesto makes the following value statements:

We value...

That is, while there is value in the items on the right, we value the items on the left more.⁴

4. www.agilemanifesto.org.

Like many other methodologies, agile has its own unique language such as the “ScrumMaster,” who maintains the processes in lieu of a project manager; a “sprint,” which is typically a two- to four-week period during which the teams create a potentially shippable product increment; and the “daily scrum,” which is a project status meeting that occurs every day and is time-boxed to usually 15 minutes. If we look past the buzzwords, we find many Lean concepts embedded in agile. Agile also uses some of the same techniques as Lean, including A4 problem solving and the “5 Whys.”

Certainly there is more to integration than software development, but to the degree that integration does involve software development, there is a great deal of alignment between the respective methods, as summarized in Table 12.3. The left column shows the 12 agile principles from the Agile Manifesto. The right column shows the Lean principles that have many of the same objectives as the corresponding agile principles.

Table 12.3 Agile Principles Compared to Lean Principles

Do Agile Methods Complement or Work against Lean Integration?

Several of the agile and Lean principles are very similar and don’t need much clarification. A few of them, however, do deserve a few comments to highlight the unique qualities of one or the other.

One of the strongest themes in agile is iterative development, as indicated in principles 1 through 3, which even go so far as to prescribe the frequency of iterations. Lean doesn’t prescribe an iterative approach nor does it put an arbitrary time frame on delivery, but it nonetheless aligns strongly with agile in the sense that Lean strives for small batch sizes (increments) and the fastest possible delivery in response to customer demand (pull). Lean also uses manufacturing techniques such as mass customization to achieve rapid delivery. Furthermore, one of the best ways to mistake-proof (poka-yoke) integration components is to build them incrementally and validate each iteration. As stated by Michael Levine in A Tale of Two Systems, “Continually ask this question: ‘What is the minimum set of functions we can put into production and get business value?’ Then do that. Then do it again.”⁵

5. Michael K. Levine, A Tale of Two Systems: Lean and Agile Software Development for Business Leaders (CRC Press, 2009), p. 291.

Agile principles 4, 5, 6, and 11 address team issues and also promote the idea of bottom-up empowerment, just as Lean does. Lean, however, does not prescribe the frequency of interactions (agile suggests daily meetings), nor does it insist on face-to-face conversations. Lean, however, does put a strong emphasis on visiting the gemba (the workplace where the work is being done), which accomplishes similar results. Business sponsors, users, and other stakeholders shouldn’t sit in their offices and manage by reading status reports or participating remotely via conference call; they should genchi genbutsu (“go see for yourself”). Lean also relies heavily on pull signaling mechanisms such as andon lights; the equivalent in a software factory may be an automated workflow tool that places a task on the integration team member’s work queue. In short, Lean doesn’t insist on face-to-face communications as long as the appropriate mechanisms are in place to ensure effective handoffs.

One way to achieve effective communications that doesn’t necessarily require face-to-face interactions is the use of simulations, even in the early stages of a project before all the components of the end-to-end solution are available. Simulation tools have the benefit of forcing a degree of specificity that computer software demands; in other words, the act of programming a computer to produce a simulation forces you to be specific. And as explained by Levine, “. . . simulations [are] a mechanism of visual management, one of the key integrating events that helped teams collaborate effectively.”⁶

6. Ibid., p. 144.

Agile principles 1, 3, and 7 prescribe working software as the primary deliverable rather than specifications or documentation. Agile keeps much of the project documentation (such as requirements and user stories) on flip charts or whiteboards in the project room; these are discarded after the project is over. Lean is similar in that it focuses on what the customer values (working software) and eliminating waste such as unnecessary documentation that is not used after the project is over.

If agile and Lean are so similar, why couldn’t one just use agile methods instead of Lean? There are several key concepts in Lean that agile does not address. Fundamentally, agile is a project methodology, whereas Lean is a sustaining methodology. Lean puts a strong emphasis on understanding, optimizing, and continuously improving the entire value stream, not just optimizing a given project. Agile does encourage team learning, but its focus is on staff development and not on institutionalizing end-to-end process improvements. Lean also applies manufacturing principles such as jidoka (autonomation) and mass customization to the software development process; agile is silent about these.

To answer the question in the header of this section, agile and Lean are generally very complementary when it comes to developing integration software components. Lean, however, goes further in providing sustainable practices. Our best advice to you is to select techniques from both practices and continuously learn and improve on them in your organization.

Can Lean Integration Support an Agile Project Methodology?

Another way to state this question is “Should an ICC, or Integration Factory, do anything different when supporting a project that is using a waterfall methodology versus a project that is supporting an agile methodology?” When the question is stated in this way, the answer is no, you shouldn’t do anything different, for one simple reason: Focus on the customer and deliver what (s)he considers valuable. If the customer (the project being supported) desires rapid delivery of incremental integrations, the ICC should deliver that. If the customer desires formal delivery and signoffs of stage-gate deliverables, the ICC should deliver that. The beauty of the metadata-driven Integration Factory is that it can just as easily respond to both approaches since it views the factory information flows to be just as important as the material flows. The Lean disciplines involved in defining, optimizing, and automating both of these flows make it easy to tap into the metadata repository and extract formal reports and deliverables that the waterfall project requires or to focus on rapid delivery of small batches of functionality that the agile project demands.

An interesting observation that we have made over many years of experience in working on large, complex IT projects that follow a waterfall methodology is that they still require an agile integration approach. The reality is that the big requirements document that is produced in the early stages of the project never fully, or accurately, specifies the interfaces, data quality profile, or integration requirements. A common pattern we have observed is that the integration testing phase always takes longer than anticipated and involves multiple iterations of integration components as the “real” integration needs are uncovered. Once again the factory approach handles this situation elegantly by using a metadata-driven mass customization approach to rapidly deliver and redeliver integration components.

A question we have been asked on more than one occasion is “Which approach is better for a large-scale enterprise systems integration project or program: waterfall or agile?” We generally recommend agile methods, but there are times when it is challenging to do so. For example, there is often more than one customer or organization involved in a large-scale program, and everyone needs to buy into the agile approach for it to work effectively. Some customers (business sponsors) may demand certainty around project scope and cost, which often steers teams down a waterfall methodology path. It also may be difficult to replace a collection of tightly integrated legacy systems in an incremental fashion while also maintaining existing service levels, and hence a big-bang conversion may appear more feasible. Finally, integration teams may be separated geographically in large multinational firms, or the project may include vendor teams operating under different contractual terms, both of which make it difficult to apply agile principles of face-to-face communication.

To close the loop with the question at the header of this section: Yes, Lean Integration can indeed support agile projects just as effectively as it can support waterfall-style projects.

Engagement Services Management

Because ICCs are, by definition, shared-services functions that support many and varied internal groups that are considered to be customers, it is essential that they operate as internal businesses with a portfolio of services that potential customers can easily find, understand, and order.

This section focuses on defining and developing the various services to be provided by the ICC. The number and type of different services provided (e.g., production operations, metadata management, and integration training) determine the initial size and scope of the ICC. Once the services have been defined and the appropriate capabilities established, the organization can consider sustaining the service(s) in an operational mode.

Services to be offered by an ICC should include the following attributes:

• Name of the service

• Description/narrative of the service

• Who the likely buyer or consumer of the service is

• Value proposition

• Cost of service

• Ordering mechanism and delivery process

Many people confuse service definitions with delivery processes. There is a natural tendency for individuals to describe what they do from their own perspective rather than from the perspective of the customer who is the consumer of the service. Lack of clarity on this distinction is a primary cause of failed adoption of an ICC. It is imperative, therefore, to internalize this distinction as a first step. Any attempt to develop a service portfolio or value proposition in advance of obtaining this insight is pointless, because the result will be an organization that is perceived to be internally rather than externally focused, a situation that undermines the success of an ICC.

The sequence of steps needed to fully define the portfolio of services is as follows:

1. Define the services, which in turn

2. Define the engagement and delivery processes, which in turn

3. Specify the capabilities and activities, which in turn

4. Drive the requirements for tools and skills

In summary, the first step is to define the services from the customer’s perspective.

For example, consider a package-shipping company. If it defines its service and value proposition as guaranteed rapid delivery of packages from anywhere to anywhere in the world, it is likely to maximize processes such as an extensive network of local delivery vehicles, a fleet of airplanes, and sophisticated package-sorting and tracking systems.

If, on the other hand, it defines its service and value proposition as low-cost delivery of bulk goods to major U.S. cities, it is likely to maximize its network of truck and train delivery vehicles between major cities. Note that in this second scenario the customer is different (i.e., a smaller number of commercial customers instead of a large number of consumer customers) and the value proposition is also different (i.e., low cost versus speed and flexibility).

Thus, it is essential to begin with a description of the service based on a clear understanding of who the customer is and what the value proposition is from the customer’s perspective. Once that has been established, you can begin to design the processes, including how the customer will discover and order the service.

After the process definitions are complete, the ICC can proceed to define the capabilities and activities necessary to deliver the service requests and also to determine the tools and staff skills required.

Note: Fulfillment elements such as capabilities, activities, and tools, while essential to maintain a competitive service delivery, are irrelevant to the customer and are non-value-added activities. For example, customers don’t care how the delivery company knows about the current status of each package, as long as the organization can report the status to the customer.

Similarly for an ICC, the internal customers don’t really care how the developer optimizes the performance of a given ETL transformation; they care only that it satisfies their functional and quality requirements.

There are two key tests for determining if the services have been defined at the appropriate level of detail:

1. The first is to list and count them. If you have identified more than ten ICC services, you have probably mistaken fulfillment elements for services.

2. The second is to apply a market-based price to the service. If an external organization with a comparable service description and a specific pricing model cannot be located, the service is probably defined at the wrong level.

Because defining services correctly is the foundation for a successful ICC operation, all automation, organization, and process engineering efforts should be postponed until misconceptions are resolved.

Service identification begins with the question “What need or want are we fulfilling?” In other words, “What is our market, who are our customers, and what do they require from us?” A service is defined in terms of explicit value to the customer and addresses items such as scope, depth, and breadth of services offered. For example, it should consider whether the service will be a one-size-fits-all offering, or whether gradations in service levels will be supported.

Individual services can then be aggregated into a service portfolio, which is the external representation of the ICC’s mission, scope, and strategy. As such, it articulates the services that the ICC chooses to offer.

Two points are implied:

1. The ICC will consciously determine the services it offers based on perceived need and value. Simply performing a service “because we always have” isn’t relevant.

2. No ICC can be world-class in everything. Just as an enterprise may develop strategic partnerships to outsource non-core competencies, so must the ICC. This means sourcing strategically for services that are non-core to ensure that the ICC is obtaining the best value possible across the entire service portfolio. Outsourcing for selected portions of the service delivery can have other benefits as well, such as the ability to scale up resources during periods of peak demand rather than hiring (and later laying off) employees.

A value proposition states the unique benefits of the service in terms the customer can relate to. It answers the questions “Why should I [i.e., the customer] buy this service?” and “Why should I buy it from the ICC?” ICCs are well positioned (because of their cross-functional charter) to understand the nuances of internal customer needs and to predict future direction and develop value propositions in a way that appeals to them.

Other Factors Affecting Service Offerings: Strategic versus Tactical Priorities

Another significant challenge of determining service offerings is the question of targeting offerings based on strategic initiatives or tactical projects. For example, if an ICC has a charter to directly support all strategic initiatives and provide support to tactical projects on an advisory basis, the service portfolio might include several comprehensive service offerings for strategic initiatives (e.g., end-to-end analysis, design, development, deployment, and ongoing maintenance of integrations) and offer a “best practices advisory” service for tactical projects.

A list of IT projects provided by the project management office for an organization can be scored on a 1-to-5 numerical scale or simply categorized as high, medium, or low, depending on the level of cross-functional integration that is required.

Once the projects are categorized and scored with regard to integration needs, the ICC could provide central services such as development management of strategic projects that have a high index of integration versus projects with low levels of cross-functionality (which could be supported with a best-practices ICC model).

The goal is to focus on ICC service offerings that are geared toward strategic integration initiatives and to provide minimal ICC services for tactical projects.

The key to a successful ICC is to offer a set of services that add value to the ICC team. Services can be very helpful in reducing project overhead for common functions in each data integration project. When such functions are removed from the project, the core integration effort can be reduced substantially.