1. Service-Oriented Enterprise Integration: Tools and Techniques Chris Peiris www.ChrisPeiris.com

2. 11 Oct 2006© ChrisPeiris.com2 Agenda Enterprise Architecture  Demo 1 Enterprise Architecture Models Integration Technologies  EAI, ETL, EII  Demo 2 Service oriented Architecture

3. 11 Oct 2006© ChrisPeiris.com3 Enterprise Architecture “Enterprise Architecture is about understanding all of the different elements that go to make up the enterprise and how those elements interrelate” “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 )

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

5. 11 Oct 2006© ChrisPeiris.com5 EA Model / Framework 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.

6. 11 Oct 2006© ChrisPeiris.com6 EA Models Enterprise Architecture Frameworks  Zachman Enterprise Architecture Model  Federal Enterprise Architecture Framework (FEAF)  The Open Group Architecture Framework (TOGAF)  Treasury Enterprise Architecture Framework (TEAF)

7. 11 Oct 2006© ChrisPeiris.com7 What do they discuss? How an enterprise should function For an example Zachman addresses,  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)

8. 11 Oct 2006© ChrisPeiris.com8 Zachman Model 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.

9. 11 Oct 2006© ChrisPeiris.com9 Zachman Framework

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

11. 11 Oct 2006© ChrisPeiris.com11 Federal Enterprise Architecture Framework (FEAF) 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.

12. 11 Oct 2006© ChrisPeiris.com12 Treasury Enterprise Architecture Framework 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

13. 11 Oct 2006© ChrisPeiris.com13 The Open Group Architecture Framework (TOGAF) 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 preliminary phase.

14. 11 Oct 2006© ChrisPeiris.com14 Agenda Enterprise Architecture  Demo 1 Enterprise Architecture Models Integration Technologies  EAI, ETL, EII  Demo 2 Service oriented Architecture

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

16. 11 Oct 2006© ChrisPeiris.com16 Integration Products Available CategoryEnterpriseSmall to Medium Product Data Mgmt/Demand Planning Manugistics Back Office (ERP)SAP, Oracle, JDE, Manugistics… Axapta, Great Plains Front Office (CRM)Siebel, SAPMS CRM, Salesforce.com Connecting Partners (SCM) ERP Vendors, I2SMB ERP… LegacyIBM Mainframe…Unix, VAX, AS/400 Vertical / Company Specific ISVs, Build Why build when you can buy? Build less and connect more

17. 11 Oct 2006© ChrisPeiris.com17 Integration Categories Enterprise Application Integration Extract Transform and Load / Extract Load and Transfer Enterprise Information Integration

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

19. 11 Oct 2006© ChrisPeiris.com19 ETL / ELT Extract Load Transform (ELT) or Extract Transform and Load (ETL)  Bulk Transactions / Batch  Database to database  Low frequency / high latency Vendor Implementations  IBM DataStage  Microsoft SQL Server Integration Services  Seibel EIM

20. 11 Oct 2006© ChrisPeiris.com20 EII User Interface driven Person to Person – to assist senior management. Real Time Vendor Implementations  Seibel  Microsoft Workflow Foundation  Biztalk Server Orchestration

21. 11 Oct 2006© ChrisPeiris.com21 Demo 2 Enterprise solution that uses multiple products to assist business processes. It uses Microsoft InfoPath, BizTalk, ASP.NET Web Services, RPG on an AS/400, CICS on a Mainframe, J2EE on WebSphere, Pocket PC, SQL Server, Speech Server, and Microsoft MOM. Question : Which integration strategies are we using? Introduction to SOA…

22. 11 Oct 2006© ChrisPeiris.com22 Agenda Enterprise Architecture  Demo 1 Enterprise Architecture Models Integration Technologies  EAI, ETL, EII  Demo 2 Service oriented Architecture

23. 11 Oct 2006© ChrisPeiris.com23 Changing Times [i] (Malveau & Mowbray, 2004)

24. 11 Oct 2006© ChrisPeiris.com24 PolymorphismEncapsulationSubclassing Message-basedSchema+Contract Binding via Policy Interface-based Dynamic Loading Runtime Metadata Object-Oriented Service-Oriented Component-Based 1980s 2000s 1990s

25. 11 Oct 2006© ChrisPeiris.com25 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.

26. 11 Oct 2006© ChrisPeiris.com26 The SOA Journey Point-to-Point Message Based

27. 11 Oct 2006© ChrisPeiris.com27 Example SOA Benefits 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  Increases agility  Decreases costs  Increases process transparency

28. 11 Oct 2006© ChrisPeiris.com28 Four Tenants of SOA 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.

29. 11 Oct 2006© ChrisPeiris.com29 Four Tenants of SOA 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”.

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

31. 11 Oct 2006© ChrisPeiris.com31 Universal Business Integration Platform (Integration Journal Online, 2003)

32. 11 Oct 2006© ChrisPeiris.com32 Questions?