The Business Side of SOA. Challenge: Inertia in the Organization

Transcription

1 The Business Side of SOA Ron Schmelzer ZapThink, LLC Take Credit Code: NOBIZ Copyright 2006, ZapThink, LLC 1 Challenge: Inertia in the Organization Architecture doesn t have features and business executives pay for features! Moving to SOA means breaking down silos and sharing resources The technology change is easy it s the human change that s the hard part! Copyright 2006, ZapThink, LLC 2 1

2 Challenge: Reuse = Sharing We all learned to share in kindergarten But by the time we get to the working world, we forget how! Copyright 2006, ZapThink, LLC 3 Challenge: People, Change and Fear People are inherently resistant to change People consider job security, authority and responsibility when asked to share Fear is the strongest emotion of all! Copyright 2006, ZapThink, LLC 4 2

3 Challenge: SOA Governance Establishing and communicating the policies that employees must follow Giving employees the tools they need to be compliant with those policies Providing visibility into the levels of compliance in the organization Mitigating any deviations from established policy Not just governance of SOA governance in the context of SOA Copyright 2006, ZapThink, LLC 5 What is a Business Process? What a business does Range from fully manual (no IT involvement) to fully automated (no human involvement) Most processes are partially automated Copyright 2006, ZapThink, LLC 6 3

4 The Rise of the SOBA A Service-Oriented Business Application (SOBA) is a composite application composed of Services that implements a business process Copyright 2006, ZapThink, LLC 7 SOBAs and Business Process SOBAs implement processes that are composed of Services and exposed as Services Processes that are loosely coupled: a change to a process flow, activity, subprocess doesn t effect other processes Processes that are asynchronous, dynamically discoverable, and recursively defined Put the power for creating and managing business processes into the hands of the business user Copyright 2006, ZapThink, LLC 8 4

5 Role of SOBAs Architecture guides composition of Services Legacy assets key part of SOBAs Governance essential to successful SOBAs SOBAs combine legacy processes with new composite business logic Copyright 2006, ZapThink, LLC 9 SOBA Example Merchandising process example The old way: establish the process for ordering, delivering, and displaying winter coats on store racks An early cold snap leads to unexpected demand, causing an exception to be handled manually The Service Oriented way: a business user responsible for the merchandising SOBA updates it to deal with unexpected events, reducing the need for manual exception handling Copyright 2006, ZapThink, LLC 10 5

6 How do you manage change? SOA is all about continuous and sometimes unpredictable change Development issues How to handle versioning? How to handle metadata management? How to develop changing policies? Runtime issues Service availability Policy enforcement Guarantee Service-level agreement Maintain low TCO Copyright 2006, ZapThink, LLC 11 Building for ongoing change: The Death of the SDLC Traditional Distributed Software Development Waterfall Gather requirements, design, develop, test, deploy as separate steps Works great when things don t change But, over time, usually fails to meet ongoing business requirements What if things are never done? Need Iterative approaches Same order, with overlapping cycles Better, but still assumes project completion SOA applications are never complete, Services are always in flux Traditional SDLC wholly inadequate Copyright 2006, ZapThink, LLC 12 6

7 Building Applications the Old Way Plan Design Develop Risky Test Time-consuming Fix Expensive to maintain Inflexible in the face of change Places limitations on the business Deploy Maintain Copyright 2006, ZapThink, LLC 13 Building Applications the New Way Describe Save Leverages Service- Oriented Architecture Meets ongoing business requirements Responds to change Lowers risk & cost No programming Agile Publish Render Copyright 2006, ZapThink, LLC 14 7

8 Building SOBAs Orchestrate Compose Compose to build Service- Oriented Business Applications (SOBAs) SOBAs enable agile, costeffective business processes Copyright 2006, ZapThink, LLC 15 SOA Tenet: Move from Code to Composition Fundamental shift from code-centric business logic to metadata-centric It s not the Service that makes the application, but the composition and the policy Goal: users build applications out of Services Copyright 2006, ZapThink, LLC 16 8

9 Revisiting Definition of Application Original definition of application was what task a computer was applied to Colossus at England s Bletchley Park was applied to breaking codes, so that was its application The rise of programmable digital computers associated the word application with computer program Today, business users apply Services to solve business problems by building SOBAs Copyright 2006, ZapThink, LLC 17 The Services Tipping Point Up till now, focus on building Services SOA infrastructure Legacy enablement Identifying reusable Services Building loosely coupled Services Now, focus moving to consuming Services Finding the right Service for the task at hand Composing Services into Service-Oriented Business Applications (SOBAs) Supporting rich user interfaces for Services and SOBAs Copyright 2006, ZapThink, LLC 18 9

10 Service-Oriented Process Business processes in the context of SOA SOBAs as empowerment tool for the business over process Integration as a side effect of implementing Service-Oriented Processes thru Service composition Copyright 2006, ZapThink, LLC 19 Enterprise Applications and Process The problem with enterprise applications Process bound to Functionality High customization and integration cost New approach Atomic Enterprise App Functionality Separate Process Layer Copyright 2006, ZapThink, LLC 20 10

11 Example: SAP NetWeaver Moving from selling business applications to business Services Offering the platform as well Selling the trains and the tracks Copyright 2006, ZapThink, LLC 21 Source: SAP The SOA Team Business analysts/business process architects Define Service specs depending on business requirements Decompose and recompose processes Enterprise/SO architects Codify policy and best practices Create Service model Technical specialists/project architects Specify implementation Service provider/consumer developers Implement requirements and policy Testers / Quality Assurance Insure conformance, simulate Service providers & consumers Network, operations and security personnel Contribute relevant expertise to project Copyright 2006, ZapThink, LLC 22 11

12 The Roles of SOA Business Stakeholders Logical View Functional requirements Component Architects Developers Implementation View Components Information Specialists Information View Enterprise Use Case Architects View Use Case SOAsView SOAs Data Experts Data View Business Analysts LOB Experts Process View Processes Systems Experts Deployment View Platforms Copyright (C) 2004, ZapThink, LLC Copyright 2006, ZapThink, LLC 23 The Agile SOA Lifecycle Agile architectures demand agile development approaches The Agile Manifesto: Working software over documentation People over programming Begin with metadata Agile SOA: Iterate between architecture and implementation The business drives the applications Contract-first development Software lifecycle at the Service level Copyright 2006, ZapThink, LLC 24 12

13 Service Lifecycle Considerations Lines of Business Service Model Existing Infrastructure Service Metadata Lines of business should work with metadata no IT involvement Services go thru individual lifecycles development, test, production, revision Service development driven by Service contracts Must support variety of consuming applications Copyright 2006, ZapThink, LLC 25 The Challenge of SOA Testing Impossible to create realistic QA environment Metadata configuration differences too prevalent and too dynamic Necessary to test in production environment Services must support test messages Quality assurance processes must be part of governance framework State of the Art! Copyright 2006, ZapThink, LLC 26 13

14 Handling Service Versioning New requirements may involve only process configuration changes Services may support multiple contracts New requirement may require new contract Policy drives version selection & deprecation Service consumers must support deprecation policies State of the Art! Copyright 2006, ZapThink, LLC 27 Change and Version Management: Multiple Levels Loosely-coupled systems: Lots of simultaneous change Service Implementation Change Changing how you build and run the Service Service Contract Change Changing how to define and communicate Service capabilities Service Policy Change Changing the rules by which you create, access, and compose Services Data Schema Change Changing the language of data Service Infrastructure Change Embracing ongoing heterogeneity Business Process Change The Business keeps changing, so your architecture needs to keep working! Copyright 2006, ZapThink, LLC 28 14

15 Dealing with Service Implementation Change Changing the way you build a Service provider shouldn t break consumers: loose coupling at work! Thought: can a single Service have multiple, different implementations? Reality: what happens when you change a Service implementation from Java to.net or COBOL? In order for loose coupling to be a reality, abstraction layer must be real. Copyright 2006, ZapThink, LLC 29 Service Contract Change The contract governs the loosely-coupled relationship, but what happens when the contract changes? Tip: Use Governance as an approach to unify Service development Tool: Use registries to provide visibility into Service contract heterogeneity and change Method: Treat Service contracts like Service implementations Just because you use the same infrastructure and technology doesn t mean you ll build Services consistently! Copyright 2006, ZapThink, LLC 30 15

16 Policy and Service Metadata Change Even if Service implementations and contracts stay the same, a small policy change can wreak havoc! Tip: Use Governance as an approach to prevent the SOA butterfly effect Tool: Use registries to provide central control of policy management. Method: Test policies just as you test Service implementations, and manage policies as rigorously as you manage Services. Unmanaged Policy changes can have unpredictable effects! Copyright 2006, ZapThink, LLC 31 Data Schema Change Services aren t really interoperable unless they can understand and process data in common. Schemas are key to Service data interoperability However, what happens when Schemas change? Tip: Address information and schema management in the same way you approach Service metadata management Problem: those who maintain data schema might not have anything to do with those who maintain Service models. Align the efforts of those maintaining the data schema with those maintaining the Service metadata. Copyright 2006, ZapThink, LLC 32 16

17 Service Infrastructure Change What happens when the infrastructure that runs, manages, and processes Services changes? In a loosely coupled SOA: NOTHING! That s the idea! Strive for true loose coupling by making sure that any change to environment, including changes to ESB, Service management, and process runtime do not impact Service consumption Dependence on infrastructure means that you have failed to build a truly loosely-coupled, Service-oriented Architecture. Copyright 2006, ZapThink, LLC 33 Business Process Change What happens when a business process suddenly changes? In a loosely-coupled SOA that s based on Service-oriented Process and composition, you just need to change metadata. Change your process? No problem in an SOA! Manage changing business processes just like how you d manage any changing Service metadata. Copyright 2006, ZapThink, LLC 34 17

18 Service Lifecycle Governance and Quality Connect design time to runtime Quality a never-ending goal Quality much more than being bug-free Meets business requirements as those requirements continue to change Meets Service levels and other policies as those policies change The agility requirement for SOA vastly complicates the quality challenge Copyright 2006, ZapThink, LLC 35 Is there an Architect in the House? The new discipline of architecture A formal approach to organizing IT resources is still a relatively new practice Just how big is the big picture? Architects must have an enterprisewide view Where are the architects? It s hard to learn architecture at college most learn on the job Copyright 2006, ZapThink, LLC 36 18

19 SOA Foundation: The Zachman Framework Copyright 2006, ZapThink, LLC 37 The Zachman Framework (cont.) Copyright 2006, ZapThink, LLC 38 19

20 SOA & Zachman DATA FUNCTION NETWORK SOA Copyright 2006, ZapThink, LLC 39 ZapThink is an advisory, analysis, & influence firm focused exclusively on Service- Oriented Architecture, Web Services, & Enterprise Web 2.0. Thank You! Read our new book, Service Orient or Be Doomed! How Service Orientation Will Change Your Business. Ronald Schmelzer Jason Bloomberg Copyright 2006, ZapThink, LLC 40 20