SOA and the Organization

Transcription

1 SOA and the Organization Nicolai M. Josuttis IT-communication.com 12/ Independent consultant continuously learning since 1962 Nicolai Josuttis Systems Architect, Technical Manager finance, manufacturing, automobile, telecommunication SOA for 3 years incl. experience of bringing SOA in production >40 international systems >400 services >10 million service calls per day Author of SOA in Practice 1

2 SOA and Organizational Structures 3 4 Darwinism It is not the strongest of the species that survive, nor the most intelligent, but the ones most responsive to change. Charles Darwin 2

3 5 Globalization We scale more and more Business is highly distributed Harmonization is not an option The Context of the 21 st Century We are on the road towards ULS (ultra-large-scale) systems Internet Health care systems Traffic and transportation... 6 Characteristics of Large Systems Characteristics of large systems: Decentralization Heterogeneous, inconsistent, and changing elements Continuous evolution and deployment Redundancies Inherently conflicting, evolving, and diverse requirements Normal failures Erosion of the people/system boundary These characteristics may appear in today s systems can become critical in a system of systems dominate in ultra-large-scale systems SOA 3

4 7 SOA Service Oriented Architecture: An architectural paradigm way of thinking, style, value system e.g.: use lose coupling where appropriate for distributed processes multiple companies, business units, departments, systems involved over heterogeneous systems multiple platforms, programming languages,... that may be under control of different owners different schedules, budgets, priorities,... 8 Thin Client SOA and the Frontend Smart Client (Call Center Desktop) Back Office Frontend Portal read & validate execute Process Compose Basic rule read write rule read write rule read write Backend domain domain domain 4

5 9 Thin Client SOA and the Frontend Smart Client (Call Center Desktop) Back Office Frontend Portal Process Compose Basic rule read write rule read write rule read write Backend domain domain domain 10 SOA and the Organization Before SOA: With SOA: CRM Client Inventory Client Production Client Billing Client CRM Inventory Production Billing based on: Eberhard Wolff, 5

6 11 SOA and the Organization New Organizational structures backend departments backend cross departments frontend departments solutions managers Organizational culture collaboration and trust no fiefdoms Lessons Learned in Practice 12 6

7 13 Flexibility and Interfaces The world is changing: Agile principles are getting mainstream To be flexible, the SOA concept has established BUT still People think that interfaces have to be stable Projects and contracts are defined by stable interfaces Even worse Now system analysts are able to model services and all assume that these remain stable Therefore: Change the way, system interfaces are defined before they get implemented 14 Example: Reuse of a Broad Service 7

8 15 Consumer Specific Services Loading all customer data at once took too long: Consumer Provider getall() 16 Consumer Specific Services Loading all customer data at once took too long Consumer Provider getall() So, split the service into two specific calls: Consumer getpart1() Provider Cache 8

9 17 Consumer Specific Services Loading all customer data at once took too long: Consumer Provider getall() So, split the service into two specific calls: Consumer getpart1() Provider getpart2() Cache 18 You will find: Reused services Redundant services Custom-made services Unused services The Performance Reusability Tradeoff 5 4 Average number of consumers per service Years

10 19 SOA Business Case increasing costs and risks for modifications Investment in loose coupling ordinary software development costs in large systems software development costs with loose coupling in large systems Cost of a modification/ extension Long-term SOA benefit Time 20 [Krafzig04] with extensions: Forms of Loose Coupling physical communication style data model type system interaction pattern control of process logic binding platform transactionality deployment Tight Coupling point-to-point synchronous common complex types strong navigate through complex object trees central control statically strong dependencies 2PC (two-phase commit) simultaneous Loose Coupling intermediator asynchronous common basic types weak data-centric, self-contained message distributed control dynamically platform independent compensation at different times Note that loose sounds simpler, but is harder to implement and increases complexity 10

11 21 Harmonization Harmonization is a tricky subject If possible, harmonize Don t require harmonization where you don t have it (yet) There is a difference between harmonization and centralization You have to find the right amount of harmonization One common Business Object Model? One common repository/registry? Same tools? Same processes? Same infrastructure? Same policies and conventions? 22 Example Infrastructure Java Appl Local Appl Local Appl Ext. Appl Ext. Appl National WebService Bus B2B WebService Bus Local Appl Local Appl Gateway National Proprietary ESB Java Appl C Appl C++ Appl SAP Appl Router I18N Appl International Proprietary ESB I18N Appl I18N Appl 11

12 23 Repositories and Registries in Practice Rose Repository Magic Draw Repository external WSDL HTML HTML import SLA,... Intermediate format: Signature SLA s URL for documentation Deployment Informations Central Registry Establishing SOA 24 12

13 25 Possible Approaches to Establish SOA Developer-driven (grass roots) leads to experience and technology expertise includes the risk of being uncoordinated and non-collaborative Business-project-driven approaches: developers experience leads to a proof of concept or pilot, which encourages further adoption business-driven first isolated projects might have limited benefits, IT-driven so you need some way to expand the SOA approach to cross-organizational collaboration IT-driven effective for infrastructure aspects danger of focusing only on technical aspects We need a combination of all approaches: top-management support Top-management-driven (top-down mega project) highly coordinated effort driven by business priorities is usually expensive, disruptive, and very risky Based on Anne Thomas OOP Establish SOA Top-down or Bottom-up Top-down: Bottom-up: Figures with friendly permission by Dirk Krafzig and Dirk Slama 13

14 27 SOA is an architectural style Shared architectural vision is key Step 1: Understand SOA SOA = Infrastructure + Architecture + Processes Think big SOA is a concept for large decoupled systems Start small Remember the YAGNI principle ( You Ain t Gonna Need It ) Kent Beck: Start stupid and evolve 28 Start with fundamental SOA Basic infrastructure Basic architecture Basic meta model Step 2: Start with SOA Pilot project(s) a small number of basic services a small number of service participants may be a quick win be careful with external contracts Plan time and resources to refactor 14

15 29 Step 3: Grow Grow increase number of services and participants introduce composed and process services and orchestration let processes evolve let policies evolve manage services (repositories) Refactor Three strikes and you automate (three different times) Three strikes and you refactor (three different places) 30 Iterative and Incremental SOA Establishment SOA Landscape Repositories Processes and Policies Infrastructure (incl. Meta Model and MEPs) Project 1 Project 2 Refactoring Project 1 Refactoring Project 1&2 Project 3 Further Projects months 6-12 months 1-2 years 15

16 31 SOA Governance Governance: Making sure that people do what s right SOA Governance: Visions, objectives, business case, and funding model Reference architecture(s) Roles and responsibilities Policies, standards, and formats Processes and life cycles Documentation Service management Monitoring Change and configuration management => SOA Competence Center Tool Support: no ( ) no no no ( ) 32 Central Service Team You need a central service team to decide about technology and restrictions setting-up processes and frameworks serve as central contact for business teams maintain infrastructure, architecture, processes trigger generation of service code (in conjunction with build team) beware of work contracts and external systems But note This is a central team that has the challenge to provide decentralization It s hard to find the right balance (central teams tend to centralization) 16

17 33 Key Success Factors of SOA Governance Central team (SOA Competence Center) for decentralization understanding themselves as servant for business teams doing homework right key for acceptance Support by management time and resources for slow establishment support organizational impact distributed processes do not work with profit centers First things first Summary 34 17

18 35 SOA is an approach for a system of systems under maintenance an architectural paradigm for distributed processes over heterogeneous systems that may be under control of different owners nothing new but revolutionary by accepting heterogeneity not driven by a community driven by major vendors, analysts, and integrators but unfortunately: You Can t Buy SOA 36 Lessons Learned Distribution means distributed design (multiple parties involved) needs organizational culture (collaboration, trust) and structures distributed testing distributed test data turned out to be our biggest day-to-day problem distributed debugging your infrastructure/esb is your debugger Yes, you can t buy SOA important first step: shared understanding later: processes, policies, architecture, patterns evolve Reuse is not the business case for SOA SOA is a strategy sooner or later you need top management support 18

19 37 SOA is provided for business processes over distributed systems Limits of SOA SOA is not appropriate for: decoupling user-interface from complex business logic system-specific clients are still appropriate data synchronization between backends critical real-time applications profit center systems... SOA concepts can help in other areas Note: It doesn t matter whether it is SOA, the important point is whether it is appropriate 38 Summary SOA is a concept for a system of systems under maintenance accepts heterogeneity and supports harmonization enables flexible deployment strategies for capabilities can be established step-by-step maintenance starts by establishing SOA There is no such thing as a quick fix Organizations are complex business systems, within which a change in any one component is likely to have an impact on other components. Andrew Spanyi in Business Process Management is a Team Sport: Play it to Win! 19

20 39 SOA FAQ Is SOA something new? No new technologies or concepts (except Web Services) New value system, due to acceptance of heterogeneity Does SOA reduce or raise complexity? Distributed computing raises complexity SOA reduces this raised complexity Key Success Factors? Collaboration Careful introduction Technology + Architecture + Processes Management support Should we use SOA for each system integration? No, SOA is for distributed business processes (micro/macro flows) DB replication, mass data processing, local clients are different Appendix 40 20

21 41 Nicolai Josuttis: SOA in Practice The Art of Distributed System Design ISBN-10: ISBN-13: soa-in-practice.com includes: SOA Glossary SOA References 42 Nicolai Josuttis: SOA in der Praxis System-Design für verteilte Geschäftsprozesse ISBN-10: ISBN-13: soa-in-der-praxis.de umfasst: SOA-Glossar SOA-Referenzen 21

22 43 So Long, and Thanks for All the Fish Nicolai Josuttis Gaussstr. 29 D Braunschweig Tel.: / / / JOSUTTIS 22