Service-Oriented Enterprise Integration Tools and Techniques Chris Peiris

Service-Oriented Enterprise Integration: Tools and Techniques Chris Peiris www. Chris. Peiris. com 11 Oct 2006 © Chris. Peiris. com

Agenda n Enterprise Architecture ¡ n n Enterprise Architecture Models Integration Technologies ¡ ¡ n Demo 1 EAI, ETL, EII Demo 2 Service oriented Architecture 11 Oct 2006 © Chris. Peiris. com 2

Enterprise Architecture n “Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate” n “A logically consistent set of principles, practices, policies, models, standards and guidelines that are derived from business requirements, that guide decision-making and the engineering of an organization’s information systems and technical infrastructure. ” (WA. State ISB EA Committee ) 11 Oct 2006 © Chris. Peiris. com 3

Demo 1 n n Need to model Enterprise Architecture? Key Takeaways ¡ ¡ n Collaboration of 40 small companies 40 different software platforms / technologies / “way of doing things” How do we models all these? 11 Oct 2006 © Chris. Peiris. com 4

EA Model / Framework n A general Enterprise Architecture (EA) framework provides general high-level views for the separation of enterprise level concerns for use in any industry or project. In effect, the EA aims to provide the ability to view complex systems underlying organisations from a high-level to aid in analysis and understanding during strategic planning. 11 Oct 2006 © Chris. Peiris. com 5

EA Models n Enterprise Architecture Frameworks ¡ ¡ 11 Oct 2006 Zachman Enterprise Architecture Model Federal Enterprise Architecture Framework (FEAF) The Open Group Architecture Framework (TOGAF) Treasury Enterprise Architecture Framework (TEAF) © Chris. Peiris. com 6

What do they discuss? n n How an enterprise should function For an example Zachman addresses, ¡ ¡ ¡ n What (Data) How (Function) Where (Network) Who (People) When (Time) Why (Motivation) Answers them in the context of ¡ ¡ Contextual (Scope) Conceptual (Business Model) Logical (System Model) Physical (Technology Model) (Zachman, 1987) 11 Oct 2006 © Chris. Peiris. com 7

Zachman Model n The Zachman Framework first published in 1987, defines a logical structure for the classification and development of specific models (i. e. design artefacts) required in the management and operations of enterprises, including the development of supporting enterprise information systems. Together the inter-related models in the framework separate enterprise specific concerns (e. g. function, data, network e. c. t. ), providing a holistic enterprise. 11 Oct 2006 © Chris. Peiris. com 8

Zachman Framework 11 Oct 2006 © Chris. Peiris. com 9

Zachman Framework n Row 1 – Scope External Requirements and Drivers Business Function Modeling n Row 2 – Enterprise Model n Row 3 – System Model Business Process Models Logical Models Requirements Definition n Where Who When Why Contextual 2 Conceptual 3 Logical 4 Physical Row 6 – Functioning Enterprise 5 As Built Functioning Row 4 – Technology Model Row 5 – As Built Deployment n How 1 Physical Models Solution Definition and Development n What Functioning Enterprise Evaluation 11 Oct 2006 6 © Chris. Peiris. com What How Where Who When Why 10

Federal Enterprise Architecture Framework (FEAF) n The Federal Enterprise Architecture Framework (FEAF) aims to provide a comprehensive “business-driven blueprint” of the entire Federal government including its functions and IT infrastructure. 11 Oct 2006 © Chris. Peiris. com 11

Treasury Enterprise Architecture Framework n The Treasury Enterprise Architecture Framework (TEAF) is framework developed specifically for the U. S. Department of the Treasury and its bureaus in order to aid in performing strategic planning / investment management, and to provide direction for the development of enterprise architectures tailored to the needs of the U. S. Treasury Department and its bureaus. The framework had been developed with the Federal Enterprise Architecture Framework (FEAF) and Zachman Framework as its basis 11 Oct 2006 © Chris. Peiris. com 12

The Open Group Architecture Framework (TOGAF) n Originally designed as a way to develop the technology architecture for an organization, TOGAF has evolved into a methodology for analyzing the overall business architecture. The first part of TOGAF is a methodology for developing your architecture design, which is called the Architecture Development Method (ADM). It has the following nine basic phases: Preliminary phase: Framework and principles. Get everyone on board with the plan. ¡ Phase A: Architecture vision. Define your scope and vision and map your overall strategy. ¡ Phase B: Business architecture. Describe your current and target business architectures and determine the gap between them. ¡ Phase C: Information system architectures. Develop target architectures for your data and applications. ¡ Phase D: Technology architecture. Create the overall target architecture that you will implement in future phases. ¡ Phase E: Opportunities and solutions. Develop the overall strategy, determining what you will buy, build or reuse, and how you will implement the architecture described in phase D. ¡ Phase F: Migration planning. Prioritize projects and develop the migration plan. ¡ Phase G: Implementation governance. Determine how you will provide oversight to the implementation. ¡ Phase H: Architecture change management. Monitor the running system for necessary changes and determine whether to start a new cycle, looping back to the 11 Oct 2006 preliminary phase. © Chris. Peiris. com 13 ¡

Agenda n Enterprise Architecture ¡ n n Enterprise Architecture Models Integration Technologies ¡ ¡ n Demo 1 EAI, ETL, EII Demo 2 Service oriented Architecture 11 Oct 2006 © Chris. Peiris. com 14

Enterprise Integration is required at all levels n Need for databases to exchange information ¡ n Need for applications to exchange information ¡ ¡ n Provides data consumers with an integrated view of disparate data Within organizations and between organizations Often times involves legacy technologies Need for organizations to exchange information ¡ ¡ ¡ 11 Oct 2006 Structured and unstructured business process dependencies Bulk data exchange Reporting © Chris. Peiris. com 15

Integration Products Available n n Why build when you can buy? Build less and connect more Category Enterprise Product Data Mgmt/Demand Planning Manugistics Back Office (ERP) SAP, Oracle, JDE, Manugistics… Axapta, Great Plains Front Office (CRM) Siebel, SAP MS CRM, Salesforce. com Connecting Partners (SCM) ERP Vendors, I 2 SMB ERP… Legacy IBM Mainframe… Unix, VAX, AS/400 Vertical / Company Specific ISVs, Build 11 Oct 2006 Small to Medium © Chris. Peiris. com 16

Integration Categories n n n Enterprise Application Integration Extract Transform and Load / Extract Load and Transfer Enterprise Information Integration 11 Oct 2006 © Chris. Peiris. com 17

EAI n Enterprise Application Integration (EAI) ¡ ¡ n Message based High Frequency Real Time Application to Application Vendor Implementations ¡ ¡ ¡ 11 Oct 2006 IBM Web Sphere Message Broker Microsoft Biztalk Server Web Methods BEA Web Logic MS, IBM, Java Web Services Implementations © Chris. Peiris. com 18

ETL / ELT n Extract Load Transform (ELT) or Extract Transform and Load (ETL) ¡ ¡ ¡ n Bulk Transactions / Batch Database to database Low frequency / high latency Vendor Implementations ¡ ¡ ¡ 11 Oct 2006 IBM Data. Stage Microsoft SQL Server Integration Services Seibel EIM © Chris. Peiris. com 19

EII n n User Interface driven Person to Person – to assist senior management. Real Time Vendor Implementations ¡ ¡ ¡ 11 Oct 2006 Seibel Microsoft Workflow Foundation Biztalk Server Orchestration © Chris. Peiris. com 20

Demo 2 n n Enterprise solution that uses multiple products to assist business processes. It uses Microsoft Info. Path, Biz. Talk, ASP. NET Web Services, RPG on an AS/400, CICS on a Mainframe, J 2 EE on Web. Sphere, Pocket PC, SQL Server, Speech Server, and Microsoft MOM. Question : Which integration strategies are we using? Introduction to SOA… 11 Oct 2006 © Chris. Peiris. com 21

Agenda n Enterprise Architecture ¡ n n Enterprise Architecture Models Integration Technologies ¡ ¡ n Demo 1 EAI, ETL, EII Demo 2 Service oriented Architecture 11 Oct 2006 © Chris. Peiris. com 22

Changing Times [i] (Malveau & Mowbray, 2004) 11 Oct 2006 © Chris. Peiris. com 23

Object-Oriented Polymorphism Encapsulation Subclassing Component-Based Interface-based Dynamic Loading Runtime Metadata Service-Oriented 11 Oct 2006 Message-based Schema+Contract Binding via Policy © Chris. Peiris. com 1980 s 1990 s 2000 s 24

What is SOA? SOA is an emerging paradigm to integrate systems, applications, processes and businesses. SOA delivers differentiated business capabilities or products through the assembly of autonomous business and technology capabilities (services). SOA changes the way an enterprise is run by making the business process the focus. 11 Oct 2006 © Chris. Peiris. com 25

The SOA Journey 11 Oct 2006 Message Based Point-to-Point © Chris. Peiris. com 26

Example SOA Benefits n n n n Application decoupling Share functionality rather than build it redundantly Improves Custom Development Improves Enterprise Integration Improves Information Management/Collaboration Improves Business Intelligence Protects Business Strategy ¡ ¡ ¡ 11 Oct 2006 Increases agility Decreases costs Increases process transparency © Chris. Peiris. com 27

Four Tenants of SOA n n 1) Boundaries are Explicit - Crossing boundaries is an expensive operation as it can constitute various elements such as data marshalling, security, physical location, etc. Some of the design principles to keep in mind vis-à-vis the first tenet are 2) Services are Autonomous - Services are self contained and act independently in all aspects such as deployment, versioning, etc. Any assumptions made to the contrary about the service boundaries will most likely cause the boundaries to change themselves. 11 Oct 2006 © Chris. Peiris. com 28

Four Tenants of SOA n n 3) Service Share Schema and Contract, not Class -Services interaction should be using policies, schemas and behaviours instead of classes which have traditionally provided most of this functionality. The service contract should contain the message formats (defined using a XML schema), message exchange patterns also known as MEPs (defined in WSDL) 4) Service Compatibility is based on Policy -At times one cannot express all the requirements of service interaction via WSDL alone, which is where policies can be used. Policy expressions essentially separate the structural and semantic compatibility. Or in other words, “what is communicated” and “how/whom a message is communicated”. 11 Oct 2006 © Chris. Peiris. com 29

Example of a SOA Implementation Service-Oriented Business Applications Service-Oriented Implementation Management & Governance Lifecycle Process Service Standards Design & Modelling Code & Testing Service Publishing Service-Oriented Integration Application Integration Orchestration Workflow Transformation & Routing Host Integration Service-Oriented Infrastructure Service Repository Metadata Management Publication & Discovery Monitoring & Detection Service Provisioning Svc Dev Environment Auditing and Logging Configuration Transport Hosted Svc Environment 11 Oct 2006 © Chris. Peiris. com Service Management Authorization & Access Existing Systems 30

Universal Business Integration Platform (Integration Journal Online, 2003) 11 Oct 2006 © Chris. Peiris. com 31