Methodology
From Mnjiwiki
Integration projects should be delivered incrementally. It is helpful to organize the overall initiative as a series of related deliverables. Two common sets of terminology are used;
- a Project with supporting Subprojects, or
- a Program with supporting Projects.
We will use the Program with supporting Projects terminology in this document.
Contents |
Program
An Integration Program requires careful thought, planning, organization, and above all, commitment from top levels of the organizations impacted.
Key deliverables include:
- Program Plan
- High Level or Program Level Business Requirements
- Architecture Definition Document
- Service Catalog
Program Plan
A Program Plan addresses scope, schedule, cost and quality for the overall program. The plan should not be overly detailed, but rather provide a framework for projects included in the program. Broad assumptions and estimating models are common tools used in developing program level plans.
- Scope - a portfolio of projects
- Schedule - start and end date of each project, with key dependencies
- Cost - high level effort estimates and resource requirements for each project
- Quality - a consistent process for project delivery
A Governance Process must also be defined to enable decision making such as prioritizing projects and conflict resolution. This process should work toward what is in the best interest of the organization as a whole. This is often a difficult process and sometimes evolves into a horse trading exercise where managers agree to the interests of one party in exchange for another decision.
Program Level Business Requirements
As part of planning an Integration Program, business requirements must be understood at a high level. Key business processes must be explored to identify touch points and dependencies on other business processes. Information associated with business processes and what information is shared with, or obtained from other business processes will also be reviewed and documented.
By defining requirements at a high level a conceptual view of the entire program will emerge. This big picture will help define services and integration processes that need to be developed, providing the information necessary to create an effective Program Plan.
Architecture Definition
A Technical Architecture Document will be published to provide a conceptual framework for delivering integration solutions. The architecture document will specify the preferred approach to support integration patterns (request/response and notifications).
Other areas that should be discussed include:
- Logging and retry processing associated errors and exceptions.
- Audits of various activities to support problem solving and various statistical reporting that may be needed.
- Strategy for leveraging reuse of XML structures, code and various services.
- How will new versions of integration services and XML schemas be supported?
- When is a layer of abstraction preferred vs when should consuming applications accept data directly from other systems?
- Should applications generate complete messages for outbound notifications, or should they only generate event data and require a second step to provide a notification message?
Service Catalog
This may be a separate document or it may be included in one of the other documents produced as part of Program Planning efforts. Ultimately, the Service Catalog should be converted to an index to technical documentation on how to specific technical services.
Project
A methodology tailored to integration projects was developed by the Integration Consortium. This methodology is very effective, in part because its' simplicity. It is easily understood, and as a result can be readily adopted by a broad audience. Members of the consortium have access to the complete methodology, which is summarized in the table below.
| Phase | Key Deliverables |
|---|---|
| Define |
|
| Design |
|
| Build & Test |
|
| Deploy |
|
Define
The Project Plan provides a framework for completing integration deliverables associated with a specific project. The Plan, as well as the overall Program Plan, will balance scope and business objectives against schedule, resource and organizational constraints.
Business Requirements will be defined and documented by reviewing business processes and walking through various scenarios or use cases. Common scenarios, as well as exception situations should be reviewed.
Design
Business Process diagrams and other information developed as part of the Business Requirements definition process will be used as a basis for designing technical solutions.
Data Mapping Specifications will document rules for one system to consume data from another system. Creating mapping specifications will require knowledge of both the source and target systems, so this will be a collaborative effort between resources from both the providing and consuming applications. An example of a mapping is included below.
Design Documents will provide information necessary for programming to be completed. Design documentation often includes both logical and physical elements. Design documentation may be combined with the mapping specification or it may be produced as a separate document.
Test Plans will be documented to ensure to the system functions as expected.
Build & Test
The Build phase includes a series of activities where programming is completed, tested, reworked and retested. This evolution toward a finished product generally starts in a development environment where coding is completed and the developer completes technical Unit Tests with data that is often manufactured.
Once the code passes Unit Testing it is generally promoted to a testing environment where more functional level testing is completed by Test and Business analysts, as well as super-users. Early stages of testing are often completed in isolation, but later testing expands the boundaries to include integration with other programs and systems.
Plan on cycles or iterations of development and testing. Three cycles is generally a reasonable number to provide review/rework cycles and not extend the schedule excessively.
Deploy
Deployment Documentation and turn-over to production support is the final phase. Any formal Training required would also be completed as part of the Deployment phase.
