Soa Business And Technical Overview Presentation (Reed003707)
- 2. Goal of Today Discuss Strategy and build consensus for the continued evolution of a flexible Enterprise Architecture.
- 3. Agenda Flexible IT, Better Strategy Designing for Business Processes Developing for Business Solutions Challenges Ahead
- 4. Agenda Flexible IT, Better Strategy Designing for Business Processes Developing for Business Solutions Challenges Ahead
- 5. Flexible IT, Better Strategy The McKinsey Quarterly, 2003 Number 4 IT architecture determines the agility with which companies can carry out strategy The difficulty and cost of modifying today's IT architectures can be so high that some companies would rather abandon new strategic initiatives than make a single change to the applications they already have in place. Service-Oriented Architectures promise to reduce if not remove the current obstacles. Information technology, far from lacking strategic worth, determines strategic value
- 6. Business Processes Rule This is the Fundamental Assumption Everything Enterprise IT does is in the service of some business process Service-Oriented Architecture (SOA) is about making business processes: Better Easier to change Cheaper to create Faster to Assemble David Chappell: Service Oriented Architecture: What’s Next (www.davidchappell.com)
- 7. Service Oriented Architecture Defining the Term Flexible software providing Services leading to agile business processes. Services are a technology agnostic end point that either answers a question or raises a notification when a meaningful event occurs.
- 8. What does SOA mean: To the CIO means for protecting existing IT investments without inhibiting the deployment of new capabilities. To the Business Analyst means of bringing information technology investments more in line with business strategy. To the Developer Means for creating dynamic collaborative applications. To the IT Manager means for effectively integrating the diverse systems typical of modern enterprise data centers. To Microsoft a crucial prerequisite to creating connected systems.
- 9. Service Orientation Basic Consumer/Provider view Service Façade Service Consumers Service Provider How the application is constructed and hosted is independent of the service implementation SQL App Internals
- 10. Shift To Service Orientation Integrations = cost Function oriented Build to last Prolonged development Integrations = value Process oriented Build for change Incrementally deployed From To Application silos Tightly coupled Object oriented Orchestrated solutions Loosely coupled Message oriented
- 11. Enterprise Flexibility Aggregation Business Process Management Identity and Access Mgmt Web Services Management Application Monitoring Testing and Performance Presentation Services Data and Capabilities exposed as Services… … customized via shared middle-tier middleware… … are aggregated to fit user needs Process Aggregation Single Sign On Two-way integration User Specific Experiences Infrastructure Integration Management Packaged Applications Custom Applications Legacy Warehouse Operations Executive Marketing
- 12. Key Attributes Flexible Sourcing Legacy Rationalization Hidden from users Service Reuse Customization in Middle-Tier Services remain Generic Process and Data Integration
- 13. SOA is all about ROI Custom Apps PeopleSoft Point to Point Integrations are costly to develop and maintain … Services Integrations add Value by enabling Flexibility Billing Order Mgmt
- 14. Why SOA Makes Sense: Business Benefits Services are a Language to Discuss Business Processes So IT people can talk with them more easily about solutions Business processes become explicit So they can more easily be understood and improved Applications or business processes might be more easily replaced Because they’re well-defined and discrete
- 15. Why SOA Makes Sense: Technical Benefits Deployment is explicit Bridges Infrastructure and Development Building business processes is faster and cheaper Services can more easily be reused Applications can expose their services in a standard way Applications can be exposed more easily to diverse clients Windows clients, Web Clients, Host-based clients, External Clients, etc…
- 16. Agenda Flexible IT, Better Strategy Designing for Business Processes Developing for Business Solutions Challenges Ahead
- 17. Designing for Business Processes Thinking in Services Orientation Business Services Conceptual Shifts Capabilities Analysis Enterprise Services Scenarios
- 18. Designing Business Processes Identify Business Services Begin Success Fail
- 19. Business Services Steps in the Larger Business Process Enterprises Need Business-Services Projects One or More Services to the World Outside Business Process for a specific aspect Encapsulates Some Database Resident Data Implemented with Business-Logic Data SQL Business Service Services
- 20. Composite Business-Services Processes define Solutions A Business-Service May Be Implemented by Many Business-Services Must Look Like a Single Business-Service Can’t Tell from the Outside Business-Service Biz-Svc Biz-Svc Biz-Svc Biz-Svc Biz-Svc Biz-Svc Biz-Svc Communication with the world outside
- 21. Capabilities Analysis Externalizing the Capabilities and Data Please Do this on my behalf Please provide me some data. Everyone! This data changed. OK, I’ll get back to you when it’s done. OK, here’s what I’ve got. I completed successfully SQL App Internals
- 22. Four Tenets of SOA Rules to Design By Boundaries are explicit Services are autonomous Services share schema and contract, not class Service compatibility is determined based on policy
- 23. Conceptual Shift: Data Questions to Consider What system is Authoritative for this data? How does this version over time? Is this data Idempotent? What external data is needed by which systems? What is the SLA for this data of this data and why? How often does external data change? What aspects of that change are meaningful? How fresh does this need to be in other systems? At what level of detail? What relationships exist between data? What happens when not everything can be changed? What happens when changes fail?
- 24. Conceptual Shift: Capabilities Questions to Consider What are the discrete steps that make up this Business Solution? What are the most important things an application does? What are the scenarios where other applications might request another app to perform an action? What are the most reusable capabilities an application provides? On whose behalf do these actions need to take place? Why might a request be rejected? What SLA is required for the activity?
- 25. Business Services Impact Enables Agility Solutions Focus Flexible and Composable Applications Ability to rapidly Adapt systems to the needs of the Business Compose new ways of doing things by assembling new processes over existing services
- 26. Enterprise Services Scenarios: Integration Patterns Policy and Business Interest Manager Business Entities and PeopleSoft Policy and Business Entities Publishing Endorsable Events
- 27. Policy and Business Interests Request Response Pattern <Body> <LocationList> <Location Id=‘1231’ Name = ‘HQ’ … /> <Location Id=‘5377’ Name = ‘Div’ … /> <Location Id=‘9621’ Name = ‘Site’ … /> </LocationList> </Body> Business Interest Manager A Policy A <Message id=‘ 200 ’> <Request Contract=‘ LocationList ’ Version=‘ 2.2’> <Customer Id=‘AllPeril’/> </Request> </Message> Service Manager <Message id=‘761’> <Response To=‘ 200 ’ Contract=‘ LocationList ’ Version=‘ 2.2 ’> <Customer Id=‘AllPeril’/> </Response> </Message> Stored Procedures User Interface Business Facade Business Logic Common Services Data Storage Typed Datasets
- 28. Business Entities and PeopleSoft Publish Subscribe Pattern PeopleSoft A BizTalk Business Entities A <Message id=‘279’> <Notify Contract=‘ContactInfo’ Version=‘ 1.7 ’> <Action Type=‘Update’ Id=‘1990124’ EntityId=‘197811’/> </Notify> <Body> <ContactInfo Type=‘Original’ Version=‘281’ …. /> <ContactInfo Type=‘New’ Version=‘282’ …. /> </Body> </Message> Other Service Other Service <Message id=‘507’> <Notify Contract=‘ContactInfo’ Version=‘ 1.2 ’> <Action Type=‘Update’ Id=‘1990124’ EntityId=‘197811’/> </Notify> <Body> <ContactInfo Type=‘Original’ Version=‘281’ …. /> <ContactInfo Type=‘New’ Version=‘282’ …. /> </Body> </Message>
- 29. Policy and Business Entities Notification and Conversation Pattern Policy A BizTalk Other Service Other Service Business Entities A <Message id=‘381’> <Notify Contract=‘AddressInfo’ Version=‘1.8’> <Action Type=‘Add’ Id=‘ 171021 ’ EntityId=‘ 197811 ’/> </Notify> </Message> <Message id=‘ 200 ’> <Request Contract=‘AddressInfo’ Version=‘2.2’> <EntityId=‘ 197811 ’/> <Add Id=‘ 171021 ’/> </Request> </Message> <Message id=‘761’> <Response To=‘ 200 ’ Contract=‘AddressInfo’ Version=‘2.2’> <EntityId=‘ 197811 ’/> <Add Id=‘ 171021 ’/> </Response> <Body> <AddressInfo Id=‘ 197811 ’ LocationName = ‘HQ’> <Street Id=‘5377’>201 Jones Road</Street> … . <Country Id=‘ 712 ’/> <AddressInfo/> </Body> </Message> <Message id=‘ 201 ’> <Request Contract=‘CountryInfo’ Version=‘4.5’> <CountryInfo Id=‘ 712 ’/> </Request> </Message> <Message id=‘762’> <Response To=‘ 201 ’ Contract=‘CountryInfo’ Version=‘4.5’> <CountryInfo Id=‘ 712 ’/> </Response> <Body> <CountryInfo Id=‘ 712 ’ Name = ‘<Name>’> <GPSInfo Latitude=’48.17’ Longitude=’91.44’ /> <Capital Name=‘<Name> City’ …/> </CountryInfo> </Body> </Message>
- 30. Publishing Endorsable Events Database Isolation Pattern RATS CSS Database Policy Service Interface Stored Procedures Data Storage Models Common Framework Commands A User Interface
- 31. Agenda Flexible IT, Better Strategy Designing for Business Processes Developing for Business Solutions Challenges Ahead
- 32. Developing for Business Solutions CSS Application Architecture 1.0 CSS Application Architecture 2.0
- 33. CSS Application Architecture 1.0 Separated the layers of an application internally Designed for potential reuse Façade provides security Stored Procedures User Interface Business Facade Business Logic Common Services Data Storage Typed Datasets Dataset changes rippled through the layers Significant amount of code in stored procedures
- 34. Issues with Architecture 1.0 Appropriate for your Initial Implementations Tight coupling across layers Results in brittle code that is not tolerant to data changes Security is Developer Dependent No clear enforcement of Business Rules with Data Business processes are not dynamic Database-centric architecture Significant amount of Code inside the Database Significant amount of SQL-oriented Code in the UI/BL Bound to a delivery (Web or Windows) Significant amount of Code in the UI Deployment is a complex operation
- 35. Design Principles for 2.0 Targeted at Where You are Going Promote Object Oriented Design Patterns Encapsulate Business Data within Rules Focus on Modeling the Domain Isolate dependencies per Layer Reduce Code Duplication Create class hierarchies with inheritance to share implementations – one place to fix Design Interfaces for extensibility Integrate Infrastructure Build in Security, Instrumentation, Logging, etc. XML-centric architecture Allows for DataSource agnostic approach Adds richness of Xml family (XPath, XSL, etc.) Design for reuse: Web, Windows, Services Simplifies Packaging and Deployment
- 36. CSS Application Architecture 2.0 Underlying Domain Model implements the local business processes of an application Designed for Reuse Designed to be independent of physical storage Data Storage Models Common Framework Domain Models User Interface Web Framework External Services Interfaces Services Framework Models
- 38. Models and Commands CommonFramework abstracts Storage Data Storage Models Commands Web Services MSMQ XML ICommand
- 39. Domain Driven Design Domain Models Persistence Models Service Models Contract Model ID Version Schema Fields Contract Model ID Version Schema Fields UI Models UI Model ID UI Fields UI Behaviors UI Model ID UI Fields UI Behaviors
- 40. Conceptual Shift: Developers Questions to Consider What Responsibilities does this application have? What Entities do I need to work with? How do I model these things and their relationships? What Business Process is this application supporting? Is it a part of a larger Process? What happens when the larger process fails? Design for the Business Processes Stop designing from the Database Stop designing from the UI
- 41. Conceptual Shift: BAs, BSLs Questions to Consider Why does the Business need this application? Where are the Business processes evolving? i.e. where might change be inevitable? How can a Business Process be automated What steps to be taken? What already exists? Stop recreating Screens from other Systems…
- 42. Agenda Flexible IT, Better Strategy Designing for Business Processes Developing for Business Solutions Challenges Ahead
- 43. Design Artifacts High level to Low Level Enterprise View Application View Feature View
- 44. Enterprise View Overall Solution Analyze the impact on the Enterprise What is the organizational impact of… Define the steps of the Solution in an abstract manner Identify the capabilities expected of each Service Provider Determine failure paths What are the expected inputs and outputs in each Business Process Step
- 45. Enterprise Business Process Overall Solution View Begin Success Fail
- 46. Application View Capabilities Definitions Design the local business process as series of small abstract steps What is the responsibility of this application or service? What features are required to process the inputs into the outputs Work backward from the outputs What abstract objects (responsibilities) are required to execute this process? How does this fit or not fit with the overall domain model Focus on abstract types (Interfaces, Abstract base classes) Identify the relationships and dependencies within the Domain and within each layer
- 47. Application Level Processes Domain Models Persistence Models Service Models Contract Model ID Version Schema Fields Contract Model ID Version Schema Fields UI Models UI Model ID UI Fields UI Behaviors UI Model ID UI Fields UI Behaviors
- 48. Feature View Low Level Implementation Details Low level design of the internals of the steps of a local business process Design the specifics methods and properties of the objects involved Detailed definition of the Contracts required to support the services Design of the concrete classes that support the abstractions What factories are needed? How will a sub-type be defined?
- 49. Leverage the Artifacts GEA Model Business Process Models Stems from the Business Activities Business Component Model High level view Take it to the next level of detail
- 50. Challenges Ahead Aspects of Change Adopting an SOA Adopting the Common Framework Change Issues
- 51. Aspects of Change Dimensions of Impact Process SLAs Technology Data People
- 52. Adopting an SOA
- 53. Change Issues Dialogs for moving forward
- 54. Summary Evolution of existing Architecture Architectural Solution for integrating Authoritative Sources Actionable patterns to move the Automation Plan forward
Editor's Notes
- #3: Key Points: This presentation is for Sr Management. Purpose is to understand the content, style, examples and message that is being presented to the BA/PM/Other Managers and to Developers in order to endorse and reinforce it. The meeting will be interactive from Management point of view (impact, training, skills, timelines etc) in addition to the content discussion. This presentation should contain material that contains the salient messages without an instructor (Notes, bullet points will do), so that we can make it available to others to continue to propagate the message. We will work out a comprehensive documents/presentation later. Examples should slant FMG towards business scenarios. Material presented at EBC is too sparse (slanted towards implementation) We need to revise this to include the following topics/flow Problems we are trying to solve and advantages (stock material from many SOA presentations) What SOA is all about., governing principles When we talk loosely coupled services, what areas should be considered. Example questions to seek solutions Different patterns of integration Inside and outside the box difference (SOA outside,Framework Inside) Lead in to what is the framework for How the developers have to think (SRP etc). How the BA’s need to analyze (decomposition , UI, process, etc) We will reinstate the other sessions after the input from Sr Management presntation
- #6: Start with: Problems we are trying to solve and advantages (stock material from many SOA presentations) Most CEOs would cringe at the idea that IT architecture—the way technology resources are organized—determines the agility with which companies can carry out good strategy. Yet the difficulty and cost of modifying today's rigid IT architectures, dominated by big enterprise applications such as ERP, can be so high that some companies would rather abandon new strategic initiatives than make a single change to the applications they already have in place. Good news is on the horizon in the form of service-oriented architectures, which promise to reduce if not remove the current obstacles. The take-away In this article, John Seely Brown and John Hagel III compare flexible service-oriented architectures to the more rigid IT architectures that preceded them. The authors make the case that information technology, far from lacking strategic worth, determines strategic value.
- #7: Speak the problems being solved here: Focus on Business Solutions, adaptabilty, etc,
- #8: We are going to hear this term a lot today, so let’s provide a definition up front.
- #9: What is SOA is all about? It has a value to different aspects of an organization, but all have a common theme in Adaptability
- #10: Define the Iconic representation of Services that is used throughout the presentation. Key message here is that a Service is a wrapper around an application’s internals. The major difference being that a Service exposes a means to interact with the Data and Capabilities of an application without building a dependency on how that application performs that capability or compiles the data entity. External Consumers depend on the Capability or the Data, not the means.
- #11: For the Business Audience focus on the top quadrants. Key is Business Process oriented (in the large and in the small…)
- #12: Services are not islands that every other application that requires their capabilities talks to directly. Message Oriented Middleware (for Integration), Management and Monitoring capabilities function as shared capabilities over the Services to enable aggregation and User Specific Experiences. Mid-tier rationalization increases service-level accountability and information accessibility reducing transaction latency and permitting rapid channel integration.
- #14: Originally connections are point to point and expensive to maintain and build. = > Costs Building Services on top of existing applications creates an integration layer that does not require a rip and replace of the existing application. Explain why this is very different from point to point batch processing. Reuse and Leverage
- #15: Enable a language for discussions of Processes and Technologies The abstraction of the language
- #18: When we talk loosely coupled services, what areas should be considered. Example questions to seek solutions
- #19: Key message is that a process is not within a system, its across the organization. Use the example of: Location added with a TIV > 2,000,000 Insurance Teams need to Reevaluate Location needs Engineering assessment Will then require Policy
- #20: Think of it as an actionable Data Container. It’s internals are meaningless, but it expresses its capabilities and the data that it is responsible for
- #21: Put together an example here: CSS is a
- #22: When looking at a system, what are the Capabilities it needs to offer for what sets of data?
- #27: Different Patterns for Integration
- #28: Request / Response Scenario Target technology: Web Services WSE Indigo This needs to de-technofied…
- #29: Straight Pub/Sub Target Technology: BizTalk
- #30: Pub-Sub-Conversation Scenario Target Technology: BizTalk WSE
- #31: Target Technology: Yukon Service Broker DTS Reporting Services
- #33: Inside and outside the box difference (SOA outside, Framework Inside) Lead in to what is the framework for
- #38: The namespaces of the commonframework provide all of the relative building blocks applications need: Data container objects Collections Infrastructure The common things brought together in a consistent API
- #39: The core theory of the Common Framework has Services in its thinking. By isolating the object that developers model against from the underlying the medium where the data originates allows them to focus on solving their applications problems rather than the integration problems…
- #40: Business Processes are built within the application as well – promotes reusability by designing for encapsulation Define Business Domain. How the developers have to think (SRP etc). Developers need to focus on modeling the objects of a system that need to interact. Focusing on building a rich Domain model of objects and interrelationships, both internal and external to their application. How that data gets to their system is independent of the work that needs to be done with it. Events of meaning that have been discovered need to be raised so other systems can do their thing…
- #41: How the developers have to think (SRP etc).
- #42: How the BA’s need to analyze (decomposition , UI, process, etc)
- #44: Design To the business process not the wire frames
- #46: Key message is that a process is not within a system, its across the organization. Use the example of: Location added with a TIV > 2,000,000 Insurance Teams need to Reevaluate Location needs Engineering assessment Will then require Policy
- #48: Business Processes are built within the application as well – promotes reusability by designing for encapsulation Define Business Domain. How the developers have to think (SRP etc). Developers need to focus on modeling the objects of a system that need to interact. Focusing on building a rich Domain model of objects and interrelationships, both internal and external to their application. How that data gets to their system is independent of the work that needs to be done with it. Events of meaning that have been discovered need to be raised so other systems can do their thing…
- #51: Technology Changes Organizational Changes Behavioral Changes