1 / 26

Lessons Learned Initiating a SOA

Lessons Learned Initiating a SOA. Andrew Ide April 30, 2008. Agenda. Introduction SOA Implementation Stages Initiate Develop Roadmap Execute Plan Final Thoughts Example Services Integration Manager Service Travel and Expense Voucher to GDS Service. Introduction.

sissy
Télécharger la présentation

Lessons Learned Initiating a SOA

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Lessons LearnedInitiating a SOA Andrew Ide April 30, 2008

  2. Agenda • Introduction • SOA Implementation Stages • Initiate • Develop Roadmap • Execute Plan • Final Thoughts • Example Services • Integration Manager Service • Travel and Expense Voucher to GDS Service

  3. Introduction • This presentation conveys how one organization initiated the implementation of a Service Oriented Architecture (SOA). There are other approaches and methods not covered. • Implementing organization leveraged BEA’s “SOA Practitioners’ Guide” for method guidance. • Organization is a Commercial Software vendor. SOA services scaled to support the following environment: • 300,000 users • 3,700,000 expense vouchers annually • Organization implemented Progress Software’s Sonic Enterprise Service Bus

  4. SOA Implementation Stages From BEA’s “SOA Practitioners’ Guide”

  5. Initiate • During this stage, we worked to develop a Concept of Operations which guided the overall project effort. It outlined the project’s objectives, detailed the project organization and governance, listed the project team members and their responsibilities, and provided general timelines & deliverables. • It combined business and IT efforts and was approved by the governance body. • It was during this stage that our IT and business organizations determined which business functions and underlying processes SOA could potentially enable, enhance, or even replace. These where articulated within the ConOps and informed the follow-on stages. • Initiate Stage Deliverables • SOA Concept of Operations •  Initiate Stage Team • Project Lead: Solution Architect • Project SME: SOA Technical Architect

  6. Develop Roadmap • During this stage our team: • Created a roadmap which detailed the specific steps for conducting a SOA assessment for the organization • Developed the SOA principles which guided the assessment • Defined the future reference architecture based on the outcome of the assessment • And provided the steps necessary to make the transition from the current state to the future state. • This stage was highly dependent on balancing sound business judgment against the technologically seductive call to see all processes as potential services. • During this stage, the team needed to be guided more from a business trade-off perspective than from a technical feasibility perspective. For this reason, it was important that the effort be guided by a leader with keen business acumen and not necessarily by the best technologist. • While business acumen traits are always present in the best technologists, it was our experience that it was often biased by the future promise of new technologies and approaches. Large scale change initiatives often benefit from a more analytical approach rooted in realistic expectations of what can be accomplished within a dynamic organization.

  7. Develop Roadmap (cont’d) • An important aspect of this stage was guiding the proposed SOA roadmap through the organization’s governance structure. • It was critical that all stakeholders embrace and adopt the roadmap as it was a critical component of future Enterprise Architecture, technology planning and budgeting processes. • It was the responsibility of the SOA Project Lead to work closely with the organization’s leadership to ensure that all appropriate control gates and milestones were met in this regard. •  Roadmap Stage Deliverables • SOA Assessment Targets: determine which business processes and applications should be analyzed as service candidates. • SOA Principles: clear and concise SOA principles ensure that balanced assessments can be made. • SOA Reference Architecture: describes the “future state” for the IT organization. It should define the business “end-state” and articulate the technology “end-state” necessary to support it. • SOA Roadmap: the roadmap should clearly define the phases for deploying business solutions and the infrastructure required to support them. It should also identify opportunities for quick wins to validate the benefits of SOA. • Roadmap Stage Team • Project Lead: Solution Architect • Project Analyst: Solution Architect • Project SME: SOA Technical Architect

  8. Execute Plan • During this stage the SOA roadmap was decomposed into an execution plan that detailed the projects needed to move towards the future state. Execution was responsible for two major areas. • The first was the specification and oversight of the projects necessary to bring the SOA roadmap to life. The SOA team was involved with and helped to coordinate the delivery of projects in the sequence described in the roadmap and built out the infrastructure as required to provide the desired business capability. • Secondly, the SOA team worked to implement the necessary governance, organization and methods to enable efficient project execution. • It was during this part of the process that an experienced SOA Technical Architect was critical. • This team member was able to bring critical project experience to bear to ensure that appropriate standards and technologies were selected, that life-cycle methodologies were appropriately tailored, and that project requirements were clearly articulated. • Additionally, the SOA Technical Architect provided insight into general project design and architectural approaches gleaned from real-world implementation experience.

  9. Execute Plan (cont’d) • Execute Stage Deliverables • SOA Execution Plan: detailed the specific projects and their sequence necessary to implement the SOA Roadmap. • Individual Project Plans: provided project goals and objectives, team structure, tasks and milestones. •  Execute Stage Team • Project Lead: SOA Technical Architect • Project SME : Solution Architect

  10. Final Thoughts • You will need to tailor implementation stages for your organization. • It is important during the initial planning stage to ensure the project’s plan is optimized to support your specific environment. • The stages outlined in this presentation and in BEA’s guide serve as a baseline for planning discussions. • Implementing SOA is a complex endeavor that requires technical experience complemented by keen business acumen. • The landscape is littered with SOA implementations that do not satisfy the expectations of the organizations that implemented them. Many of these “poor outcomes” have to do with failures in front end analysis and services definition. • Having the appropriate staff and approach will help to ensure that you are successful in moving towards this innovative method of delivering business benefit.

  11. Example Services • Integration Manager Service • The Service solved a complex multipoint integration maintenance problem. It enables the integration of many disparate systems and eliminates the need to maintain the integration points when one of the systems changes. • Travel and Expense Voucher to GDS Service • The Service receives industry standard reservation information in the form of a Passenger Name Record (PNR) from the Global Distribution System (GDS). The service transforms the PNR into XML which then enters the organization’s systems. Upon route and approval, the organization’s system generates updated XML which traverses the ESB and updates the GDS to issue the approved tickets.

  12. Integration Manager Service

  13. Why Integration ManagerBack-end simplification • Replace or enhance existing legacy system interfaces • Accounting system interfaces • Disbursement system interfaces WHY? To reduce or eliminate the cost of interface maintenance WHY? Significantly reduce the cost of upgrading capabilities • Extend integration to other areas of previously untapped value • Migrate from a batch to real-time interface WHY? Utilize the features of your latest Accounting/ERP system. • Interface with HR and other systems of record to reduce redundant data WHY? To eliminate the need to maintain data in more than one place

  14. Accounting System How Integration Manager WorksAccounting Systems IM

  15. Accounting System Disbursement Systems How Integration Manager WorksMultiple Accounting Systems IM

  16. Accounting System Data Warehouse How Integration Manager WorksData Warehouse and Accounting System IM

  17. Human Resources How Integration Manager WorksHuman Resource Systems IM

  18. Enterprise Portal How Integration Manager WorksEnterprise Portals IM

  19. Human Resources Enterprise Portal Accounting System Disbursement Systems Data Warehouse How Integration Manager WorksEverything! IM

  20. Service Highlights • System event based on action codes in routing lists • One way XML message to IM for distribution and processing • IM Data Warehouse, XML consumer, SQL Queries • Included SonicESB integration suite • In-bound events based on Web Services and XML messages • Maintain all data via the web services interface • Access to System data to enable Enterprise Portals

  21. Main BenefitsEase of Integration • Reduce the cost of Interface Maintenance - Standard XML and Web Services • Ease the burden and time to upgrade to the newer System versions - Re-use the existing XML based interface • Readily expand the level of integration between System and your enterprise - Leverage the built-in Enterprise Service Bus • Integrate System into YOUR business processes - Leverage the built-in Enterprise Service Bus BPM features • Create automated and manual Business Processes - Leverage the built-in Enterprise Service Bus BPM features

  22. Travel and Expense Voucher to GDS Service

  23. Overview • Automatically creates Travel Authorization from Reservation information • Capture air, hotel and car costs • Derives per diem rate from the hotel address • Updates Travel Authorization when Reservation Information is changed • Keeps Travel Authorization data in sync with PNR data • Automatically Tickets when Travel Authorization is approved • Updates PNR with accounting information • Automatically cancels trip reservations if Travel Authorization is cancelled • Cancels PNR in the GDS when Travel Authorization is cancelled

  24. PNR PNR PNR PNR PNR PNR PNR PNR PNR Reservation Data Reservation Data Reservation Data TA TA TA TA Email OBT TA TA Service Walkthrough Step 1 Traveler Makes a Reservation Step 2 GDS Creates an PNR Step 3 System grabs PNR and sends to T&E system Step 4 System Sends Travel Authorization to Traveler GDS Step 5 Traveler completes Travel Authorization Step 6 System Sends TA to Travel Authorizer Step 7 System Returns PNR to GDS Step 8 Agency QC System Processes PNR

  25. Service Benefits Significantly increased the productivity of travelers and travel preparers • Reduced the amount of redundant data entry • Automatically created Travel Authorization document • Automatically derived the per diem location Significantly reduced the cost of travel procurement • Increased the number of touchless transactions • Used any supported GDS (SABRE, Galileo, Worldspan) • Used any Online Booking Tool (GetThere, Trip Manager, etc.)

  26. Discussion

More Related