This chapter is from the book
This chapter is from the book
This chapter is from the book
Managing Integration Teams
There are two basic models for managing integration requirements and supporting software development projects: enterprise integration teams and business model-driven integration. Both models have their own challenges and key success factors. The choice depends on the corporate culture, the number of project teams, and the experience of project management staff.
Enterprise Integration Teams
Usually, the enterprise integration team is a separate team or department with dedicated staff to support it. These teams work at an enterprise level, and are liaisons with departmental and other distributed development project teams. The integration team is tasked with designing the integration infrastructure, setting standards, and working with the other project team leaders who implement the various integration strategies and components.
Enterprise integration teams need to have a broader view of the corporate IT function and the corporate business goals. The challenges faced by these teams include getting support from other project teams in implementing enterprise-level integration requirements. It is not unusual for department project teams to feel burdened with extra work by the enterprise teams. There is often conflict between the short-term goals of department project teams and the long-term goals of enterprise integration teams that result in tension; integration often suffers as a result. Enterprise integration teams rarely succeed without continued support from senior management. Figure 7.2 shows the critical role of project managers in enterprise integration teams. These project managers not only manage specific integration projects but also are responsible for coordinating integration analysis across department project teams.
Figure 7.2 Centralized integration team.){kind=link}
Business-Model-Driven Integration
Another model used in some corporate environments is to define integration requirements based on the business models. When using this model, the business users or business analysts define the overall business integration objectives, and publish a roadmap. Project teams responsible for implementing the roadmap resolve application integration issues by using the common development process. Individual project teams are completely responsible for adhering to corporate standards in their development projects. Project managers collaborate to schedule, estimate, and plan for integration-related enhancements and developments.
This model works well when the number of project teams is small (between one and five), and when the business models are well-defined and documented. For larger numbers of project teams, a central integration team is required to define the standards and ensure compliance across the enterprise. Also, the business models often are not accurate or even complete. The fast-changing business environment makes it hard to define the business requirements and build a stable business model. As a result, frequent changes to integration requirements bog down the project teams affecting the delivery of software.
Figure 7.3 shows the importance of a complete business model when it drives enterprise integration. A complete business model does not have to capture all business processes in the enterprise, but the business processes that are part of the model should be complete. Only then can integration requirements be derived for implementation across project teams.
Figure 7.3 Business-model-driven integration teams.){kind=link}
Advantages and Disadvantages
Both models have their advantages and disadvantages when applied to project-managing strategies. Isolating integration as a separate project enables the integration project teams to focus on developing the integration solutions more quickly. However, the practical value of the integration solution can only be realized when deployed in conjunction with business applications that are developed by different project teams. Many times, the integration solutions developed by dedicated integration project teams are technically good, but they are developed in isolation without full understanding of the complete requirements. The usual causality in these scenarios is the technology, which takes the blame for failed integration projects.
On the other hand, empowering individual project teams with the necessary integration standards and tools doesn't automatically guarantee cooperation between project teams. Many times, the management objectives of individual project teams are focused on departmental issues rather then understanding enterprise objectives. Unless a stable business model is defined, project teams are constantly grappling with changing integration requirements.
Software integration is a cross-functional requirement and cannot be solved by isolating the integration teams; nor can it be solved by allowing individual project teams to function in isolation. One approach that yields better results is training the development teams on integration tools and development methodologies that make integration part of the process. Project managers need to change their project management techniques and processes to include closer cooperation from other project managers, technical leads, business analysts, and integration experts. It is very important that every project team has a technical lead (or an architect, depending on the size of the project) who is a member of an integration team composed of technical and business experts.
In very large global organizations where integration issues are not only technical but also geographical, a central integration council with participants from all geographical regions is useful in determining the challenges of integration. In smaller organizations, integration teams tend to be formed on a more informal basis, with representation from each project team as required for specific time-bound integration projects. Regardless of the type of team and the methods used to form them, participation from all involved application teams and availability of integration experts is critical.
The integration experts need to ensure that all software development activities adhere to common enterprise integration standards, tools, and architecture. We will explore the role of adapters in integration projects more in the following sections.