<ENTERPRISE NAME>
<PLACE LOGO HERE>
<author><version><revision date>
This is a template for the Technical 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.
Technical Integration Architecture Specification
<This document represents the technical integration architecture specification that will be used to guide the integration of applications for <<enterprise name>>. This document is to guide all decisions and designs related to integration in the organization to ensure that there is consistency, reusability, and economic benefit to the organization.>
<Define the scope of the technical integration architecture. It should address whether it is enterprise-wide or limited to a certain organization or class of applications. Other areas to address include types of integration (data, application, or process), any limitations, and reasons for the limitations. The scope must also describe what types of external applications are covered, for example, applications outside the scope of the enterprise that are candidates for connecting to enterprise applications.>
<Define the audience and major stakeholders. The audience should include all members of the IT organization; however, it should explicitly list out specific roles or titles that are to apply the integration in the normal execution of their jobs. The major stakeholders should include the IT executives and those responsible for maintaining the document.>
<The types of the integration to be performed needs to be defined. The data from the prior section is used to extrapolate the requirements for this section. Define which types of integration to determine scope of investment.>
<Discuss the role of different types of components to the overall strategy. This section guides technology selection for specific projects. Include preferred vendors and solutions and any technologies for which the company has enterprise licenses. List the different types of integration services and the technologies that can be used to implement the service.
Figure 5-3, which was constructed during the assessment of the current architecture and shows existing products in the organization, is used as the basis for determining whether the preferred vendor or technology is currently installed.>
<The Architecture Description contains two different views: the conceptual view and the development view.>
<The conceptual view shows all of the components and their relationships. This conceptual view can be drawn in a number ways. For example, it could be shown as a layered architecture with the lowest level protocols shown above TCP/IP, and at the highest level the applications and how they connect into the system. Furthermore, the layers could be split to show how the layers fit into the server architecture. For example, the services would be shown on different servers than the adapters or interfaces. Each application would be shown dependent on the servers or mainframes on which they reside. The conceptual view would demonstrate how they fit together and the relationships inside and outside the firewall.>
<The development view is a description of how and when each of the different tools and interfaces is used, to guide the development team utilizing the integration architecture. For each and every aspect of the integration architecture, there must be a description of how a developer may apply the architecture. This would include the languages supported and the manner in which services and capabilities are accessed, tools for developing any integrations, and tools for configuration and administration. Additionally, standard interfaces available for use should be defined.>
<This section specifies all standards that have been adopted by the organization that are relevant to the integration architecture. The full specification should also include a governance policy that defines how compliance with standards will be managed, and the process and guidelines for approving solutions that do not comply with standards.>
<Service level requirements include availability, integrity, scalability, maintainability, manageability, usability, performance, transaction services, persistence, and directory services.>
<There are two types of availability metric: system availability (8 × 5, 24 × 7), and availability of integration (real time, periodic, or batch). This metric defines when the information that has been integrated is available for use.>
<Integrity of integrated information rests on the integrity of the transmission as well as the integrity of the information being processed. Transmission integrity is ensured by transmission services such as guaranteed delivery, once-and-only-once delivery, and persistent message stores. The integrity of the information processes is dependent upon the validity of the translation and transformation process and the processing of the information by the target system. This metric can be measured in error rates.>
<Scalability requirements determine the type of architecture as well as the technologies selected for implementation, and are a large factor in capacity planning and purchasing. The scalability requirements must be defined for the expected needs of the organization in the short term as well as the longer term. Scalability requirements can be defined by the following parameters:
Amount of information to be passed
Transaction rates (time/volume)
Number of applications to be integrated
Simultaneous end-user connections
Maintainability and management requirements can be defined by the following services:
Monitoring and alerting
Startup, shutdown, and restart
Troubleshooting and level of support
Maintainability of code and use of tools
Installation and managing release of updates and ability to rollback
Scheduling
Integration with existing tools
After determining manageability requirements, we recommend summarizing them for the purposes of enterprise planning. Assigning a manageability requirement rating to each application or project can do this. This rating provides a summary view of all manageability requirements. The following rating can be used:
<Usability refers to how easily each type of user will use the system. Define all types of system users, along with the type of access and usability they require. The table below can be modified or expanded as needed.>
<Performance requirements define the level of service the infrastructure needs to provide to support business users, processes, and transactions. Performance requirements are also used in the Capacity Planning View (section 9 of this template).>
<Transaction services include distributed transaction support and XA standard transaction compliance. This information determines how transactions will be managed and how transactional integrity will be maintained. This section also defines requirements for supporting industry and regulatory standards such as RosettaNet, HIPAA, or other industry standard transactions.>
<Persistence is required for improved reliability when recovering from a failure. Being able to re-start a failed system without losing any in-process integrations is the most basic use of a persistence service. Other types of uses for persisted data include the ability to rollback any actions, perform audits of activity, or to use the collected data to analyze activity on the infrastructure. This section defines the requirements to provide storage of the integration data and state information during and after any use of the integration infrastructure.>
<Directories can provide location transparency by allowing applications to “find” other applications for integration. They can store configuration information on resources or users that can be used by any application or integration process. Finally, a directory can be used to store security information. The table below depicts the types of information to specify for directory services.>
<Security is a type of service-level requirement, but it is such an important topic and a highly specialized topic that it is dealt with separately. The specification should start by summarizing the top-level security requirements by the categories or types of applications that will be utilizing the architecture. This can be done in a general manner, as shown in the following table, but it is more effective if it can be specifically defined.>
<Authentication services confirm the identity of a user. A detailed specification of authorization service requirements includes the following:
List of user types. User types should correlate to the types of applications or services a group would access. Examples include: designers, programmers, managers, line-of-business users, customers, and partners.
Level of authentication for each type of user or role. Levels of authentication may include: password, password with public/private key encryption, digital certificate, or biometrics.
Whether unitary login will be supported. Unitary logic defines whether authentication can be performed once for all applications and services. This requires a centralized directory for all services.
Definition of how user accounts will be managed. User accounts must be constantly created and updated based on the changes that occur in the business. It is important to have a formal process defined on how this information will be kept synchronized.>
<Authorization levels determine what operations a user or process is authorized to perform on a set of data or within an application. This section defines categories for authorization, based on application and/or sensitivity of data. Authorization is usually defined in a CRUD matrix that defines rights to Create, Read, Update, or Delete information.>
<This section should address how the integration architecture will work with perimeter security and the types or categories of integration that will be required to use the perimeter security features. Perimeter security is the combination of firewalls, encryption, authentication services, and architecture to protect the enterprise from the outside world. The configuration of the perimeter security will dictate the design of the integration architecture as it relates to external usage.>
<This section defines categories for auditing based on the type of application and the sensitivity of the data being processed. Basic categories of auditing are:
Level 0. Maintain no information
Level 1. Maintain information on type of interaction and participants
Level 2. Maintain only instructions for each interaction
Level 3. Maintain a complete set of information on every interaction
Performance and resource requirements are the tradeoffs in making a distinction between each level.>
<Confidentiality refers to the level of privacy that a transmission requires. Confidentiality usually applies to the level of encryption that is applied, but could also be reflected in the communications path that is used.>
<This section specifies the design approaches to achieving specific application-required responsiveness, throughput, capacity, reliability and availability, and scalabiliy. The information from Service Level Requirements is the input to capacity planning. The goal is to define how all service level requirements will be met.>
<All constraints and specific guidance for architects, designers, and developers should be defined at this point. Some areas to be considered in the setting of constraints and guidance are
Known performance limitations
Formatting guidelines for data
Constraints on metadata definitions and registration
Preference on use of different types of interfaces
Special cases of security implementations
Deviations allowed from the integration architecture>
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.