Your SlideShare is downloading. ×
Download Slides
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Saving this for later?

Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime - even offline.

Text the download link to your phone

Standard text messaging rates apply

Download Slides

289
views

Published on

Published in: Technology, Education

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
289
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
9
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Suggestion: Reiterating the point that integration is in everything that we do – it is important to understand what our customers require at each level.
  • Tightly Coupled
  • We’ve been on this journey for a while now. The fact that we are still talking about it is a good thing. It means that the concept of “SOA” has proved to be valuable to our customers at a business and technical level.
  • Traditionally, Enterprise Applications Integration (EAI) and Enterprise Information Integration (EII) were viewed as the essential ingredients of an integration strategy. This view has expanded to include both Service-Oriented Computing (SOC) and Business Process Management Systems (BPMS). In Figure 1.1, SOC is represented by Service Oriented Architectures (SOA), Web services, and Service Oriented Development of Applications (SODA). BPMS is depicted as Business Process Orchestration (BPO), Business Activity Monitoring (BAM) and Business Intelligence (BI).
  • Transcript

    • 1. Service-Oriented Enterprise Integration: Tools and Techniques Chris Peiris www.ChrisPeiris.com
    • 2. Agenda
      • Enterprise Architecture
        • Demo 1
      • Enterprise Architecture Models
      • Integration Technologies
        • EAI, ETL, EII
        • Demo 2
      • Service oriented Architecture
    • 3. 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. 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. 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. 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. 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. 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. Zachman Framework
    • 10. 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
      1 2 3 4 5 6 Contextual Conceptual Logical Physical As Built Functioning Contextual Conceptual Logical Physical As Built Functioning Why Why Who Who When When Where Where What What How How
    • 11. 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. 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. 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. Agenda
      • Enterprise Architecture
        • Demo 1
      • Enterprise Architecture Models
      • Integration Technologies
        • EAI, ETL, EII
        • Demo 2
      • Service oriented Architecture
    • 15. 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. Integration Products Available
      • Why build when you can buy?
      • Build less and connect more
      Manugistics Product Data Mgmt/Demand Planning ISVs, Build Vertical / Company Specific Unix, VAX, AS/400 IBM Mainframe… Legacy SMB ERP… ERP Vendors, I2 Connecting Partners (SCM) MS CRM, Salesforce.com Siebel, SAP Front Office (CRM) Axapta, Great Plains SAP, Oracle, JDE, Manugistics… Back Office (ERP) Small to Medium Enterprise Category
    • 17. Integration Categories
      • Enterprise Application Integration
      • Extract Transform and Load / Extract Load and Transfer
      • Enterprise Information Integration
    • 18. 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. 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. EII
      • User Interface driven
      • Person to Person – to assist senior management.
      • Real Time
      • Vendor Implementations
        • Seibel
        • Microsoft Workflow Foundation
        • Biztalk Server Orchestration
    • 21. 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. Agenda
      • Enterprise Architecture
        • Demo 1
      • Enterprise Architecture Models
      • Integration Technologies
        • EAI, ETL, EII
        • Demo 2
      • Service oriented Architecture
    • 23. Changing Times [i] (Malveau & Mowbray, 2004)
    • 24.
      • Polymorphism
      • Encapsulation
      • Subclassing
      • Message-based
      • Schema+Contract
      • Binding via Policy
      • Interface-based
      • Dynamic Loading
      • Runtime Metadata
      Object-Oriented Service-Oriented Component-Based 1980s 2000s 1990s
    • 25. 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. The SOA Journey Point-to-Point Message Based
    • 27. 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. 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. 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. 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. Universal Business Integration Platform (Integration Journal Online, 2003)
    • 32. Questions?