Integration Strategy

In previous sections, we've discussed the most important characteristics to consider in developing an integration strategy. Our strategy must be carefully considered and be a well-planned scheme with well-defined goals. Figure 5.2 illustrates the two primary components of our integration goals. In devising the strategy, the integration factors are an evaluation of our existing software development processes and methods, whereas the integration approach represents our ideal development processes and methods of the future. Therefore, our integration strategy must carefully consider the benefits we wish to realize from our integration and must define a clear path of execution with well-defined goals that enable our software development team to realize these benefits.

Figure 5.2. Integration Strategy Combining Integration Goals and Integration Factors

The most effective integration strategies are those that are treated as separate projects, apart from the software development project. Continuously evaluating the progress, and making appropriate modifications to the strategy, most likely results in a more satisfying experience. Breaking down the integration strategy into various phases, emphasizing the adoption of various best practices, typically helps to more effectively mitigate the risk of failure, which is in accord with the CMM.

Because of the various permutations associated with the multiple inputs to our integration strategy, it's virtually impossible to adequately define in just a few short paragraphs an integration strategy that's suitable for all organizations. Therefore, our discussion in this section presents general considerations that must be given serious thought regardless of our organization's existing methods. However, it should be clear from the previous discussion that the goal of any integration strategy is the use of a formal tool in a team development environment. We provide this caveat: It's doubtful that many teams can achieve this high level of integration in a short period of time.

This isn't necessarily a reflection on the team itself, but more likely a reflection on the current state of the technologies the team is using. The time period required to

successfully integrate a team development approach is largely dependent on the integration considerations.

Figure 5.3 illustrates the cost and complexity associated with any UML integration strategy. Individual developers using an informal tool is the most inexpensive option, yet it also offers the least amount of benefit. A team environment using a formal tool offers many of the advantages we've discussed, yet it also is most expensive. Striving to achieve either extreme on the benefit continuum may be unrealistic. Instead, our goal should be to reach a point on the continuum where we're utilizing the software development best practices in a manner most appropriate for our software

development team.

Figure 5.3. UML Integration Graph

If many of the integration factors are present, it's likely that we have a well-defined and repeatable software process, individuals who are well versed in object-oriented principles, and a solid understanding of many of our implementation tools. In this scenario, it's likely that the only aspect missing is a clear modeling strategy. In fact, at this point, UML adoption may be the next logical step in the improvement lifecycle of our existing methods. Suffice it to say, however, that in an environment such as this, the time period required to adopt the UML will be much shorter than if any of the other integration factors aren't present. However, these types of environments are also quite rare. With the exponential growth of many technologies, especially Java,

mastering one aspect typically leads only to the need to master another.

Assuming that an organization is typical, it's likely that our development team lacks more than just a single integration factor. Therefore, when adopting the UML, it's important that these considerations be given careful thought as to how our

environment will provide the team with the necessary information. This learning experience traditionally comes from training. While formal training can provide a solid foundation, it is highly likely that it won't suffice as the only means through which our development team learns these new technologies. It's typically more effective to utilize many of the new technologies on pilot projects. If our organization doesn't have the luxury of enabling our team to learn and experiment on a pilot project, we should consider first applying the newer technologies to a lower risk portion of a system, possibly isolating our first attempt to a subsystem. Also, we should consider utilizing the services of an experienced mentor. While the purpose of any integration strategy is to help develop better software, which should help minimize risk, risk is inherent in the integration strategy itself. A series of small wins not only enables our development team to gain experience with new technologies, but also to build confidence.

Because we can't control the existing integration factors, we must devise a strategy that takes this factor into account. We can control, however, our integration goals and the time and cost associated with the overall effort. Therefore, the integration goals we're striving to achieve should consider the benefits we wish to realize from our integration. Only then can we effectively adopt an approach that supports our efforts.

For instance, if we know we're using Java as the implementation language but aren't considering forward- and reverse- engineering of our code, using specification models will be most useful.

Keep in mind that an approach to use the UML on an individual basis may not resolve the true challenge in software development. Only a team-based approach can help us create more resilient systems and manage change more effectively. All team members must be able to unambiguously understand the system in the same manner but from potentially different perspectives. The UML helps us do that, and therefore, an approach emphasizing team dynamics provides the most benefit, given that we can accommodate the various integration considerations discussed earlier. If not, an individual approach may be all we're capable of at the present time. Even so, the benefits of emphasizing architectural resiliency still can be realized by developers, and that quite possibly may be an advantage in comparison to our previous methods.

When devising an integration strategy, give careful consideration to the following questions:

• How well do we understand the tools we use?

• How well do we understand our implementation language?

• How well defined is our software development process?

• What benefits do we wish to derive from using the UML and other best practices?

• How well do our tools support our desired development process?

• How supportive is our team of adopting these new ideas?

5.3 Conclusion

Our integration strategy is heavily dependent on the current state of software development within our organization. The various integration factors provide an indication of this state. Our strategy must carefully consider these factors, and we must devise a strategy that enables us to achieve our integration goals. It's imperative that any integration strategy be realistic in the plan it sets forth. Placing unrealistic expectations on our development team only results in frustration and conflict.

Evaluating the integration strategy and making adjustments should be done as necessary. Treating the integration strategy as a project in itself can bring awareness of its goals. Communicating the benefits of the strategy helps all development team members understand more fully the important role the strategy plays in developing better software.

The integration strategy should consider the best practices we're interested in taking advantage of. A phased integration strategy most likely will offer the greatest chances for success. Keep in mind that any technology that isn't helping us create better software should not be used. Don't adopt a technology because it's the latest industry trend. Instead, it should be adopted because we understand its value.