Appendix K. Process Integration Implementation Specification

<ENTERPRISE NAME>

<PLACE LOGO HERE>

<author><version><revision date>

Template Instructions

This is a template for the Process Integration Implementation 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

  1. Review the chapter in the book that refers to the template to understand its use.

  2. Examine the template outline and determine what additions might be necessary based on unique organizational needs.

  3. If absolutely necessary, remove any sections that will not apply. (The authors strongly discourage this practice.)

  4. Save the template for future use.

  5. 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.

Headers and footers should be customized as necessary as a final step in the completion of the document.

Process Integration Implementation Specification

Introduction

<This specification provides implementation guidance for the development of a process integration based solution. It is most likely that the process design specification from Chapter 9 will form the basis for the implementation.

Process integration represents a specific style of integration. It manages the integration from an end-to-end business process level. It is appropriate for business process-improvement initiatives, automating iterations between organizational entities, and implementing industry and compliance solutions.

This section describes the context of specific implementation described by this specification.>

Scope

<The scope of a process integration specification is limited to the business processes that are being automated and integrated. It can include processes within departments or between departments, divisions, territories, companies, and business customers and partners.

In this section, define the scope of the implementation, including all business entities and systems.>

Key Participants

<This section identifies all stakeholders in the implementation; 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. Because there may be multiple managers responsible for parts of the process, continuous process improvement and process optimization will be difficult to achieve without a process owner or manager who is responsible for the end-to-end process. Any other participants or stakeholders should also be identified including their roles.>

Process Integration Patterns and Services

<Process integration is in the very early stages of adoption, and patterns may emerge over time. Reference architectures are provided for the following patterns:

  • Process automation

  • Process activity monitoring

  • Process collaboration

In this section define the particular pattern that is being used and provide details on the configuration of the specific components of the implementation.>

Process Automation

<Process automation requires underlying application integration services. The solution may provide integration services such as adapters, or may provide integration with an EAI solution. Many BPM tools do both in order to provide implementation flexibility.

The services included in process automation include process modeling, process simulation, process management including support for long-lived processes and transactions, business rules management, transaction support including compensating transactions, as well as all necessary application integration services. The following figure depicts an example Process Automation Reference Architecture.

Process Automation

Process Automation Reference Architecture

The Implementation Table specifies all the integration services provided in the Process Automation integration solution, along with relevant implementation details.

Modify the sample following table to specify your implementation.>

Process Automation

Process Automation Implementation Table

Process Monitoring

<Process monitoring, also called business activity monitoring (BAM), provides real-time visibility into business processes. BAM can be part of a business process management solution or it can be a stand-alone solution.

The services provided by BAM include a management dashboard with key performance indicators relevant to particular roles in the organization, real-time analytics to populate the dashboard, and the underlying agents or event managers to recognize relevant events. It has some information integration capabilities to pull information from analytical data stores in real time. A BAM solution may also contain modeling or development capabilities to define the BAM solution, as each one is likely to be unique.

Because the BAM market is young and evolving, the current solutions have different focuses and configurations. In this section, define the services included in your BAM solution. The following figure is a sample reference architecture that is likely to evolve significantly as the market matures.

Process Monitoring

BAM Reference Architecture

The Implementation Table specifies all the integration services provided in the BAM solution, along with relevant implementation details. Modify the following table to specify your implementation.>

Process Monitoring

BAM Implementation Table

Collaborative Process Integration

<Collaborative process integration provides a platform for integrating work from different team members in different locations. Collaborative solutions include a collaboration portal that provides access to all project artifacts including deliverables, meeting notes, discussions, etc. A project repository is important for managing project artifacts. The repository can be part of the collaboration platform, or may integrate with a content management solution. Version control with check-in and check-out facilities can either be part of the platform or provided through integration with a content management system or a version control system (especially important for software development as the code is often managed by an existing version control system). The solution can also be a combination of both.

Project management may also be provided by the platform, or it can integrate with a project management system. Workflow is often included as part of the platform to manage the collaborative process. Project coordination is provided with electronic calendar and meeting scheduling. A facility to support threaded discussions and negotiations, and document decisions is also helpful. Because much project communication is done through e-mail, which is particularly difficult to anage and archive, e-mail integration is becoming more important. The collaboration platform should include role-based security with granular levels of authorization, so access rights can be defined artifact.

As process collaboration integration becomes more firmly entrenched in the organization the architecture is likely to evolve. The following figure is a reference architecture based on the major capabilities currently available.

Collaborative Process Integration

Collaborative Process Reference Architecture

The Implementation Table specifies all the integration services provided in the collaborative integration solution, along with relevant implementation details. Modify the following table to specify your implementation.>

Collaborative Process Integration

Collaborative Process Integration Table

Conclusions and Recommended Next Steps

<This section should provide any final comments on implementation.>

Appendix A: References

<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.>

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset