^{Document Information}

Document Title	EAI Total Business Integration Methodology
Revision / Revision Date	Jan 24, 2004
Publisher	EAI
Reviewed By
Distribution List (In addition to Reviewers List)

^{Revision History}


Revision History

	Revision #	Description	Initials	Date

^{Table of Contents}

Document Information............................................................................................................... 1

Revision History.......................................................................................................................... 2

Table of Contents....................................................................................................................... 3

1 Overview................................................................................................................................ 5

1.1 Assumptions...................................................................................................................... 5

1.2 Inputs and Deliverables................................................................................................ 6

1.3 About the Methodology................................................................................................. 7

2 Define.................................................................................................................................... 10

2.1 Project Definition.......................................................................................................... 10

2.2 Business Process Analysis......................................................................................... 11

2.3 Technical Requirements Analysis.............................................................................. 11

2.4 Software Quality Assurance Planning.................................................................... 12

2.5 Deliverables................................................................................................................... 12

2.6 Testing Methodology.................................................................................................... 13

2.7 Change Management Approach.................................................................................. 14

3 Design................................................................................................................................... 15

3.1 Logical Design................................................................................................................ 16

3.2 Architecture................................................................................................................... 17

3.3 Deliverables................................................................................................................... 18

4 Build...................................................................................................................................... 19

4.1 Integration Design......................................................................................................... 19

4.2 Coding............................................................................................................................... 20

4.3 Testing.............................................................................................................................. 20

4.4 Deliverables................................................................................................................... 22

5 Deploy.................................................................................................................................. 23

5.1 Quality Assurance & User Acceptance.................................................................... 23

5.2 Production...................................................................................................................... 24

5.3 Deliverables................................................................................................................... 25

6 Team Staffing..................................................................................................................... 26

6.1 Project Manager........................................................................................................... 26

6.2 Quality Manager............................................................................................................ 27

6.3 Architect.......................................................................................................................... 27

6.4 Business Analyst........................................................................................................... 28

6.5 Designer........................................................................................................................... 28

6.6 Developer....................................................................................................................... 29

7 Governance......................................................................................................................... 30

7.1 Deliverable Review Process...................................................................................... 30

7.2 Deliverable Flow........................................................................................................... 31

8 Appendix A - Templates..................................................................................................... 32

9 Appendix B – Template Samples...................................................................................... 34

10 Appendix C – Project Scenarios..................................................................................... 36

10.1 Green Field New Construction............................................................................... 36

10.2 Legacy Extension....................................................................................................... 36

10.3 External Business to Business............................................................................... 36

¹^Overview

The Total Business Integration (TBI) Methodology is a business process oriented methodology designed for projects that are integrating data, applications and processes within or across multiple business units using heterogeneous systems, throughout the enterprise. The methodology provides a foundation to maximize re-use opportunities by providing a common design approach, reusable templates and processes that can be leveraged by other projects within your company.

This methodology makes software quality assurance a priority over the entire lifecycle of an integration project. It uses Process Excellence and Capability Maturity Model (CMM) as guiding principles and incorporates best practices and templates from them into its guidelines and templates.

This document describes the phases in the TBI methodology with detailed descriptions of each activity and deliverable required.

1.1 Assumptions

The following assumptions have been made about the implementation and execution of the TBI Methodology:

· Integration practices and architecture are familiar to the Customer.

· Integration can be logically divided into “Source(s)” and “Target(s)”.

· All development will be following best practices that ensure the highest amount of reuse of components throughout the enterprise.

· This methodology was developed using the webMethods integration platform as the enterprise standard for a middleware tool. The webMethods platform supports multiple coordination patterns such as Publish/Subscribe and Request/Reply.

· This methodology was developed using TIBCO TurboXML as the enterprise standard to be used for XML schema creation.

· This methodology was developed using the XML Canon repository for storing XML schemas.

The following are assumed to be “out of scope” for this methodology:

· Preparation of data or applications for integration (example : data conversion, data cleansing or application modifications)

· Definition and documentation of application specific business rules and processes

· Designing and implementing hardware and networking infrastructure.

· Selection, purchase, and installation of integration middleware.

· Network, application, and database security setup.

· Middleware-specific best practices, naming conventions, and standards. This is covered in the e-advantage Best Practices Guide and e-advantage B2B/EAI Naming Standards documentation available in the Middleware e-room.

1.2 Inputs and Deliverables

The TBI Methodology is based on a set of inputs and deliverables for each of the four methodology phases: Define, Design, Build and Deploy. The inputs and deliverables are presented for each phase in the following diagrams. Refer to later sections of this document for more detailed descriptions of each phase and its associated activities and work products.

INPUTS

DELIVERABLES

1.3 About the Methodology

This business process oriented methodology was designed for Application-to-Application (A2A) and Business-to-Business (B2B) integration projects within your company. The methodology covers the full lifecycle of integration projects and is independent of the source applications and technologies.

This document contains techniques, best practices and templates with examples that will help implement this methodology.

This methodology is derived from industry standards and best practices from the following sources:

Business Process Analysis worksheets from ebXML

ebXML is a public standards body created by UN/CEFACT (United Nations/Center for Trade Facilitation and Electronic Business) and OASIS (Organization for Structured Information Standards) collaboration in 2001. The business process analysis worksheets assist in understanding the business process, business events, transactions and information flow. These worksheets can be used in “pencil and paper” or tool-driven mode.

DMAIIC (Six Sigma) & DMADV (Design Excellence) Methodologies used in building this methodology for PE projects

GEAR Methodology from Webmethods

GEAR (Goals, Explore, Assemble, Rollout) is a four phased methodology recommended by Webmethods.

UML from Object Management Group

UML is a visual modeling language for application development. It is a part of the Object Management Group’s public standards.

In addition to these industry standards and best practices, the methodology is based on SEI Capability Maturity Model(CMM) and best practices from System Integrators.

This methodology is to be used as a top-down approach i.e. driven by business process analysis. The desired outcome is to address the integration of entire business processes, and not simply individual applications or data sources. However, the methodology can also be used in a bottom-up approach where projects can select and use templates from the methodology that meet their requirements.

The TBI Methodology is organized in a three-level-step process. Starting with five major level 1 phases, continuing with level 2 and level 3 phases respectively. The following diagram illustrates the level1 and level2 levels.

Benefits of TBI methodology

· Creates a standardized approach to integration across the enterprise.

· Promotes reuse and leveraging of integration services and canonicals, which in turn will reduce the total cost of ownership and increase the speed to market for projects

· Enables Business process level integration to create future-proof solutions that will require minimal changes when the business process or underlying application architecture change. The other alternatives are data-level integration and application level integration.

Ø Data level Integration - Shared databases, triggers, extract/transform/load, etc.

§ The most fragile approach

· Most new requirements will have some impact on the data model

· Any change to the data model will multiply into n application updates

· New requirements to application A will force maintenance on application B

Ø Application level Integration – API’s, RPCs, DDE, message brokers, etc.

§ A dramatic improvement over data level approaches

· Data models for integrated applications are isolated

· However, maintenance and definition of the passed message is a similar issue to data level integration – it resembles point to point

²^Define

The first phase of the TBI methodology is the “Define” phase. The main purpose of this phase is to identify the scope, goals, and objectives of the project, perform detailed business process analysis, identify technical requirements and plan for the software quality assurance activities. During this phase the Change Management approach and the Testing Methodology is established for the project.

Level 2 Phases: Project Definition, Business Process Analysis, Technical Requirements Analysis, and Test Planning.

This process is followed during the Define phase:

Figure 1 - Define Phase Process Flow

2.1

Project Definition

2.1.1 Define Project

The purpose of this phase is to review the top-level scope of the project, value proposition, and issues that could impact the success of the project.

The Project Overview form is used for this activity.

See the TBI Methodology – Business Process Analysis Document Template for more details.

2.2 Business Process Analysis

2.2.1 Process and Functional Areas

Business Area Analysis: The purpose of this activity is to review the organizational entities that are in scope of the project, key roles, and names of the individuals. The business area template is used for this activity.

Business Process Area Analysis: In this activity, the processes that are in scope for the integration project are identified and documented. The business process area template is used for this activity.

See the TBI Methodology – Business Process Analysis Document Template for more details.

2.2.2 Business Event Analysis

This activity captures the key attributes of business events in a business process such as starting and ending points, the participants in the process and any known business rules, goals, pre/post- conditions etc.

Listed below are some key questions to ask of the business process owners during this analysis:

· Who are the key stakeholders?

· What are the boundaries/limitations?

· What is the process flow?

· What is the data flow?

· What are the input/output files?

· What are the transactions that trigger action?

· How do the transactions occur?

o Batch process?

o Real time?

· What are the business rules?

· What are the exceptions?

· What happens if something goes wrong?

o In general?

o Specific to a process?

· What are the systems involved?

· What are the dependencies amongst processes? What are the relationships?

· Are there parallel or simultaneous activities?

· Rule of thumb: Focus on the events/process steps that are the endpoints of integration events

See the TBI Methodology – Business Process Analysis Document Template for more details.

2.2.3 Critical To Quality (CTQ) Identification

CTQ Identification is the process of translating customer’s critical requirements into specific measurable requirements.

See the TBI Methodology – Business Process Analysis Document Template for more details.

2.3 Technical Requirements Analysis

This activity consists of identifying the technical requirements for the integrations.

2.3.1 Functional Requirements Gathering

In this activity the business process analysis definitions are translated into functional requirements per interface. This requires review of the business process analysis documents.

See the TBI Methodology – Technical Requirements Document Template for more details.

2.3.2 Non-Functional Requirements Gathering

This activity involves identification of non-functional requirements like performance, error handling and monitoring requirements for business transactions and interfaces. For example, once a purchase order is created in System A, it must be sent to System B within 15 seconds.

See the TBI Methodology – Technical Requirements Document Template for more details.

2.3.3 Data Requirements Gathering

This activity involves identifying the data requirements for the integration. The application owners identify the data fields required to support the business process flow in the source and target systems. The data fields are classified into 3 categories – mandatory, optional and those with default values.

See the TBI Methodology – Technical Requirements Document Template for more details.

2.4 Software Quality Assurance Planning

2.4.1 System Test Design

A strict quality assurance approach is enforced throughout the TBI methodology by incorporating quality control checkpoints, structured test planning, and execution of multiple levels of testing. This activity involves creation of an overall system test plan for testing the integrations. The test plan outlines the different levels of testing that will be executed along with the timing of these tests.

System test cases are derived from the technical requirements. These are written by the business analyst and verified by the Quality Manager.

See the TBI Methodology – Software Quality Assurance Plan Document Template for more details.

2.5 Deliverables

The following are the deliverables that are produced during the define phase:

Deliverable	Description
Business Process Analysis Document	The business process analysis document is a compilation of a number of things: Project Definition Process and Functional Areas SIPOC Diagrams Use Cases CTQ’s
Technical Requirements Document	The technical requirements document outlines the specific requirements for all the integrations that are identified. This document includes : Functional Requirements Non-Functional Requirements such as Performance Requirements Data Requirements
Software Quality Assurance Plan	The system test plan is the overall plan for the quality assurance checkpoints and testing of all the integrations.
System Test Cases	The system test cases are written based on the requirements to ensure complete coverage of all the requirements

2.6 Testing Methodology

TBI Methodology uses a combination of deliverables reviews and multi-phase testing to reduce defects caused by missed requirements, defects caused because designs did not cover all requirements, and defects caused by untested code paths.

The testing approach is divided into multiple tiers of scripted testing:

· Unit Testing: Verifies the smallest units of functionality within an integration.

· Integration Testing: Incremental testing of interactions between integration components.

· System Testing: End-to-end functioning of the entire process within the context of business process, and includes Source and Target systems.

· Load/Stress Testing: Test for performance and scalability. It is recommended that all projects perform this testing.

In all phases of testing, scripted test cases are developed from the base-lined deliverables from earlier project phases:

· System Test Cases are developed from Requirements.

· Integrated Test Cases are developed from Logical Designs.

· Unit Test Cases are developed from Integration Designs, and are written before construction of integration components begins.

· Load/Stress Test Cases are developed using a subset of system test cases.

Figure 2 – Testing Methodology

2.7 Change Management Approach

When business or technical requirements change, “Change Orders” should be created to define, assess impact, and estimate effort involved with the change. This process ensures that impact and effort are quickly assessed to determine when/if action needs to be taken. Physical sign-off on the Change Orders is required.

Change Orders are divided into two categories: Changes to Scope and Changes to Baselines. Changes to Scope are often driven by the business need for new integrations to be developed. Changes to Baselines occur when requirements change during the development life cycle and require integrations to be modified.

In either case, the project team will work with the Customer to assess impact on project cost and schedule, and determine an action plan to meet the new business needs and requirements.

See the TBI Methodology – Change Request Form Document Template for more details.

³^Design

The second phase of the TBI methodology is the “Design” phase. The purpose of this phase is to develop the logical Design, select XML standard, perform data mappings, define the schema, and develop architecture recommendation.

Level 2 phases: Logical Design and Architecture.

This process is followed during the Design phase:

Figure 3 - Design Phase Process Flow

3.1 Logical Design

3.1.1 XML Standard Selection

In order to ensure an application-independent solution and maximum reusability across multiple projects, the TBI methodology recommends the use of industry standard XML schemas for the layout of canonicals or business objects. If the XML standards in your company’s repository do not meet the data requirements, a new XML standard must be selected.

The XML standard selection framework is based on a two-step process

Start with an initial list of selected industry standard XML vocabularies and use the standards analysis process for short-listing these standards to a couple of standards. The framework defines the selection criteria in three broad categories:

Maturity and Industry acceptance analyzes the vocabularies on their industry acceptance and maturity based on the number of customer adopters, key adopters, tools available, number of releases etc.
Technical Architecture analyzes the vocabularies based on characteristics like extensibility, security, and maintainability, fit with the enterprise technical environment, strategic vendor alignment and key technical characteristics.
The enterprise business fit focuses on the ability of the vocabulary to fulfill the requirement of a wide scope of business processes within your company and with its partners.

Perform requirement gap analysis between the project’s transaction requirements and the short-listed standards to decide the recommended standard. If the requirement gap analysis does not lead to a clear choice, other standard characteristics could be used to qualify the selection.

Once an XML standard is chosen, any XML schemas created in subsequent steps should adhere to this XML standard as much as possible.

3.1.2 Data Mapping

The data mapping activity establishes the relationships between the source system data elements, target system data elements and the canonical. When a business transaction occurs, this activity defines what data is passed between systems, and how that data must be transformed in the middleware layer.

See the TBI Methodology – Logical Design Document Template for more details related to the data mapping worksheet.

Note that a separate data map should be created for each source --> target system combination. If a message is being published from a single source to multiple targets, a separate data map should be created for each source-target combination.

3.1.3 Schema Definition

This activity creates the XML schema that defines the canonical or business object. The XML schema then is used to create the Universal Data Model (UDM) in the middleware layer.

This activity uses the data mapping from the previous activity. The XML schema should be exhaustive enough to contain all fields that are available from the source system that any target system might be interested in.

The XML schema is defined using one of the following:

· A schema exists in your company’s repository. If this schema can accommodate all fields identified in the data requirements, then it should be used.

· A schema exists in your company’s repository, which can accommodate a majority of the fields identified in the data map. This schema can be extended to fit the remaining fields that are unsupported by the original XML schema.

· If an existing schema cannot be leveraged, then a new XML standard must be selected

· If an existing schema cannot be leveraged and industry XML standards do not meet data requirements, then a XML schema must be created from scratch.

See the TBI Methodology – Logical Design Document Template for more details.

3.1.4 Integration Test Design

Integration test design activity involves designing a set of test cases using the logical design document. These test cases will be used for integration and system testing to verify interface functionality.

These test cases are based on the logical design to ensure that the design is functional and accurate. They focus on data and the process paths within the interface.

The integration test design activity may not be applicable in all situations. In those instances, system testing may be sufficient to deliver the required quality for the integrations.

See the TBI Methodology – Integration Test Cases Template Document for examples of integration test cases.

3.2 Architecture

3.2.1 Architecture Analysis

The architecture analysis activity occurs in parallel to the logical design activity during the Design phase. In this activity, the co-ordination pattern for interfaces is chosen, decision on adaptors is made, and architecture is recommended. These architecture decisions drive physical design decisions and help in determining candidates for a simulation/design of experiments.

The following activities occur within the architecture analysis activity:

Conceptual (logical) architecture of systems along with the relevant middleware components is created. This layout is high level, and does not include physical machine specifications, or physical machine locations.
Coordination pattern for each integration is determined. The coordination pattern describes the nature of the communication (the systems either communicate synchronously, which describes a request / reply coordination pattern, or asynchronously, which describes a publish / subscribe coordination pattern).
The method of communication between the middleware tool and the applications is determined. This could be a JDBC database connection, the exchange of text file, a program API that already exists, etc. Each system is analyzed and the appropriate communication method is chosen for each.
Approach for error handling, monitoring, logging, and reprocessing is created
Approach for architecture review and code review is discussed
Security considerations are addressed

3.2.2 Simulation (Design of Experiments)

This activity is used to determine if the architectural approach recommended in the previous activity is viable. This is not mandatory, but is strongly recommended in the following scenarios - if any of the systems being integrated are new to the company, if this the first integration project, or if the method of communication chosen in the previous activity has never been used before.

This activity has the following benefits:

Proves that the functionality of the middleware is sufficient to provide connectivity between the systems.
Shows that the performance of the application and the middleware is acceptable.
Helps the team to understand how errors are handled and how quickly and easily administrators can re-invoke integrations
If a particular architectural approach proves to be invalid, a new approach can be created at an early stage in the project

3.3 Deliverables

The following are the deliverables that are produced during the design phase:

Deliverable	Description
Logical Design	The high level design document containing the XML schema standard selection decision, data level mappings, message schemas, and a list of valid values for each message field.
Architecture Analysis document	The architecture analysis document summarizes the high-level system topology, adaptor selection, architecture recommendation, and approach for error handling, monitoring, logging and auditing.
Simulation document	This document presents the simulation approach, details, and results.
Integration test cases	The integration test cases are written based on the logical design to ensure complete coverage of all logical design elements (data mappings, etc.)

⁴^Build

The third phase of the TBI methodology is the “Build” phase. The purpose of this phase is to develop the integration services, complete the technical documentation, and to execute test cases.

Level 2 phases: Integration Design, Coding, and Testing.

This process is followed during the Build phase:

Figure 4 - Build Phase Process Flow

4.1 Integration Design

4.1.1 Integration Design

The integration design activity involves development of physical code level design for the interface points that make up the integrations. This document serves as a development guide and can be handed off to a developer to code from. The integration design also is used to create unit test cases (test cases that test an individual interface point).

The logical design, architecture analysis, naming standards and best practices documents are used to create the physical design for the integration. Typical elements contained in an integration physical design are:

Package, folder, and service naming
Integration document flow
Specifies what integration components are needed, and the specific functions of each component.
Specifies how error handling and audit logging is performed.
Specifies how security is to be implemented for this interface point.

Refer to the TBI Methodology – Integration Design Template Document for more information.

4.2 Coding

4.2.1 Interface Development

During this activity, the developers use the middleware tool to code the interfaces in the development environment. The integration design document is used as an input for this activity.

The following tasks are completed during the interface development activity

Interface code is written as specified in the integration design document.
The code is written to follow the TBI recommended best practices, including adherence to proper naming standards.
The appropriate error handling code is added to all of the places in which error handling is needed.
The appropriate audit logging calls are added to any places where auditing is needed.

At the end of the integration development activity, it is good practice for an outside resource to perform a code review of the code written.

4.3 Testing

4.3.1 Unit Test Design

During the unit test design activity, unit test cases are created. Unit test cases derived directly from the integration design. These test cases will be used during the unit testing stage to verify the integration components function as stated in the physical design.

These test cases are based on the physical design is to ensure that the design is precise and functional. They are based upon the various situations an integration is supposed to handle – success and failure criteria. A test case may reveal a situation that is not handled within the design.

See the TBI Methodology – Unit Test Cases Template Document for examples of unit test cases.

4.3.2 Test Execution

After the integration code has been written, and the unit, integration, and system test cases have been written, testing can begin.

The TBI Project Methodology is based on upon a testing approach that is divided into multiple tiers of testing. All testing phases are included in the Test Execution activity. The phases of testing breakdown as follows:

· Unit Testing: Verifies the smallest units of functionality within an integration.

· Integrated Testing: Incremental testing of interactions between integration components.

· System Testing: End-to-end functioning of the entire process within the context of business process, and includes Source and Target systems.

· Load/Stress Testing : A subset of system test cases are tested under load to ensure that the performance requirements are met/

Note that at this stage, within the Build phase, all of this testing occurs within the integration and application teams. This level of testing does not involve business users, and does not encompass user acceptance testing. User Acceptance testing is covered in the Deploy phase, in the QA activity.

When the integration code is delivered, unit testing begins. When the integration code passes all of the unit test cases, integration testing can begin. When the interface passes all integration test cases, system testing can begin. When system testing is complete, signoff on the system test results can occur, and the code can be deployed into the QA environment, where user acceptance testing begins.

4.4 Deliverables

The following are the deliverables that are produced during the build phase:

Deliverable	Description
Integration Design	Details the physical code design of the interface point(s). In addition, includes naming standards, error handling, and security settings
Source Code and Executables	The source code for the integrations and any executables (run-time code that may have been created).
Code Review	This document summarizes the results, issues, and follow-ups that come out of a formal code review.
Unit Test Cases	The unit test cases are written based on the integration physical design to ensure that the interface point adhere to the integration physical design.
Test Results	This document presents a summary of all of the tests that were run, and the results of these tests. Test Cases for unit, integration and system testing are all run in this phase.

⁵^Deploy

The fourth phase of the TBI methodology is the “Deploy” phase. The purpose of this phase is to make sure that the integrations meet the desired requirements that were outlined in the define phase through quality assurance/user acceptance testing and deploy the integrations in a production environment once the integrations have met the quality standards.

Level 2 phases: Quality Assurance, User Acceptance, and Production.

Figure 5 - Deploy Phase Process Flow

5.1 Quality Assurance & User Acceptance

Depending on the hosting environment, the User Acceptance Testing of the integrations is performed either in your company’s QA environment or a affiliate’s local QA environment. Your group may have processes and documents related to this activity, which describe how integrations must be deployed in the QA environment, and user acceptance testing must be performed.

If affiliate hosts locally, they must use their own processes and documents related to the deployment of integrations.

A checklist is provided here to help a project team to get their integrations ready for deployment in a Quality Assurance testing environment.

Deployment Check List
	All code related to the integrations that needs to be promoted is in the appropriate configuration control.
	Instructions on how to deploy all the integrations in the QA environment must be documented. These documents must also be stored in the appropriate configuration control repository.
	System settings and configuration parameters required for the integrations must be documented and stored in the appropriate configuration control repository.
	System Test cases for testing the integrations in the QA environment must be provided to the team that will perform the testing.
	Error handling guide must be provided to the team that will perform all the testing.
	All updated project documentation must be in the configuration control repository.

5.2 Production

After the integrations have passed User Acceptance Testing, they can be deployed in the production environment. Depending on the hosting environment, the deployment is performed either in your company’s production environment or a affiliate’s local production environment. Your local group may have processes and documents related to this activity that describe how integrations must be deployed in a production environment.

If affiliate host locally, they must use their own processes and documents related to the deployment of integrations.

A checklist is provided here to help a project team to get their integrations ready for deployment in a Quality Assurance testing environment.

Deployment Check List
	Sign-off from quality assurance/user acceptance testing
	All code related to the integrations that needs to be deployed in production is in the appropriate configuration control.
	Instructions on how to deploy all the integrations in the production environment must be documented. These documents must also be stored in the appropriate configuration control repository. (These documents would be the same as the ones created for the QA acceptance.)
	System settings and configuration parameters required for the integrations must be documented and stored in the appropriate configuration control repository. (These documents should be very similar to the ones created for the QA acceptance.)
	Error handling guide must be provided to the operations team that will support the integrations.
	System settings and configuration parameters required for the integrations must be documented and stored in the appropriate configuration control repository. (These documents should be similar to the ones created for the QA acceptance.)
	Error handling guide must be provided to the operations team that will support the integrations in the production environment.
	All updated project documentation must be in the configuration control repository

5.3 Deliverables

The following are the deliverables that are produced during the deploy phase:

Deliverable	Description
Implemented Integration Solution	The interfaces that are deployed in the production environment.
Test Results	This document presents a summary of all of the tests that were run, and the results of these tests in the QA/User acceptance environment.
Lessons Learned	A listing of the significant learning’s that were made during the completion of the TBI Integration Project. This can include but is not limited to: Project Management, Technical Implementation, Quality Assurance, Testing, Communications, etc.

⁶^{Team Staffing}

Projects are structured with a combination of a Project Management Team, and one or more Development Teams depending on the number of integrations being developed.

Figure 6 – Project Team Structure

6.1 Project Manager

The Project Manager provides overall project management, vendor management, strategy and vision, project planning, staffing, change management, and risk management. In addition the project manager is involved in formal deliverables review (review and sign-off of deliverables by the business users).

Project Manager
Define Activities	Deliverables
Define Project	Project Definition
Formal Deliverables Review	Formal Deliverables Review Report
Design Activities	Deliverables
Formal Deliverables Review	Formal Deliverables Review Report
Build Activities	Deliverables
Formal Deliverables Review	Formal Deliverables Review Report
Deploy Activities	Deliverables
Formal Deliverables Review	Formal Deliverables Review Report
Project Closing	Lessons Learned

6.2 Quality Manager

The Quality Manager is responsible for developing and coordinating all testing, coordination with Customer’s testing and quality personnel, and final review of all deliverables.

Quality Manager
Define Activities	Deliverables
CTQ Identification	CTQ Document
Functional Requirements Gathering	Requirements Walk-Through Report
Non-Functional Requirements Gathering	Requirements Walk-Through Report
Data Requirements Gathering	Requirements Walk-Through Report
System Test Design	System Test Plan System Test Cases
Design Activities	Deliverables
Data Mapping	Logical Design Walk-Through Report
Interface Test Design	Integration Test Plan Integration Test Cases
Simulation	Simulation Document
Build Activities	Deliverables
Integration Design	Integration Design Walk-Through Report
Unit Test Design	Unit Test Plan Unit Test Cases
Test Execution	Unit Test Results Integration Test Results System Test Result
Formal Deliverables Review	CTQ Acceptance Signoff
Deploy Activities	Deliverables
Facilitate User Acceptance testing	Test Results

6.3 Architect

The Architect is responsible for architecture design, integration development consistency, technical design reviews, and assistance with strategy and vision of integration throughout the Customer’s enterprise.

Architect
Define Activities	Deliverables
Business Process Flow Analysis Define Project	Project Definition Process and Functional Areas
Use Case Analysis	Use Cases
CTQ Identification	CTQ Document
Functional Requirements Gathering	Functional Requirements
Non-Functional Requirements Gathering	Non-functional Requirements
Data Requirements Gathering	Data Requirements Error Handling Requirements Monitoring Requirements
Design Activities	Deliverables
XML Standard Selection	XML Standards
Data Mapping	Data Map
Schema Definition	XML Schemas UDM Composition Document
Architecture Analysis	Architecture Document
Simulation	Simulation Document

6.4 Business Analyst

The Business Analyst is responsible for reviewing the business processes, gathering of business requirements, data mapping activities, and the creation of the Requirements and Logical Design documentation.

Business Analyst
Define Activities	Deliverables
Process Flow Analysis	Project Definition Process and Functional Areas SIPOC Diagrams
Use Case Analysis	Use Cases
CTQ Identification	CTQ Document
Functional Requirements Gathering	Functional Requirements
Non-Functional Requirements Gathering	Non-functional Requirements Error Handling Requirements Monitoring Requirements Performance Requirements Constraining Requirements
Data Requirements Gathering	Data Requirements
System Test Design	System Test Cases
Design Activities	Deliverables
Data Mapping	Data Map
Interface Test Design	Integration Test Cases
Build Activities	Deliverables
Test Execution	System Test Results Integration Test Results

6.5 Designer

The Designer is responsible for completing the design and documentation of the integration design, technical leadership, and data mapping activities.

Designer
Define Activities	Deliverables
Functional Requirements Gathering	Functional Requirements
Non-Functional Requirements Gathering	Non-functional Requirements Error Handling Requirements Monitoring Requirements Performance Requirements Constraining Requirements
Data Requirements Gathering	Data Requirements
Design Activities	Deliverables
XML Standard Selection	XML Standards
Data Mapping	Data Map
Schema Definition	XML Schemas UDM Composition Document
Interface Test Design	Integration Test Plan Integration Test Cases
Architecture Analysis	Architecture Document
Simulation	Simulation Document
Build Activities	Deliverables
Integration Design	Integration Design
Interface Development	Source Code / Executables Code Reviews Error Handling Guide
Unit Test Design	Unit Test Plan Unit Test Cases
Test Execution	Unit Test Results

6.6 Developer

The Developer is responsible for middleware development and configuration, language-specific development (such as Java), and database development.

Developer
Design Activities	Deliverables
Architecture Analysis	Architecture Document
Simulation	Simulation Document
Build Activities	Deliverables
Integration Design	Integration Design
Interface Development	Source Code / Executables Code Reviews Error Handling Guide
Unit Test Design	Unit Test Plan Unit Test Cases
Test Execution	Unit Test Results

⁷^Governance

7.1 Deliverable Review Process

A strict deliverables review process is enforced by the methodology. This review process improves consistency and quality of deliverables throughout the life cycle. It also provides opportunities for customer review of deliverables early and often, and establishes “base line” checkpoints for Requirements and Design. This process has been implemented as a series of reviews throughout the life cycle, often referred to as “walkthroughs”.

· Internal Milestone Reviews (IMRs) are held within the team to review deliverables, validate completeness, and to reduce costs caused by defects that could be caught before testing (ambiguous requirements, design flaws, missed coding, etc.).

· Formal Deliverables Reviews (FDRs) are held with the customer and organizations like e-advantage, IMDA, etc. to review deliverables, validate that business requirements will be met, and to obtain physical sign-off. FDRs also establish “base lines” of Requirements, Logical Designs, and Integration Designs to aid all involved parties with the management of scope for the project.

The following shows when IMRs and FDRs are scheduled throughout the development life cycle:

Internal Milestone Reviews	Purpose
Define	Review Requirements for completeness, measurability, and testability. Ensure all Requirements have a corresponding System Test Case(s).
Design	Review Logical Design for completeness and standards. Ensure Integration Test Cases represent the Logical Design.
Build	Review of Integration Design for coverage of Logical Design and standards. Review of code for accuracy and enforcement of established standards. Ensure Unit Test Cases represent the Integration Design. Review of testing results after each phase of testing.
Formal Deliverables Reviews	Purpose
Define	Validation of accuracy and coverage of business needs. Approvals and sign-offs are obtained
Design	Approvals of the Logical Design, Architecture Document, and Simulation Document are obtained.
Build	Approvals and sign-offs of CTQ Acceptance are obtained.

TBI Integration Methodology Templates
Define
Business Process Analysis Document	TBI Template - Business Process Analysis.doc
SIPOC Diagrams	TBI Methodology - SIPOC Diagrams.xls
Requirements Document	TBI Template - Technical Requirements.doc
Requirements Walk-Through Report	TBI Template - Requirements Walk-Through Report.doc
System Test Plan	TBI Template - Software Quality Assurance Plan.doc
System Test Cases	TBI Template - System Test Case.xls
FDR Report	TBI Template - FDR Report.doc
Design
Logical Design Document	TBI Template - Logical Design.doc
Logical Design Walk-Through	TBI Template - Logical Design Walk-Through Report.doc
Integration Test Cases	TBI Template - Integration Test Case.xls
Architecture and Deployment Document	TBI Template - Architecture & Deployment.doc
Simulation Document	<Template link to be added>
FDR Report	TBI Template - FDR Report.doc
Build
Integration Design	TBI Template - Integration Design.doc
Integration Walk-Through Report	TBI Template - Integration Design Walk-Through Report.doc
Code Reviews	TBI Template - Code Review.doc
Error Handling Guide	TBI Template - Error Handling Guide.doc
Unit Test Cases	TBI Template - Unit Test Case.xls
Unit Test Results	TBI Template - Unit Test Results.xls
Integration Test Results	TBI Template - Integration Test Results.xls
System Test Results	TBI Template - System Test Results.xls
FDR Report	TBI Template - FDR Report.doc
CTQ Acceptance Signoff	<Template link to be added>
Deploy
FDR Report	TBI Template - FDR Report.doc
Lessons Learned

TBI Integration Methodology Template Samples
Define
Project Definition
Business Process Analysis Document
SIPOC Diagrams
CTQ Document
Requirements Document
Requirements Walk-Through Report
System Test Plan
System Test Cases
FDR Report
Design
Logical Design Document
Logical Design Walk-Through
Integration Test Plan
Integration Test Cases
Architecture and Deployment Document
Simulation Document
FDR Report
Build
Integration Design
Integration Walk-Through Report
Code Reviews
Error Handling Guide
Unit Test Plan
Unit Test Cases
Unit Test Results
Integration Test Results
System Test Results
FDR Report
CTQ Acceptance Signoff
Deploy
FDR Report
Client Satisfaction Survey
Lessons Learned