<ENTERPRISE NAME>
<PLACE LOGO HERE>
<author><version><revision-date>
This is a template for the Process Integration Architecture Specification. This page should be removed prior to publication of the specification. The template is a guide for the enterprise and should not be blindly followed. The organization should
Review the chapter in the book that refers to the template to understand its use.
Examine the template outline and determine what additions might be necessary based on unique organizational needs.
If absolutely necessary, remove any sections that will not apply. (The authors strongly discourage this practice).
Save the template for future use.
Begin to develop the document.
Guidance is given for preparation of the document throughout the template.
Text shown as normal text should be used in the document. It may be modified as necessary.
Text shown in pointed brackets is either instructional guidance in the application of the document or a description of the type of information to be added and should be removed prior to publication.
Text shown in double-pointed brackets is a placeholder for the insertion of text by the authors.
Headers and footers should be customized as necessary as a final step in the completion of the document.
Process Integration Architecture Specification
<This specification provides the design guidance applying a process-driven approach to integration for <<system name>>. This document is a guide to creating the process specification for the composite applications or process driven business solutions.>
<The scope of a process specification is limited to an integration project. The document should define the business processes and the underlying integration architecture. The scope should describe the breath of business processes covered as well as the systems involved in the process.>
<This section identifies all stakeholders in the business process(es) being integrated, including business managers who control all or part of the process, system designers and architect(s), and the development team who will execute the implementation. Any other participants or stakeholders should also be identified including their roles.>
<This section identifies and describes all of the business processes that have been identified in the requirements. A name and a business owner identify each business process. A description of the process is provided along with the event that kicks off the process, the business services that are part of the process, and the outcome expected to end the process. If no services have been defined, then define the functions performed as part of the process. To identify the business processes that need to be defined as part of this specification, start with the Statement of Purpose and the scope of responsibilities defined in the Business Strategies and Initiatives Specification (Chapter 2).>
<A process flow model is a combination of the event(s) that start the process, actors involved throughout the process, services provided by software components in the system, the messages passed between and among services, and the business rules controlling the flow of the process. Each process flow model should have a description of each of these entities, as well as a process diagram.
If a process modeling tool is used to create this part of the specification, add a reference to the tool and file. If your tool provides browser-based access to models, then place the URL here along with a description.
There are many methodologies for designing and depicting process flows, including data flow diagrams and IDEF diagrams.>
<Process design reviews are critical to the overall success and agility of the system. The design reviews should include all relevant stakeholders, defined above in the key participants section. All parts of the model need to be reviewed and verified. Participants need to verify the portions of the process they are responsible for, including all tasks, functions and/or services, inputs to and outputs from each service, decision points along the process, and business rules that determine the process flow of control, as well as all exception and compensation rules. The overall process should be reviewed for opportunities to decrease time and cost and increase business flexibility and advantage.>
<The appendix should list any reference documents used in the creation of the document so that its contents can be traced back to their sources if necessary. This should be broken down into internal documents and external documents. Internal documents are those that belong to the organization. External documents are items such as articles, whitepapers, Web sites, or product documentation.>