<ENTERPRISE NAME>
<PLACE LOGO HERE>
<author><version><revision date>
This is a template for the Business Integration Strategy 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.
Enterprise Integration Strategy Specification
<The introduction should be a short executive overview of the specification. It should answer the following questions:
How will the integration strategy support business needs?
Are there any major constraints, such as limitations imposed by legacy systems, or requirements, such as the need for high security, that are a major factor in the integration strategy?
What are the anticipated benefits of the strategy?>
<The scope defines whether this strategy covers integration across the entire enterprise, a division, a line of business, or some other scope. The types of applications involved determine the scope of the integration strategy, and the methods of integration required. The scope should not be defined in terms of technological boundaries. For example, a strategy for the communication network is inappropriate.>
<There are three types of participants that should be identified:
The team responsible for the creation of the strategy in its initial form, as well as for any on going improvements. Anyone that provided information or review should be included in this list.
The group who will implement and apply the strategy.
Approvers of the strategy.>
<Companies must identify the strategies by which the enterprise can use technology to maximize competitive advantage. Key integration strategies include service-oriented and process-driven architectures. Business goals defined in the Statement of Purpose (Business Drivers and Requirements Specification, page 271) should be front and center when defining integration strategies. The matrix below can be used as a guide for defining your particular set of integration strategies.>
<This section provides a mapping between business initiatives defined in the Business Strategies and Initiatives Specification and integration strategies in the form of a matrix. Discuss nonobvious points of support. If any row or column is blank (i.e., a business strategy has no integration strategy to support it or an integration strategy supports no business strategy), discuss the implications. Any budgeting for projects that has been done to date or expected allocations should be included at this point. This reflects the IT organization's portion of the budget allocated to this initiative. Rank projects in importance to company, to prioritize infrastructure investments.>
<This section describes the approach that the organization feels will be most effective to acquiring any technology. It should set the philosophy, constraints, and approach to sourcing. Issues to be dealt with are the existing relationships and current use of technology, vendor preferences, best-of-breed versus single vendor, responsibilities for identifying and selecting as well as negotiating contracts. It should define the following:
Preference for best of breed approach versus single vendor or platform approach versus two or three preferred vendors
Preferred vendors for each type of technology
Procurement process (this part of the specification may point to another internal document)>
<The intention of this section is to define an enterprise strategy for how different types of standards will be used in the architecture. This strategy forms the basis for the integration architecture.
The standards that can be defined in an integration strategy are shown on the chart. One of the purposes of this section of the strategy is to decide which standards to define at an enterprise level.>
<Metrics that measure the success and relative value of an integration strategy should be defined. Metrics should be tracked over time and used as input when refining the strategy and determining future infrastructure investments. To be of use, each metric must be measurable and manageable. The effort to collect and track a metric cannot exceed the value of the information it provides. Owners are responsible for tracking and reporting on metrics.
Specific metrics that can be employed are tracking reuse, tracking the time to implement new solutions or implement changes to existing systems, tracking savings from reducing redundancy, and monitoring TCO of a system.>
<The risk section defines everything that can or might go wrong. It may also include a list of assumptions that might be wrong or need further information to be validated. This includes the organizational, cultural, technical, or management challenges and ability to achieve the desired business results. Each risk should be associated with a plan to mitigate the risk.>
<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.>