BeyeNETWORK - The Global Vision for BI and Beyond

Part 1 of this series discussed managing traffic in the SDLC/Zachman intersection. Now, we look at how the approach presented applies when there are multiple methodologies in use concurrently. Typical scenarios include merger and acquisition activity that results in two or more methodologies being brought together, an organization that uses different methodologies for their variety of project types, or an organization where a transition in development methodologies is underway.

Looking back at Part 1 for a moment, the features of the described approach include being highly extensible and providing clear visibility to the desired future state. The resulting benefits include the consistent flow back to the target architecture, the ability to maintain a normalized logical enterprise view, and the improved planning and budgeting precision as you progress through the stages. These benefits are key when employing multiple methodologies. For example, in mergers, each organization may bring its own methodology. The alignment to the common framework provides the bridge across the two to provide clear visibility to the desired future state and improve the planning and budgeting precision as you progress through the stages.

In looking at the approach presented for bringing the framework and the methodology together, it is applicable to the various development methodologies. The initial stages are common across all when supporting multiple methodologies. The path then branches out based on the project type and supporting methodology used. 

 
Figure 1: Supporting Multiple Methodologies

For example, in the case of a custom build, more of the framework artifacts will be needed. The overall SDLC progression through the framework is from the contextual to the conceptual, then logical, and on to the physical as described in Part 1. Whether the methodology chosen is waterfall, spiral, RAD, or agile based, the framework artifacts are required to build out the solution. What may vary are the sequence and the extent of the artifact, in that there are round trips through the framework views with the more iterative approaches as shown in Figure 2. Additionally, the different methodologies may require different composites, but should leverage the same primes.

When integrating a commercial off-the-shelf (COTS) package into the existing infrastructure, many of the architectural artifacts are set by the package. Since it is an acquisition rather than a build, the emphasis is on the integration with other components. The initial stages are common. The scope, or contextual view, is completed first. Additionally, the conceptual view provides the proposed solution prior to the SDLC Initiation stage.

The path branches out when acquiring a COTS package, in coming to the systems requirements analysis stage and the logical system model. The vendor provides the logical data model and component diagrams. These logical models are not needed to drive out the physical models since the package is already built. Instead, they are used to inform the interface designs and update the enterprise primes. The data flow diagram would be developed, as would the high-level sequence diagram, with the emphasis on interaction with components external to the COTS package. This logical portion of the framework may be relatively sparse for a COTS acquisition.

Figure 2: Iterative and Waterfall Methodologies

Moving on to the SDLC design stage, the vendor would provide the fundamental models from the framework such as the physical data model, lower-level sequence diagram, class diagram, and deployment diagrams. The models are needed to the degree required for integration and updating the enterprise primes. As with the logical level, this portion of the framework may be sparse. Again, whether the methodology chosen is a waterfall, spiral, RAD, or agile based, the framework artifacts tie back to the contextual and conceptual views. It is the sequence and the extent of the artifacts that will vary, in that there are round trips through the framework views with the more iterative approaches.

When development consists of enhancing what is currently in place, the focus turns to those components that are impacted. The scope and conceptual view are completed first. The path at the logical system model would now be to mark up the current logical system model with what is changing. The same applies to the physical model where the changes may not be architecturally significant, but the framework’s artifacts need to be updated.

Custom builds and enhancements rely more heavily on the architectural framework artifacts, as they are necessary in building out the solution. For enhancements, the focus is on the change from current models. For COTS procurements, the extent to which the framework is populated depends on the level of integration desired. The level is not only a function of the number of direct interfaces, but also of the solution’s role in the larger enterprise.

The approach presented in Part 1 for bringing the framework and the methodology together applies when multiple methodologies are in use concurrently. This is true regardless of whether the project is a custom build, an integration of COTS components, or an enhancement to an existing implementation. The alignment of framework to methodology is common in the initial stages and then progresses along parallel paths that may iterate and vary in the extent of the artifacts. Since the contextual and conceptual views are common across all, they provide a bridge to look across each project. Evolving the enterprise primes for these project views, even for procured packages, maintains the enterprise view. In this way, the approach described aids in ensuring that the resulting implemented solution moves the company forward toward the desired future state.

If you found this article helpful and would like to receive the latest insights each week from the experts featured on the BeyeNETWORK, please subscribe to the Bill Inmon Newsletter.