1. EI Architecture Overview/Current Assessment/Technical Architecture
Chapter 4, 5, 6, GBR

2. Chapter 4 - Enterprise Integration Architecture Overview
Enterprise Integration Architecture is the blueprint for both strategic (WHAT) and tactical (HOW).
It describes all of the components of the architecture.
Focusing alone on tactics will result in higher cost and slowdown business agility. We need a plan
Enterprise integration architecture fits into the overall framework of EA. The big picture
The priority is driven by business requirements and strategies. Not chasing shiny new things. What do you think this means.

3. Chapter 4 - Enterprise Integration Architecture Overview
A strategic enterprise integration architecture is like city planning.
It has building codes
It has governance which is a governing body that ensures projects meet accepted standards and the process of for exceptions.
This approach ensures that current and future technologies are maximized.

4. Components of an enterprise integration architecture
In terms of EA, the domain we will look at is the technology layer or domain.
In the technology domain or layer we discuss the underlying technologies of an enterprise.
In keeping with EA language, this is the basic plumbing that needs to be in place.
Examples of the plumbing (support for components) are messaging, application, interfaces, translation and transformation, routing, and process monitoring and management.

5. Components of an enterprise integration architecture

6. Technical integration architecture
A similar concept is a electric grid. When you buy a toaster, you just plug it in and it works. You don’t need to rewire the whole house just to use your toaster. Ironically, in IT this is what we do.
Part of the reason is the proprietary nature of technology but with the emergence of standards and market pressure we are shooting for the electric grid concept.

7. Service integration architecture
Service integration architecture is inside of or a subset domain or layer of the technology layer or domain.
It defines reusable business services and enables rapid adaption.
The objective here is to enable any program, platform, and data source to be used. Plug and play
Web services and SOA have been huge is this enablement.

8. Information integration architecture
Information integration architecture provides an enterprise wide view of the data contained.
With data being so valuable to an enterprise it is important to maintain it.
If data is mismanaged, it diminish the value of the data. Examples
Metadata is information about the data. (tells you what the data is)

9. Business process integration architecture
Business process integration architecture models its business processes across the enterprise.
The purpose of integration is to improve business processes and increase efficiency. Can be difficult, why?
Business process integration architecture models maximizes agility through quick analysis and view of a process.

10. Organizational structures and architecture governance
Enterprise integration is a journey not a destination. Changes will be made along the way. Enterprises must have a structure that supports this journey. adapt to change
Governance will ensure compliance to the standards and managing exceptions.
This is another way a competency center or EA can provide value by defining the structure, setting priorities, and ensuring compliance through governance. Enforce governance and keep things on track

11. Current integration environment assessment
Chapter 5 GBR

12. Current environment assessment specification document
For this chapter you will get with your groups and create this document.
This exercise should help with your group project and gain experience.
A common mistake in integration is to start with a clean sheet of paper.
This exercise will allow you to identify all the current technology being used in your project.
This document details the current situation and helps design what will be required to move to the desired state.

13. Current Environment Assessment Specification Document
The document you create will have the following information:
Intro – this is an executive overview defining the technologies in use and how it is meeting the business needs, role in the business, and failing to meet those needs.
Purpose – can be copied from book (page 79)
Key Participants – anyone on the team as well as audience.
Scope – defines if the integration is enterprise wide, division, LOB, or other scope.

14. Current environment assessment specification document
Integration technologies – defines all technologies currently being used. The purpose here is to take inventory of the integration infrastructure.
Application and data source interfaces – determines which applications have already been installed.
Integration matrix – a matrix of applications, data sources, and users.
Integration diagram – a graphic representation of the integration.
Security – defines the security that is currently installed.
Conclusion - summary of all key findings and current problems. Also include identification of risks

15. Technical integration architecture specification
Chapter 6 GBR

16. Technical integration architecture specification document
The technical integration architecture specification document will be used to guide all designs.
This document ensures consistency, reusability, and economic benefit to the enterprise.
This chapter should help with you gain experience in an area of growing importance.

17. Technical integration architecture specification document
Introduction – readers should be aware of how this document will be used to guide decisions and design along with governance rules.
Scope - defines if the integration is enterprise wide, division, LOB, or other scope.
Key Participants – anyone on the team as well as audience.
Integration architecture requirements – this section relies on the business requirements and the current integration assessment document. It includes the requirements for the type of integration services and technologies that will be part of the infrastructure.

18. Technical integration architecture specification document
The Integration architecture requirements should include the following:
Types of integration – identifies type of integration from the business strategy and requirements.
Integration services and technologies – rather than letting product selection drive architecture, the architecture should lead the integration. The assessment in the current architecture shows the existing products and can be useful in determine what new technologies should be used in its place.
Integration architecture description – contains two different views:
Conceptual view – provides the big picture of the enterprise integration.
Development view – contains information for the developers of how and when different tools is used to guide the development.

19. Technical integration architecture specification document
Standards profile – includes all the standards that have been adopted by the enterprise that are relevant to the integration architecture. Should include the governance policy and the standards for approving solutions.
Service level requirements - is a broad statement from a customer to a service provider describing their service expectations. A service provider prepares a service level agreement (SLA) based on the requirements from the customer. For example: A customer may require a server be operational (uptime) for 99.95% of the year excluding maintenance.

20. Technical integration architecture specification document
Service level requirements typically have the following sections:
Availability – when integration will take place (real time or batch)
Integrity and delivery of service - descriptions of services required to understand what is offered and affirms what is needed.
Scalability – major factor in planning and capacity needs along with cost of services.
Maintainability and management – defines operational characteristics such as alerts, monitoring, troubleshooting, installation, scheduling, and more.

21. Technical integration architecture specification document
Service level agreements typically have the following sections:
Usability – defines users, types of access, and requirements.
Performance – defines requirements needed to support business.
Security – summarizes all of the security requirements. A separate document made be used to define specific security requirements.
Summary – SLA’s are becoming vital to know and understand with the popularity of the cloud and Everything-as-a-Service (XaaS), examples are software-as-a-service (SaaS), infrastructure-as-a-service(IaaS), and platform-as-a-service(PaaS).