• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Jaap  Schekkerman    S O A  Enterprise  Arch  S Tyle
 

Jaap Schekkerman S O A Enterprise Arch S Tyle

on

  • 957 views

 

Statistics

Views

Total Views
957
Views on SlideShare
957
Embed Views
0

Actions

Likes
0
Downloads
21
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Jaap  Schekkerman    S O A  Enterprise  Arch  S Tyle Jaap Schekkerman S O A Enterprise Arch S Tyle Document Transcript

    • This Presentation Courtesy of the International SOA Symposium October 7-8, 2008 Amsterdam Arena www.soasymposium.com info@soasymposium.com Founding Sponsors Platinum Sponsors Gold Sponsors Silver Sponsors Services Orientation; an Enterprise Architectural Style ‘How to distinguish Reality from Parody’ Jaap Schekkerman, B.Sc. President & Thought Leader Institute For Enterprise Architecture Developments Opinion Leader Enterprise Architecture, Logica Management Consulting © Logica / IFEAD 2001 - 2008. All rights reserved © 2004 Capgemini - All rights reserved 1
    • Agenda • About Your Speaker • Services Orientation: An Enterprise Architectural Style • Geek & Poke‟s experiences with SOA • Why so many SOA Projects Fail • Why so few SOA Projects Succeed • Critical Success Factors in SOA • What can you Learn from that SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 3 About Jaap Schekkerman President & Thought Leader, Institute For Enterprise Architecture Developments Opinion Leader Enterprise Architecture, Logica Management Consulting Author / Co-Author of several EA & SO related books & publications Some Statistics Professional Associations: Ass. Professor Technical University, Delft ; University of Amsterdam; Open University, Heerlen; The Netherlands Advisory board member of the Federal Enterprise Architecture Certification Institute, USA. Co-Founder & Alliance member of the Global Enterprise Architecture Organization, New Zealand. Former Vice-President of the International Association of Enterprise Architects, USA. Member of the Institute for Defense and Government Advancement (IDGA), USA. Member of the European eGovernment Good Practices network, European Union. Member of the 'MANYWORLDS' knowledge network of Business Thought Leaders, USA. Member of the ISO/IEC 42010:2007 working group, -- Recommended practice for architectural description of software-intensive systems --, USA. Member of the World Wide Institute of Software Architects (WWISA), USA. Member of the Netherlands Society of Information Architects (GIA), NL. SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 4 © 2004 Capgemini - All rights reserved 2
    • Hi! Are You SOA Consultants.......... or Are You Practioners......? Services Orientation; an Enterprise Architectural Style SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 5 So How are we going......Trends & Developments in Enterprise Architecture Realtime Implementation of Enterprise Enterprise Architecture Architecture Function Business Innovation, Assessment of Enterprise Strategic Planning & EA Architecture Maturity Portfolio Management & Developmement of Enterprise Architecture Enterprise Enterprise Architectures Architects Compliancy & Enterprise Services Orientation as an Architecture Enterprise Architecture style Economic Value of Assessments of Enterprise Enterprise Architecture Architectures SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 6 © 2004 Capgemini - All rights reserved 3
    • Firts of all..... Enterprise Architecture is an Enterprise Planning Discipline SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 7 And...... Solution Architecture is a Development Discipline SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 8 © 2004 Capgemini - All rights reserved 4
    • However they need each other.... Where EA is Defining the Environmental Conditions... Stakeholders Enabling Enabling Stakeholders Mission Mission Context Context Vision Vision Strategy & Strategy & Business Business Planning Planning Technology Technology Value Value EA Program EA Program Goals & Goals & Enterprise Enterprise Objectives Objectives Program Enterprise Enterprise Program Management Architecture Architecture Management Validation Validation Services (Feedback loop) (Feedback loop) Orientation EA EA Budget Budget Solution Solution Transformation Transformation Process Process Architecture Architecture Programs Programs EA Measurement EA Measurement SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 9 Is.......Solution Architecture dealing with the Domain Specific Elements Enterprise Architecture Solution Architecture Environment Environment Business & IT Strategy, Transition Business Planning, SO Domain Domain Processes / Governance Activities & Data, Domain Business SOE: Business Services, Business Principles, Business Modeling Services Portfolio, Workflow, BPMN Semantics, Ontology, Policy Security Event Services Services Authorization Authentication Integration and Transformation Services Business Events External Events System Events BPA Organization BAM Services Financial Services Healthcare Insurance Government Telco Oriented Portlets PDF/ODF Wireless Correspondence e-Mail HTML/JSP UI Concepts / SO Reference Decision ERP Rule Styles Architecture SLA Rich Media + ERP QoS SLA Decision Performance Monitoring Rule Inference Situational Resolution Technology Declarative Network Research Forward / Backward chaining Persistent <<Business Entity>> Klant <<Data Type>> Klant Gegevens 1 Klant Heeft <<Data Type>> SO Gegevens 1 .. N Contract << Business Entity>> Pand Aangaande 1 .. N << Business Entity>> Service Overeenkomsten Periodiek Voorschot 1 .. N Contract <<Data Type>> Pand Gegevens Betreffende 1 Bedrijfsinstallaties << Business Entity>> Partner Contract Betreffende 1 Bedrijfsinstallaties << Business Entity>> Bedrijfsinstallaties Betreffende <<Data Type>> Partner Contract Gegevens Heeft <<Data Type>> Bedrijfsinstallaties Gegevens <<Data Type>> Onderhoud Gegevens <<Business Entity>> Partner <<Data Type>> Partner Gegevens Domain Services Oriented 1 .. N << Business Entity>> << Business Entity>> Object Financiële Onderhoud Status Administratie Bedrijfsinstallaties Periodieke Verrekening Voert Uit Onderhoud <<Data Type>> Financiële Gegevens Models Enterprise Standards Rule Work DB Repository SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 10 © 2004 Capgemini - All rights reserved 5
    • So Where we came from..........The Changing Face of Different Operation Styles Business Style Product Oriented Process Oriented Services Oriented Value Oriented Specific Generic Agile Inteligent Agent Services Oriented (ERP, CRM, Oriented Technology Style etc.) Packages Application Oriented Oriented 1990 - 2000 2001 - 2006 2007 – 2012? 2013?? (C) Copyrights IFEAD, 2001-2008 Source: SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 11 And where are we now today.........Do You Wanna Be Agile.... Or Not? • A set of technologies Transfer, also known as REST, Representational Statethat can be used with 2 design is philosophies a style of software architecture defined by a collection of • Benefits to principles. REST architectural both approaches is applied specifically to • Large overlap systems as the Web, such distributedin their capabilities and stipulates • Useful for both communities to look at resources. mechanisms for defining and accessing the benefits of the other camp SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 12 © 2004 Capgemini - All rights reserved 6
    • So, How to bring this together…..EA provides a mechanism for Services adoption Business and Customer Results Achieves Business Strategies Aligns to and implements Enterprise Business Activities / Processes Specifies Enterprise Business Requirements Business Drives Capability Requirements & Profile Drives Informs & Enables Fulfills Technology Services Provision Layer Integrates and provides Services Integration Layer Leverages Technology Data/Information Applications Services Components Supports Technology & Infrastructure The Enterprise Architecture model is the “line of sight” from business strategies to services and technologies that support them Source: (C) Copyrights IFEAD, 2001-2008 SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 13 And.... What about Services Orientation? Enterprise Architecture Framework Why? With Who? What? How? With What? When? • Don‟t bother your management with these Business architecture buzzwords! • But understand how they are related to each other Services Information • You have to deal with these architecture Oriented SPA SOE STP buzzwords if you like or not! Services Services • Explain their impact in terms Services Information Paradigm - Oriented Transition the business can Systems Adoption Enterprise SOA Plan understand! architecture Services Service SOC Oriented Oriented Architecture Service Oriented Technical Computing architecture Services Orientation is an Architectural Style of Enterprise Architecture Based On Sources: Oasis, IFEAD SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 14 © 2004 Capgemini - All rights reserved 7
    • How is this different....... The Characteristics of Services Orientation • Adopting the „Services paradigm‟ Why? With Who? What? How? With What? When? requires a Services Oriented Reference Business • Between Partners Architecture architecture • The “Services” in SOE are business • Between Businesses Information services architecture • Between Business processes / Activities • Business Services connect Business • Between Business Services Partners (Value Network) Information Systems architecture • Between Software Services • Services are linked together to implement business processes / Technical • Between Service Components activities architecture • Between Network Services • Services are reusable and supplied or consumed by many • Connectivity and functionality are truly separated • Services orientation requires a redesigned clean common data infrastructure • Services are Loosely coupled • Offers reusability at a functional level • Favors business agility over technical efficiency Based On Sources: Oasis, IFEAD SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 15 How Getting It Right………….Services Oriented Enterprise Why? With Who? What? How? With What? When? Business architecture Business Business Outcome & Goals agility requires Business Obligations Semantics shared Business Processes Information understanding architecture and alignment Business Services of: Business Semantics Information Services Systems architecture SOA requires Message Format shared understanding Protocols Technical architecture and alignment Status (manageability) of: Ontology's Security Joined up processes Common data infrastructure SO Reference Architecture (C) OASIS, IFEAD, ZAPTHINK, OMG, W3C, 2008 SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 16 © 2004 Capgemini - All rights reserved 8
    • But You have to Go to the Details to Understand....... SO Reference Architecture WS* / SOA Standards Business Concepts Enterprise Business Modelling SO Concepts / Styles Define Business Capabilities Business Ontology Define Business Relationships SO Principles Business Type model Reference Environment Define Business policy Service Portfolio Planning Model Business Semantics Define Policies Model Business Capability Capabilities Identify Services Model Value Chains Describe Services Business Value Policies Chains Publicize Portfolio Plan Service Planned Service Descriptions policies Required Services Business Process Design Model Business Process Business Service Provisioning Process Model Specify a Service Solution Delivery Design Software Solution Acquire the Service Operational Request Services and Operations Certify, Deploy Service Services Construct Software Solution Publish Service in Catalog Test Software Solution SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 17 And then....... SOA again more complicated by ESB proliferation • "There's a whole space emerging Dave Linthicum CEO of the Linthicum Group, LLC among enterprise architects called and SOA Guru said: ESB intermediation,". "They're finding “Call me crazy, but would it not make more sense to that two or three different divisions of have a centralized plan as to what the SOA should their company are using different be, based on the requirements of the business, ESBs from different vendors. Yet versus people dashing out and shelling out the dollars for an ESB for some one-off tactical reason, they're trying to build business or more likely just acting out of reaction to the hype? processes across these ESBs. But the ESBs are designed to be their Now, you’re left with a dysfunctional mess that’s not easily corrected, and clearly costly. …why the heck own center of the universe. How do are you attempting to integrate these integration you intermediate transactions across engines when they should perhaps be displaced these ESBs?" altogether? Because, call me crazy again, that would be cheaper.” SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 18 © 2004 Capgemini - All rights reserved 9
    • Why so many SOA Projects Fail • Burton Group found a 50% complete failure rate in the 20 companies that took part in their study in 2008. Another 30% were considered neither successful nor wholly failed. • "Many of them had deployed multiple successful projects, but most of those projects were focused on just one integration problem,“. "It was just a bunch of Web services. … The service is only built for one application and it's never going to be used again." • Such projects amount only to a less efficient method of doing EAI. Instead users focus projects around quality data, systems modernization or business process automation. • "BPM and SOA are like the peanut butter and the chocolate in the commercial the way they go together,“. • The Burton Group listed numerous other failure factors, including: – Lack of defined service models – Infrastructure focus – Governance only of SOAP-based systems – Failure of developers to leverage the runtime governance in place – Initiatives led by and solely involving the application development group – Roadmaps lacking specificity – Inability to measure ROI – Project-centric culture "The attitude is I'm so special I can't use this service everyone else is using,". "I need my own thing." – An "I'm special" attitude Source: Burton Group, July 2008 SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 19 Why so few SOA Projects Succeed • The Burton Group found that success came to SOA proponents who pay attention to the cultural shift that needs to take place within the business, cemented by good governance. The successful businesses had “incredibly inspiring” stories to tell. • Here are the common denominators Burton Group found within the successful efforts: – Business and IT reorganization, usually with a SOACIOCost Curveboard new IT coming on Over Time – Sponsorship at the C-level or by the Board of Directors – Agile/iterative Development Methodologies put into place – Projects tied to and measured by Business Goals, not IT drivers € € Investments – Well-defined Funding and Maintenance models that balance the needs of service providers and consumers € € Costs reduction – A simplified architecture, making it easier to access and manage quality Compared to data – A Culture of trust between Business and IT Traditional Approach Requirements Maintenance Gathering, Services Time Year 0 Development & Year 5? Year 10? Integration Source: Investments Source: Burton Group, July 2008 SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 20 © 2004 Capgemini - All rights reserved 10
    • Critical Succes Factors in Implementing Services Orientation 1. Not Measuring the Services Oriented Maturity • Organizations are at different levels of maturity in the adoption and incorporation of Services Orientation. Some are just beginning to explore the world of SO while others have already experienced with web services but that is not SO. 2. Building SOA like traditional Distributed Architecture • The number one obstacle organizations have been facing when attempting to achieve SOA is building service-oriented solutions in the same manner in which traditional distributed solutions have been built, under the pretence that SOA is actually being achieved. 3. Not Standardizing SOA • SOA, like any other architecture, requires the creation and enforcement of internal design standards for its benefits to be truly realized. For example, if one project builds a service-oriented solution in isolation from others, key aspects of its solution will not be in alignment with the neighbouring applications it may be required to interoperate or share agnostic services with one day. 4. Not Creating a Transition Plan • The chances of a successful migration will be severely diminished without the use of a comprehensive transition plan. Because the extent to which service endpoints are positioned within an enterprise can lead to a redefinition of an environment‟s infrastructure, the affects of a poorly executed migration can be significant. 5. Not Starting with an XML Foundation Architecture • In the world of today‟s SOA, everything begins with Web services. That statement has become a mantra of sorts within some organizations, but it is not entirely true. In the world of today‟s SOA, everything, in fact, begins with XML. It is the standard from which multiple supplementary standards have evolved to form a de facto data representation architecture. Source: Thomas Erl, IFEAD SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 21 Critical Succes Factors in Implementing Services Orientation, Cont. 6. Not Understanding SOA Performance Requirements • Loose coupling comes at a price. When implemented with Web services, SOA introduces layers of data processing as well as the associated performance overhead imposed by these layers. 7. Not Building Services based on Business Semantics & Ontology's • Software services need to be based on agreed business semantics and ontology's otherwise services can‟t be reused from a business perspective. 8. Not having a harmonized and clean Data / Information infrastructure • Key to the success of sharing data/information is the necessity to have a harmonized and clean data infrastructure with responsible ownership and procedures in place to keep data clean and correct. 9. Not Understanding to find the right balance in Services Granularity • Stating that Services are the central part of SOA and SOE will probably not offend anybody. But methods to identify Services at the right granularity are only slowly emerging. When talking about SOA the Services are often seen as a task that will be require only a small effort – so small that we almost don‟t bother talking about it. However making services small in functionality will deliver larger reusability but also a larger maintenance and performance problems. Making services larger will deliver more functionality but less reusability and less maintenance and performance problems, so depending on the generality versus specificity of a service define the appropriate granularity. 10. Not Understanding the Quality of Services • One important missing requirement often seen in the context of Services Orientation is the management of Quality of Services. Appropriate control of quality leads to the creation of quality products and services; these, in turn, fulfill customer expectations and achieving customer satisfaction. Part of this thinking of QoS is related to requirements about roll back of Services transaction sequences, Error handling, Security, Authorization and Authentication, etc. Key issue in this context is also, how to check / control the behavior and functionality of services that are delivered by third parties and how to test and guarantee their behavior. Source: Thomas Erl, IFEAD SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 22 © 2004 Capgemini - All rights reserved 11
    • But if you can’t meet those........ Here are Some other Solutions..... SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 23 Thanks for your attention..... SOA Symposium 2008 - © Copyrights Logica / Institute For Enterprise Architecture Developments, 2001-2008, All Rights Reserved 24 © 2004 Capgemini - All rights reserved 12