Enterprise Integration Architecture IPMA Professional Development Seminar June 29, 2006 Scott Came Director, Enterprise Architecture Program Washington

  • View
    219

  • Download
    5

Embed Size (px)

Text of Enterprise Integration Architecture IPMA Professional Development Seminar June 29, 2006 Scott Came...

  • Slide 1
  • Enterprise Integration Architecture IPMA Professional Development Seminar June 29, 2006 Scott Came Director, Enterprise Architecture Program Washington State Department of Information Services
  • Slide 2
  • EA Integration Architecture Initiative In December, the ISB EA Committee chartered an initiative to look at integration architecture Team of architects, developers, IT managers, and integration experts from agencies have been meeting to develop an architecture Materials endorsed by EA Committee in June, out for CAB review now
  • Slide 3
  • Motivation Reduce costs and risks of integration Reuse system interfaces Leverage common infrastructure Improve agility and responsiveness of IT Accommodate different software platforms, COTS/package application architectures
  • Slide 4
  • Approach: Service Oriented Architecture SOA is an architectural approach for organizing and using services to support interoperability between enterprise data assets and applications Capabilities performed by one for another to achieve a desired outcome Service S The fundamental organization of a system by its capabilities, their interactions, and the enterprise environment Architecture A Aligning architecture to enable a collection of services to be linked together to solve a business problem Oriented O Slide courtesy Booz Allen Hamilton
  • Slide 5
  • What is a service? An explicit, focused agreement between the provider and the users of a capability as to how the interaction with the capability will take place Services support integration by: Establishing an agreement as to the purpose of the interaction and how the interaction will take place (e.g., agreement on meaning of data) Hiding the implementation of one system from another, avoiding technical dependencies
  • Slide 6
  • Tight Coupling of Systems System in Agency ASystem in Agency B (Capability) Desires Uses Accesses Causes Effect Technology Dependency
  • Slide 7
  • How do we tightly-couple systems? Sharing databases Integrating user interfaces Integrating with technology specific/proprietary to one system (versus open standard technologies) Exchanging files
  • Slide 8
  • Loose Coupling of Systems System in Agency ASystem in Agency B (Capability) Desires Uses Accesses Causes Effect Service Accesses Interface Technology Dependency (Standards)
  • Slide 9
  • How do we loosely-couple systems? Exchange messages specified by service (explicit, focused agreement) Leverage open standards for message structure Use infrastructure to route messages, rather than direct addressing Asynchronous, reliable transport of messages
  • Slide 10
  • Natural Boundaries When systems are likely to change at the same time, tight coupling is OK Performance Simplicity A natural boundary identifies sets of features that are implemented as a unit (and change as a unit) Integrate across natural boundaries; consolidate within natural boundaries
  • Slide 11
  • Benefits of SOA Agility Focus more on core competencies and missions by creating a network of producers- suppliers with intense interactions Improve access to information to enable faster cycle times Enable enterprises to be more agile and respond quickly to business needs Focus more on core competencies and missions by creating a network of producers- suppliers with intense interactions Improve access to information to enable faster cycle times Enable enterprises to be more agile and respond quickly to business needs Process Increase business flexibility through plug- and-play architecture and re-use of existing services Ensure system change is not a constraint on business or mission change Allow interoperation with other systems & partners without customization Increase business flexibility through plug- and-play architecture and re-use of existing services Ensure system change is not a constraint on business or mission change Allow interoperation with other systems & partners without customization Interoperability Facilitate integration with multiple solutions via open IT standards Remain platform, language, and vendor independent to remove IT barriers for using best-of- breed software packages Facilitate integration with multiple solutions via open IT standards Remain platform, language, and vendor independent to remove IT barriers for using best-of- breed software packages Costs Reduce development costs by acquiring pre-built capabilities Leverage previous IT investments through re- use of assets Lower maintenance costs and TCO through fewer instances of a function, and fewer software licenses Reduce development costs by acquiring pre-built capabilities Leverage previous IT investments through re- use of assets Lower maintenance costs and TCO through fewer instances of a function, and fewer software licenses IT alignment with an organizations mission Improved agility, focus on core competencies, IT efficiencies, and ROI for IT assets Slide courtesy Booz Allen Hamilton
  • Slide 12
  • Deliverables from EA initiative Integration Domain (principles, business drivers, environmental trends) Conceptual Architecture Service Interaction Profiles (Web Services, Websphere MQ, File Drop) Solution Integration Design Guidelines Service Modeling Guidelines
  • Slide 13
  • For more information EA Committee Website (includes deliverables) http://isb.wa.gov/committees/enterprise/index.aspx http://isb.wa.gov/committees/enterprise/index.aspx EA Program Website and Contact http://dis.wa.gov/enterprise/enterprisearch/index.aspx http://dis.wa.gov/enterprise/enterprisearch/index.aspx Scott Came, EA Program Director scottca@dis.wa.gov, 360-902-3519 scottca@dis.wa.gov

Related documents