Enterprise Integration Group Project Technology Term Paper

Enterprise Integration Group Project: Project Information
Overview
The purpose of this group project is to understand the steps and holistic approach towards the development and integration of an enterprise system. The group will evaluate and understand the strategic direction of the given organization at its core and document the foundations of what drives its purpose. The goal is to familiarize the team with both an external and internal process evaluation in order to provide a comprehensive view of all system components. Overall, the group should understand that the purpose of any system integration is to provide an organization with competitive advantage while leveraging the technology it already has or needs to obtain. The group must use the enterprise integration project template document (Enterprise Integration Project part 1.docx) by building milestones throughout the semester.
For Milestone 1 ONLY, produce a Summary of a chosen AWS Case Study.

Make sure your summary includes the following elements:
1. Executive overview
2. Organization background/summary/vision/mission
3. Organizational chart and culture summary
4. Policies and procedures summary (Governance)
5. Group MOU
6. Project plan
Please read the following Amazon Case Study below and complete the corresponding deliverables for each of the milestones given.
https://aws(dot)amazon(dot)com/solutions/case-studies/netflix-kinesis-streams/?trk=cr_card

Business Drivers and Enterprise Integration Strategy

<Project Name>

<authors>
<version>
<revision date>

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. Each project group should:

• Adjust the template adding or removing template content based on unique organizational scenarios
• Guidance is given for preparation of the document throughout the template.
• Text shown as normal text should be used in the document modified as necessary.
• Text shown in pointed brackets is either instructional guidance or a description of the type of information that should be added or 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.

1.      Introduction / Executive Overview.......................................................................................... 4

2.      Scope and Purpose..................................................................................................................................... 4

3.      Key Participants........................................................................................................................................ 4

4.      Statement of Purpose........................................................................................................................... 5

5.      Cost Estimates............................................................................................................................................. 5

6.      Return on Investment (ROI)................................................................................................................ 5

7.      Metrics............................................................................................................................................................... 6

8.      Conclusions and Commentary........................................................................................................ 6

9.      Integration Strategies....................................................................................................................... 7

10.         Mapping to Business Strategies and Initiatives.......................................................... 7

11.         Strategic Sourcing............................................................................................................................. 7

12.         Standards.................................................................................................................................................... 8

13.         Metrics.......................................................................................................................................................... 8

14.         Risks................................................................................................................................................................. 8

15.         Conclusions and Recommended Next Steps..................................................................... 9

16.         Integration Technologies.......................................................................................................... 9

17.         Application and Data Sources Interfaces..................................................................... 10

18.         Integration Matrix......................................................................................................................... 10

19.         Integration Diagram...................................................................................................................... 11

20.         Security..................................................................................................................................................... 11

21.         Conclusions and Commentary................................................................................................. 12

Appendix A: References................................................................................................................................ 13

1. Introduction / Executive Overview

The Business Drivers and Requirements Specification is the document that defines the drivers, goals, scope, and metrics that measure success, potential business benefits, and ROI of the investment.  <The introduction should be a short executive overview of the specification. In addition, any special aspects of the project should be addressed, including the sponsoring organizations and business champion. A history of the initiative would be helpful as well. At the end of this section the reader should have an understanding of how the business drivers and requirements evolved.>

Introduction also defines the current information technology environment as it pertains to the business integration strategy and architecture as of <<date>> for <<enterprise>>. <The introduction to the Current Environment Assessment should be a short executive overview of the specification. It should define the types of technologies that are being defined and any major constraints in the current environment, such as limitations imposed by legacy systems or the requirements for high security.>

Introduction 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?>

1. 2.      Scope and Purpose 

<This section defines the scope of the Business Drivers and Requirements Specification, specifically whether it is enterprise wide, or for a specific business unit or business initiative.> <The scope also defines how the business integration strategy covers integration across the entire enterprise, 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.> <This purpose section should document and assess the current integration technologies that support the business functions of the enterprise. This assessment will be used when determining recommended technologies and vendors in the Integration Architecture Document.>

1. Key Participants

<This section identifies all stakeholders in the requirements process, including business managers, the sponsoring organizations and business champions, and the owner of the proposed initiative.>

<Include an organizational chart that documents the relationships between key participants.>

<There are five 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 be implement and apply the strategy.
• Approvers of the strategy.
• The team responsible for the creation of the current environment assessment 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 audience of this document; include how they will apply it to their work.>

Business Drivers and Requirements Specification

1. Statement of Purpose

<The Statement of Purpose is a succinct specification used to communicate the business goals and functions of the initiative. It makes the business case for the initiative. It does not include implementation of technology.>

1. Cost Estimates

<This section lists high-level costs and an estimated time frame. Costs at this point should be a rough order of magnitude and used for budgeting purposes and estimating ROI. It must be understood that these will be refined in the follow-on phase with the next level of detail.>

1. Return on Investment (ROI)

<This section documents the potential or expected ROI for the business initiative under consideration.You can use the template to guide your assessment of an ROI for the integration initiative.>

1. Metrics

<Metrics are used to measure the success of the initiative and are created by turning business goals into measurable Key Performance Indicators (KPIs). For each goal there can be more than one metric.>

1. Conclusions and Commentary

<This section should provide any final comments on requirements. It should include any known constraints or other business factors that could affect architecture, design, and implementation decisions.>

Enterprise Integration Strategy

1. Integration Strategies

<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. The matrix below also includes best practices in integration strategies. Use the template as a guide for defining your particular set of integration strategies.>

10.  Mapping to Business Strategies and Initiatives

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

11.  Strategic Sourcing

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

12.  Standards

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

13.  Metrics

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

14.  Risks

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

15.  Conclusions and Recommended Next Steps

<This section should complete the document with any major conclusions as well as any recommended next steps or approved management actions. This document will be used throughout the project(s) to guide and evaluate the results.>

Current Environment Assessment

16.  Integration Technologies

< This section should define the boundaries for the current environment assessment. Does it cover the entire enterprise or only a segment? It should cover internal as well as external assets.> < This section should also identify the integration technologies that are used by the type. It should describe the specific vendor technology and the applications that are connected using the technology. If there are technologies that are purchased but not used (shelfware) this should be identified as well.>

17.  Application and Data Sources Interfaces

<Using the information on applications or data sources from the prior section’s interfaces should be described in detail. This section should list all integrated applications or major data stores and connector information. The objective is to determine which applications or data stores already have installed adapters or other interfaces. An effort should be made to determine the reusability of the interface.>

18.  Integration Matrix

<This section gives a unified view of the current environment’s integrations, first by purpose and second by technology. Where there exist multiple integrations between each application, place all the descriptions of the purpose and each individual technology in the cell making sure there is a clear identification between the purpose and technology.>

19.  Integration Diagram

<A diagram should be placed here that is a schematic of the current environment, identifying the current configuration including the servers, systems software versions, application software, adapters, databases, integration software, networking, administrative, and security systems. It may not be possible or desirable to have a single diagram; each diagram should be included. For example, there might be a separate physical network diagram and security diagram. There may need to be several diagrams of the applications, due to complexity. All diagrams should be clearly marked. In addition, any supporting diagrams that already exist should be included.>

20.  Security

<Security is defined separately because of the complexity and the importance of this topic to integration. In this section, a description of the security requirements and the implementation approach for each type of data, application, or process will need to be identified. >

21.  Conclusions and Commentary

<This section is a summary of all key discoveries found during the assessment process. This should include any areas of risk identified, such as holes in security or hand coded interfaces, and what will not scale and cannot be easily changed. This section should also note any areas of technical redundancy, such as multiple messaging technologies or multiple integration brokers already installed. Finally, any current problems that involve end users’ use of the existing systems should also be captured.>

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