İndir
Upcoming SlideShare
Loading in...5
×

Like this? Share it with your network

Share
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
1,285
On Slideshare
1,285
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
0
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • SPEAKERS NOTES: Introduce title and speakers names and titles/roles Logistics: Please shut off all cell / mobile phones Ask questions as we go, however, in the interest of time, we may defer some questions/discussions to after the session
  • MAIN POINT: The primary goal of this session is to help you learn practical, realistic ways to begin implementing a Service Oriented Architecture (SOA) in your application
  • SPEAKERS NOTES: Introduce the agenda and review each section
  • MAIN POINT: Summary from INT-1: Achieving SOA: The Product Solution breakout session – SOA and SOBA is an architectural concept – not a specific product, application, standard or set of rules. After the dot com boom and bust, an new era of cost containment began. IT organizations were asked to do more with less: make use of existing assets and resources to get the job done. No longer is “rip and replace” a viable alternative. Instead, as much value as possible needs to be extracted from existing systems. Loose coupling, no hard connections No one technology, standard, rules etc … more of an architectural concept! GARTNER Definition: SOA is a set of guidelines, principles and patterns (topological and communications related) for defining a system solution based on loosely coupled software services. (AD95 - K2)
  • MAIN POINT: Summary from INT-1: Achieving SOA: The Product Solution breakout session – Introduce the SOA Maturity Model as a high-level model for a SOA approach built from Progress best practices. It provides a basic road map for any customer to follow to achieve an SOA.
  • MAIN POINT: Summary from INT-1: Achieving SOA: The Product Solution breakout session – stress the three main points/conclusion ORIGINAL NOTES: However, it is important to not overload your SOA project and expectations: Focus on the one or two benefits that are important to the business unit. Build success one project at a time. The great thing about SOA – if done correctly - is that it supports this incremental adoption approach – so you can build a more efficient IT organization that responds better to business requests Minimize the risk - take it at a pace to suit you business, your industry - should not be disruptive
  • MAIN POINT: The SOA maturity model is designed to provide a model for how to achieve SOA. However, you cannot reach the top in one step SPEAKERS NOTES: Reiterate how business needs to get more formalized in their processes as well – in some part thanks to SOX and other control initiatives (Bernard??)
  • SPEAKERS NOTES: Introduce the agenda and review each section
  • MAIN POINT: The SOA maturity model is designed to provide a model for how to achieve SOA. However, you cannot reach the top in one step SPEAKER’S NOTES: Reiterate that the SOA maturity model is a “big mountain to climb” then transition into the agenda
  • MAIN POINT: You will need two architecture during the transition period to allow for small incremental steps
  • Comparing conventional integration architectures on the left with a service oriented architecture on the right we can see a stark difference. Data is XML now. Communications are Integration ,, asynchronous and reliable Process logic is coherently managed in a separate fasihon so that it can be changed easily Now no one is going to rip everything out and replace it with a SOA or ESB – just because they can. But an incremental approach toward the clean architecture of a SOA or ESB is a vision all IT professionals should understand and strive for.
  • Existing Architectures: Most current architectures were constructed in piecemeal fashion, across multiple different implementation groups, using multiple different architectural approaches.   These multiple architectures are disparate and have evolved over a period of time without the benefit of an overarching architectural framework.  As a result, these architectures have shortcomings that manifest themselves by constraining the delivery and operational capabilities of the business.  There is tightly-coupled integration across the architecture, complicating modifications.  Architectural changes, application enhancements, and defect fixes are very time-consuming and complicated.   As a result, changes take much too long from requirements to implementation, and the changes (as well as support) are costly.  In addition, many advancements in technology cannot be taken advantage of because of the current architecture. New SOA (ESB Architectures): Implementing SOA in an incremental approach, requires you focus on a single set of functionality. In the first effort, you may simply be replacing connectivity between two different applications, possibly with an external partner application. A first phase would include building in an ESB as part of the new architecture and implementing a single set of services across the necessary applications to communicate over that service.
  • MAIN POINT: SOA requires discipline in the development process for success. The challenge to transforming the SOA process is like carving three individual bricks out of a brick wall. App Development groups do not know where the specific bricks are (poor documentation) and do not want to admit to their users/customers (perception as unprepared). But in order to handle the complexities of new software development processes as well as having two architectures, there needs to be some level of process in place.
  • Main Point: You must change your processes in order to succeed at SOA Action Item: Start tactical, wrapping and reusing established systems where high value can be gained. Develop a long-term evolution plan of new development or legacy restructuring.
  • MAIN POINT: There is no best process to implement – it is custom to each development organization.
  • MAIN POINT: SOA requires developers to adhere to a process. The advantage of strict adherence is that parallel development threads can be performed and then results merged together at the end.
  • MAIN POINT: Review the details of a SOA process contract SPEAKER’S NOTES: Query audience on how many have used internal procedures, super procedures, etc from The advantage of strict adherence is that parallel development threads can be performed and then results merged together at the end.
  • OpenEdge 10.1A Overview Product Marketing 10.1A FCS PUOL MAIN POINT: Transformation provides the best approach for building a strong, underlying foundation.
  • MAIN POINT: SOA success requires you to think strategically and act tactically. Do not try and have a big-bang SOA strategic or R&D project without a tactical business improvement. Do not try and have a tactical business project and build SOA elements into it without having a long-term SOA vision you are trying to achieve.
  • MAIN POINT: For the strategy to succeed, you need executive commitment, links to business agility, and proper expectations SPEAKER’S NOTES: Stress that developer training may expand into early prototype systems and development of non-critical applications
  • MAIN POINT: For the strategy to succeed, you need executive commitment, links to business agility, and proper expectations SPEAKER’S NOTES: Stress that developer training may expand into early prototype systems and development of non-critical applications
  • MAIN POINT: For tactical success, focus on high-value business project with SOA characteristics and build in limited SOA Architecture & processes
  • MAIN POINT: Revisit the Two Architectures diagram as example of building SOA infrastructure into first project
  • MAIN POINT: For tactical SOA success, focus on architectural gaps, process improvements and the next high-value project
  • MAIN POINT: Additional Projects extend the initial SOA architecture throughout the application
  • SPEAKERS NOTES: Introduce the agenda and review each section
  • MAIN POINT: Communication breakdowns are the primary threat to a successful SOA effort.
  • MAIN POINT: Even if you are just 3 developers, you will need to interact with other systems and developers
  • MAIN POINT: Change is the only constant in business – you will need to be positioned to adapt to it
  • MAIN POINT: Process problems are the second common threat to successful SOA efforts
  • MAIN POINT: Process problems are the second common threat to successful SOA efforts
  • OpenEdge 10.1A Overview Product Marketing 10.1A FCS PUOL MAIN POINT: OERA helps a transformation by providing a proven architecture approach – so we are providing not just the development tools, but also the best practices and know-how
  • MAIN POINTS: Selecting the right first project is key to early SOA success and building momentum OTHER NOTES: Business Qualification Pick a use case that demonstrates real business value to prove the incremental value of the SOA/ESB Don’t just replace a point-to-point integration with an SOA/ESB Based integration – find unique business value Technical Qualification Pick a project exposes the unique capabilities of Sonic ESB Pick something that is typically not able to be handled by other integration approaches Rich Integration Scenario (Performance, Agility, Reliability, etc..) Service and Event Reuse Potential Will the selected project result in reusable events and services that can be leveraged in other areas? Make sure events/services are common to other parts of the application for reuse. 1-use/1-time solutions are not good first candidates. The over-arching goal for the first use case is to demonstrate value in each of these areas to show the power of the ESB and ease adoption within the enterprise.
  • SPEAKERS NOTES: Introduce the agenda and review each section
  • MAIN POINT: Use the SOA Maturity Model to define your high-level strategic goal and perform tactical steps to help guide you there
  • MAIN POINT: Where to go for additional information
  • MAIN POINT: Other SOA sessions here at PTW and held at Exchange 2007 in June

Transcript

  • 1. INT-3: Realistic Service Oriented Architecture Approaches Michael Boyd & Bernard Bresser Progress Software
  • 2.
    • How to begin implementing a Service Oriented Architecture (SOA), one step at a time
    Realistic SOA Approaches What you will learn today
  • 3. Agenda
    • The SOA starting point
    • What you will need
      • A tale of two architectures
      • Process, process, process
      • Think strategically, act locally
    • Common pitfalls
    • First steps when you get back home
    Realistic Service Oriented Architecture Approaches
  • 4. Introducing SOA & SOBA
    • An approach for building agile and flexible business applications
      • Loosely coupled services = flexible business processes
    • SOA is not
      • A product or application
      • A specific technology
      • A specific standard
      • A specific set of rules
    S ervice- O riented A rchitecture > S ervice- O riented B usiness A pplications
  • 5. The SOA Maturity Model Optimization Transformation Responsiveness Functionality Cost Effectiveness Initial Services Architected Services Measured Business Services Optimized Business Services Business Services Collaborative Services The Impact of SOA
  • 6. SOA In Summary
    • SOA
      • The architecture for the agile business
    • SOA is a design approach
      • Not a technology
    • Take small steps
      • Evolution, not revolution
  • 7. The SOA Maturity Model Optimization Transformation Responsiveness Functionality Cost Effectiveness Initial Services Architected Services Measured Business Services Optimized Business Services Business Services Collaborative Services The Impact of SOA
  • 8. Agenda
    • The SOA starting point
    • Starting your own evolution
      • A tale of two architectures
      • Process, process, process
      • Think globally, act locally
    • Common pitfalls
    • First steps when you get back home
    Realistic Service Oriented Architecture Approaches
  • 9. A Tale of Two Architectures You cannot reach the top of the SOA mountain overnight Initial Services Architected Services Measured Business Services Optimized Business Services Business Services Collaborative Services
  • 10. A Tale of Two Architectures
    • You will need two architectures during the transition period
    • This allows for small, incremental steps
    New Service Oriented Architecture Existing Architecture
  • 11. A Tale of Two Architectures
    • Communications is conducted point to point, synchronous and unreliable
    • Process logic is fragmented across applications and platforms and implemented differently in each place
    • Data comes in multiple incompatible formats
    • Communications are direct to a centralized service bus
    • Process logic is coherently defined in a single model which can be edited and redeployed quickly
    • Data comes expressed as XML
    Existing Architecture New SOA (ESB)
  • 12. Example: Using Two Architectures P3 P1 P2 Order Mgmt Order Process Business Applications Finance Supplier Mgmt CRM Tracking Service Partner Back Office MFG SCM Adapter Adapter Integration Broker New SOA (ESB) Existing Architecture Adapter Order Fulfillment CRM Enterprise Service Bus (ESB)
  • 13. Process, Process, Process “ Trying to extract business functions from larger applications is like trying to extract bricks from a large wall. It's possible, but not simple. ” Gartner – September 2005
  • 14. Process, Process, Process
    • To move faster to meet the market, you cannot just code your way out of it –
    • you must change your processes
    • Success is using “just enough process” (CMMi Level 3-ish…) It never means “use no process”
    • Expect that development styles will change as SOA implementations begin
  • 15. Process, Process, Process
    • Combination of steps that allow you to meet your business’ needs every time
    What is the Best Process?
  • 16. Process, Process, Process
    • Moving to SOA requires developers to:
      • Specify contracts and interfaces
      • Harvest existing systems for logic
      • Wrap legacy systems
      • Define system monitoring and management
      • Specify service policies & granularity
        • How small / big is a service ?
        • You don’t want 74 similar ones !
    SODA - Service Oriented Development of Applications
  • 17. Process: Contracts and Interfaces
    • Input from calling service
    • Data format and type (or what’s the XML Schema)
    • Service functionality options (or actions or events)
    • Details on business process flow (i.e. UML graphic)
    • Output from Service:
    • Data result from service events
    • Error status or results from service
    • Other Details:
    • Service Owner
    • Service Design
    • Service History
    • Service Cross-Ref
  • 18. Process: Harvesting Existing Logic
      • Guideline how to approach assessment, analyses, redesign, harvest, build and test…
      • … NOT the enforced way how to get there!
      • Break the larger project into manageable smaller iterations to mitigate risk
      • Search on “Transform” in PSDN
    Application Transformation Approach Awareness Transformation Assessment Analysis & Modeling Redesign & Harvest Build & Test Transformation Continues… Engagement Capability Gap Fulfillment Project Planning & Management Commitment
  • 19.
    • Strategic SOA
      • Define your long-term SOA vision
    Think Globally, Act Locally Succeed by thinking strategically but acting tactically
    • Tactical SOA
      • Implement first elements of your SOA vision on next business-based project
      • Add SOA elements into each successive business-based project until SOA is realized
  • 20. Think Globally – Strategic SOA
    • Get executive commitment to an overall SOA strategy
    • The Key reason for SOA is Business Agility
      • Code reuse is just a means to get there
    • If possible, get funding for some overall SOA infrastructure needs
      • Resource Management – roles & duties
      • Developer training
      • Cross-application tools
    • Set expectations of evolving process
    In order to be agile, businesses need disposable business rules – ones that are cheap and easy enough to throwaway and replace as business changes. - Ronald Ross, Business Rule Concepts “Father of Business Rules”
  • 21. Think Globally – Strategic SOA
    • Get executive commitment to an overall SOA strategy
    • The Key reason for SOA is Business Agility
      • Code reuse is just a means to get there
    • If possible, get funding for some overall SOA infrastructure needs
      • Resource Management – roles & duties
      • Developer training
      • Cross-application tools
    • Set expectations of evolving process
  • 22. Act Locally – Tactical SOA
    • Find high-value business project
      • Loosely coupled business processes
      • Can benefit from Business Process Changes
      • Has high-value to the business
    • Build new SOA and funding into project plan
      • Architect in minimum SOA
      • Include new processes
        • Service Granularity
        • Service Contracts
  • 23. Act Locally – Tactical SOA: the First Project P3 P1 P2 Order Mgmt Order Process Business Applications Finance Supplier Mgmt CRM Tracking Service Partner Back Office MFG SCM Adapter Adapter Integration Broker New SOA (ESB) Existing Architecture Adapter Order Fulfillment CRM Enterprise Service Bus (ESB)
  • 24. Act Locally – Tactical SOA
    • SOA implemented
      • Refine architectural gaps
        • Context and Security are most common
        • Service Granularity
        • External Service Interfaces
      • Project Retrospective
        • Look for process improvements
    • Repeat on next high-value business project
      • Consider as an “SOA Tax” on development
  • 25. Act Locally – Tactical SOA: Additional Projects P3 P1 P2 Order Mgmt Order Process Business Applications Finance Supplier Mgmt CRM Tracking Service Partner Back Office MFG SCM Adapter Adapter Integration Broker New SOA (ESB) Existing Architecture Adapter Adapter Adapter Order Fulfillment CRM Enterprise Service Bus (ESB) Enterprise Service Bus (ESB)
  • 26. Agenda
    • The SOA starting point
    • What you will need
      • A tale of two architectures
      • Process, process, process
      • Think strategically, act locally
    • Common pitfalls
    • First steps when you get back home
    Realistic Service Oriented Architecture Approaches
  • 27. Common Pitfalls: Communication
    • Clear Roles & Responsibilities
    • Communicate the Vision
      • Include full team – business, development (IT), and users
      • Keep the SOA Vision simple
      • Actively sell to the business the agility values of an SOA approach
    • Communicate the Technical Reality
      • Initial prototypes include experimenting
    • Over-communicate to the entire team
      • Reiterate the benefits of the change
    It’s more about people than technology
  • 28. Common Pitfalls: Process
    • We only have three people, we don’t need process – we just talk about it…
      • But how do you open to external services?
    Is this what you are thinking…?
  • 29. Common Pitfalls: Process
    • But I don’t need SOA now…
      • But when will the business change?
        • Mergers & Acquisitions
        • Competitive Challenges
    Is this what you are thinking…?
  • 30. Common Pitfalls: Process
    • Need “Just Enough Process”
      • Rigid enforcement of process
        • If you are lax, problems will overwhelm you
        • Better to identify problems and fix process
    • Clear Roles & Responsibilities
      • Especially Architect and Business Analyst
    • Training on new approaches
      • Modeling business processes
      • Documenting service contracts
    Coordinating your development work
  • 31. Common Pitfalls: Process
    • Practice new approaches
      • Utilize the OERA
      • Separation of Business Logic
      • Gain experience with new tools
      • Understand the standards:
        • Technical: Web Standards, JMS
        • Industry: How does your domain share data?
    Coordinating your development work
  • 32.
      • Guideline how to (re-)architect a modern application..
      • ..NOT the enforced or only way to do it!
      • Prioritize! Maybe you need n-tier or integration first before separating ALL the layers, all the clients, all data access, etc!
    Provides a structured and planned to a new architecture Common Pitfalls: Process OpenEdge ® Reference Architecture Presentation Business Services Data Access Data Sources Common Infrastructure Enterprise Services
  • 33. Common Pitfalls: First SOA Projects
    • Business Project Qualification
      • Ensure there is an immediate business ROI
        • Can this help us grow revenue?
        • Reduce expenses?
        • Improve efficiency?
    • Technical Qualification
      • Define Integration solution for problem
    • Service and Event Reuse Potential
      • Simplify follow-on projects with common services and infrastructure
    Focus on the quick success
  • 34. Agenda
    • The SOA starting point
    • What you will need
      • A tale of two architectures
      • Process, process, process
      • Think strategically, act locally
    • Common pitfalls
    • First steps when you get back home
    Realistic Service Oriented Architecture Approaches
  • 35. Realistic SOA Approaches
    • A SOA strategy is incremental and progressive
      • Follow the maturity model and have clear, realistic objectives
    • Be Strategic AND Tactical
      • Set your Vision and Implement in Steps
    Success Factors
    • Steps to Success
    • Define a SOA Vision to achieve business agility
    • Determine where you are in the SOA Maturity Model and key goals and key practices to achieve the next level
    • Use high-value business projects for your first steps
    • Build and refine “just enough process” for your needs
  • 36. For More Information, go to…
    • PSDN
      • A New Service-Oriented Architecture (SOA) Maturity Model
      • Principles of a Service-Oriented Architecture
      • Fundamentals of Service–Oriented Architecture
      • Service-Oriented Architecture: Overview and Business Drivers
      • Design Best Practices: Methodology using Patterns
      • SOA Worst Practices, Volume 1
      • Expertise Centers: SOBA & SOA Infrastructure
      • OpenEdge ® Evaluation Kit and Product Tour
    • Progress eLearning Community:
      • SOA Essentials for OpenEdge Developers
      • SOAP for OpenEdge Developers
      • What's New in OpenEdge 10.1: SOA Support
      • Service Oriented Integration with Sonic ESB ® 7.0
  • 37. Relevant PTW / Exchange Sessions
    • PTW:
    • Achieving SOA: The Product Solution
    • Transactions in a SOA World
    • Implementing ESB Processes with OpenEdge and Sonic
    • Exchange 2007:
    • SONIC-2: Enterprise SOA Implementation: What Your Mother Failed to Tell You
    • INT-4: Introducing Sonic ESB
    • SONIC-5: Global Approach to SOA Enabled by Sonic ESB
    • ARCH-7: A Class-based Implementation of the OERA
    • SONIC-8: Extend your ESB with SOA Management
    • INT-11: It’s Monday Morning, Do You Know Where Your Service Has Been?
  • 38. Questions?
  • 39. Thank you for your time
  • 40.