Click here to download Gene Leganza's Presentation

828 views
795 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
828
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Join Gene Leganza, VP of Government Research, Forrester, as he discuses how federal civilian, state and local agencies are deploying SOA to change the way services are delivered. During this session, Leganza will outline methods for breaking down silos, lowering costs and defining how you can use these efforts to see measurable ROI in the future. For the most updated Speaker and Agenda information, visit www.soaexecutiveforum.com/gov . Mr. Leganza and other guest speakers at the SOA for Government Executive Forum will be attending the executive luncheon, open to all attendees.
  • Service interfaces are the core leverage point of SOA. As a digital representation of your business, service interfaces are the key locus of business value and flexibility. Centered around service interfaces, your SOA Platform must be designed around and for delivering the value of services. Forrester boils it up into three core value propositions: 1. Enabling deep, rich business connections Integration across hard technology boundaries Deep and broad business integration Flexibility to meet diverse quality of service demands 2. Enabling rapid, flexible business change Faster, incremental delivery — alignment of business and IT speed of change Flexible ongoing change Business rules built via both traditional application code and metadata-based processes and policies 3. Enabling business control Monitoring, management, and control of service delivery Incremental accounting for IT costs Business visibility into business operations represented by service requests/responses These three core value propositions are the drivers for three major design centers for an SOA platform. A fourth design center covers your core application platforms. In this diagram, Service Clients represents the tier of architecture above services, which connects your services to many different channels through which they are accessed. Forrester’s strategic vision for the SOA platform is explored further in the March 29, 2005, Trends “Your Strategic SOA Platform Vision.”
  • The starting point for your SO-IT transformation is your vision for the impact and structure of SOA. The primary purpose of the vision is to educate IT and the business about SOA and to set the tone of your organization's thinking about SOA. Two main aspects of this are to ensure that your organization views SOA primarily as a business issue and to ensure an understanding that the move to SOA will broadly impact IT, requiring changes in IT's relationship with the business, IT's internal organization and processes, and IT's architectures for application and infrastructure design. The vision also makes it clear that moving to SO-IT is a multiyear evolution, not a sudden conversion. At a high level, your SOA vision should address: Business impact. In its big strategic impact, SOA is a catalyst for business transformation, enabling your business to thrive on change. With SOA, your enterprise applications, beyond simply supporting your business, are a technology-based embodiment of your business: a unified environment for designing business processes, measuring business operations, and continuously and incrementally optimizing the business. SOA's reuse and reduced cost of integration are important business benefits, but in the long term they are secondary to SOA's business transformation value. IT impact. To deliver on the big strategic impact of SOA, IT must change its primary operating mode from simply delivering applications as requested by the business to a mode of delivering strategic business flexibility via collaborative process design with the business. Tactical delivery of high-priority applications is still important, but IT's central focus must be on end-to-end business processes, starting with your customers' customers and continuing through to your suppliers' suppliers. In this world, IT's core deliverables are in two categories: business services — the digital embodiment of your business rules and processes — and interaction channels — the user interfaces and sensors that connect your digital business to the physical world. All of IT must realign around these two core deliverables, requiring changes in IT processes, roles, architecture, tools, and organization. Breadth and depth of impact on IT architecture. A tactical approach can be successful in viewing SOA as a Web services-based integration layer on top of existing IT architectures. Strategic adoption of SOA requires a deeper architectural transformation that is much bigger than Web services. To begin with, strategic SOA recognizes that you will need other application-to-application protocols besides Web services — as Sabre Holdings, Standard Life, Verizon, Allstate Insurance, and others have found.( see endnote 2 ) But beyond this, it requires that SOA capabilities be unified with and integrated into your application platform, management platform, security platform, and application tools. SOA is a transformation of your IT infrastructure, not an additional layer on top of it.
  • n a simple graphic illustration, SOA's two major layers may look highly reminiscent of diagrams from a component-based design (CBD) book. They should. The core concepts of modular software design principles have not changed since structured design was introduced in the 1970s. But with SOA, four things are different in how these principles are applied: SOA recognizes business processes as a critical design domain. In the CBD era, development started after business processes were defined, and business processes became embedded in the application implementation. With SOA, business process design is an integral part of the development, and business process definitions can drive the operation of the interaction layer (with human-centric workflow, etc.) and the business services layer (with WS-BPEL orchestrations, etc.).( see endnote 2 ) SOA has a stronger layering. The line between the interaction layer and the business services layer is more sharp and clear with SOA. A business service must take 100% responsibility for ensuring the valid processing of every service request — it cannot rely on the interaction layer to do validation, because there may be multiple interaction layer implementations accessing the same service.( see endnote 3 ) With a strong business services layer, business rules are typically factored out of the interaction layer — this layer is free to focus entirely on presentation-level issues like gathering data for business tasks, calling business services to perform tasks, and displaying the results to the user.( see endnote 4 ) SOA designs services that are meaningful at a business level. Business services are designed to perform complete business units of work. As such, businesspeople can easily see them as useful and necessary for the business. As a lead architect at Standard Life puts it, "It's not a business service if the business doesn't understand it."( see endnote 5 ) SOA allows any type of service implementation. Whereas CBD prescribed certain types of software implementation — Component Object Model (COM), COM+, JavaBeans, Enterprise JavaBeans (EJB), and such — SOA is open to a broad range of implementation options, including CBD. This creates greater openness to evolutionary strategies that leverage the existing IT assets.
  • SOA CREATES MULTIPLE DEFINITIONS OF "APPLICATION" Although SOA blows apart the traditional notion of an application, it is too complex for IT to deal with an explosion of piece parts. IT needs some type of structure for planning, managing, and developing all of the SOA piece parts in a coherent fashion. Key questions that the new structure must address include: Which development and support teams are responsible for which SOA piece parts?( see endnote 6 ) Which SOA piece parts are funded by which budgets? When the user says, "The application is down!" which team do we call first? How many teams will have to work together to deliver a complete business solution? Analysis of these questions leads to logical groupings of related SOA piece parts, and these groupings become the basis for multiple definitions of "application" in the world of SOA. Budgeting, support, development, and other IT activities then center on these new applications as the major units of planning.
  • A Difficult Example: A Layered, Interdivisional Contact Center Solution A more complex and difficult example might be a new, division-level contact center solution that requires information from the enterprise-level order management and billing applications. Both the division and the enterprise have strategic SOA initiatives, and both are creating a body of services for use across their respective domains. Beyond orders and billing, the enterprise SOA strategy provides utility services, such as credit card authorization, that the new solution will use. To deliver competitive customer service within its market space, the division has specialized requirements that require business services that build on the functionality provided by the enterprise order and billing applications. The result is a collection of four SOA-based applications. From the user's perspective, the result is one unified application. By layering and grouping the piece parts into clearly defined layers, each of the four teams can focus on its specific scope of application delivery and support. For some firms, the business service layers may be further divided into and managed as separate applications (for example, one SOA application for billing services and another for order services).
  • The conversation between business and IT then shifts to a clear flow from business strategy to business processes to critical success factors and process metrics to service-enablement of business processes. IT and business both come to understand services as the key unit of IT delivery and as the key unit of enablement and optimization for business processes. Looking “upward” from services, there is clear alignment with business metrics. Looking “downward” from services, there is a clear way to align IT metrics with business metrics by tying IT metrics to services. Application delivery metrics focus on cost of delivering new services. Application maintenance metrics focus on costs of keeping services running (both individual services and aggregate average costs). IT operations costs can be tied back to the resources needed to deliver particular services. In general, IT costs can be planned incrementally and in alignment with drivers of business value and cost.
  • Join Gene Leganza, VP of Government Research, Forrester, as he discuses how federal civilian, state and local agencies are deploying SOA to change the way services are delivered. During this session, Leganza will outline methods for breaking down silos, lowering costs and defining how you can use these efforts to see measurable ROI in the future. For the most updated Speaker and Agenda information, visit www.soaexecutiveforum.com/gov . Mr. Leganza and other guest speakers at the SOA for Government Executive Forum will be attending the executive luncheon, open to all attendees.
  • With service oriented business architecture enabled by SOA technology solutions, applicants can use a variety of channels to enter information into a central system, reducing the burden on the applicant to visit multiple government offices to apply for benefits, and reducing the cost of government agencies’ intake processing. Then a central engine can analyze the applicant’s eligibility for any and all programs and a case manager can arrange for and coordinate services across various units within the same agency, across agencies and between levels of government. The use of industry standards in the underlying technology enables the coordination of services to external service providers as well, whether they are non-profit community organizations or for-profit providers such as doctors and psychologists. Without altering the services provided in each service stovepipe, the SOA architecture enables the design and coordination of services to fit the applicants’ specific needs, significantly increasing the likelihood that the applicant’s objective will be achieved. Government agencies’ costs are reduced by applicant self-service and through the use of shared eligibility processing for multiple services, the possibility of fraud is reduced through the integration of systems, the need for case workers to understand complex eligibility requirements across disparate programs is eliminated, and, ultimately, the applicant becomes self-sufficient and no longer a tax burden. In Jane’s case, only one visit to the welfare office was needed, augmented by self-service access to her case information from her home phone, to provide a case worker with the complete information needed to plan the various services necessary to get her back to work. She began receiving temporary financial assistance and food stamps, and she obtained child care to enable her to go on job interviews. When, after several unsuccessful interviews it became clear to her case worker that she needed training to develop marketable skills, she was electronically enrolled in a course given by a training organization contracted by the state Labor Department and her certification was recorded in her case file. Certification triggered a change in her job search and she obtained a job with her new skills. Her financial assistance was reduced and, eventually, terminated. Without the coordination and integration of services across stovepipes provided by the service-oriented business architecture, Jane would have needed to learn about a wide variety of services from different providers, apply for eligibility multiple times, and adapt her efforts with new services as she encountered obstacles. With stovepiped services and systems, no case worker in any government office could have guided her through the variety of services that she needed to get off the welfare rolls and become gainfully employed.
  • With service oriented business architecture enabled by SOA technology solutions, applicants can use a variety of channels to enter information into a central system, reducing the burden on the applicant to visit multiple government offices to apply for benefits, and reducing the cost of government agencies’ intake processing. Then a central engine can analyze the applicant’s eligibility for any and all programs and a case manager can arrange for and coordinate services across various units within the same agency, across agencies and between levels of government. The use of industry standards in the underlying technology enables the coordination of services to external service providers as well, whether they are non-profit community organizations or for-profit providers such as doctors and psychologists. Without altering the services provided in each service stovepipe, the SOA architecture enables the design and coordination of services to fit the applicants’ specific needs, significantly increasing the likelihood that the applicant’s objective will be achieved. Government agencies’ costs are reduced by applicant self-service and through the use of shared eligibility processing for multiple services, the possibility of fraud is reduced through the integration of systems, the need for case workers to understand complex eligibility requirements across disparate programs is eliminated, and, ultimately, the applicant becomes self-sufficient and no longer a tax burden. In Jane’s case, only one visit to the welfare office was needed, augmented by self-service access to her case information from her home phone, to provide a case worker with the complete information needed to plan the various services necessary to get her back to work. She began receiving temporary financial assistance and food stamps, and she obtained child care to enable her to go on job interviews. When, after several unsuccessful interviews it became clear to her case worker that she needed training to develop marketable skills, she was electronically enrolled in a course given by a training organization contracted by the state Labor Department and her certification was recorded in her case file. Certification triggered a change in her job search and she obtained a job with her new skills. Her financial assistance was reduced and, eventually, terminated. Without the coordination and integration of services across stovepipes provided by the service-oriented business architecture, Jane would have needed to learn about a wide variety of services from different providers, apply for eligibility multiple times, and adapt her efforts with new services as she encountered obstacles. With stovepiped services and systems, no case worker in any government office could have guided her through the variety of services that she needed to get off the welfare rolls and become gainfully employed.
  • Join Gene Leganza, VP of Government Research, Forrester, as he discuses how federal civilian, state and local agencies are deploying SOA to change the way services are delivered. During this session, Leganza will outline methods for breaking down silos, lowering costs and defining how you can use these efforts to see measurable ROI in the future. For the most updated Speaker and Agenda information, visit www.soaexecutiveforum.com/gov . Mr. Leganza and other guest speakers at the SOA for Government Executive Forum will be attending the executive luncheon, open to all attendees.
  • “ Every state’s Medicaid Management Information System (MMIS) has, as its core, automation for processing claims and other business functions. This core functionality includes handling baseline recipient, provider, reference, and sometimes, other data. Addtional systems might reside in the environment, including Decsion Support Systems (DSSs), financial systems, Third-Party Recovery (TPR), and other applications. Their interfaces are what we call tightly coupled — each program, database, subsystem is highly dependent on another, and all are generally interconnected through individual, point-to-point interfaces. “ When business rules, policies, or legislation change, any and all parts of the system may be impacted, including applcations, databases, and interfaces. Thus, it becomes increasingly difficult to manage this complex environment. It is also becoming exceedingy costly to maintain these systems, both from a fperspective (state and federal), as we as from an intellectual property perspective. As systems grow older, fewer resources are available that are both familiar with those systems and know best how to maintain or update them.” – MITA documentation
  • The Medicaid Information Technology Architecture (MITA) is an initiative of the Center for Medicaid & State Operations (CMSO), and it is aligned with the National Health Infrastructure Initiative (NHII) (http://aspe.hhs.gov/sp/nhii/).NHII is a voluntary network comprising clinical, public health and personal health knowledge-based information systems that make health information available as needed to improve decision-making. MITA is intended to foster integrated business and IT transformation across the Medicaid enterprise to improve the administration of the Medicaid program. The Figure above shows a simplified view of a SOA with exampes of Medicaid Information Technology Architecture (MITA) services. These services can perform either business or techncal functions. Services such as m, Enroll Provider, and Verify Provider Credentials, perform . Services such as Portal Service, Forms Management, External Data Interchange Hub Services, or EDI Gateway, perform high-level services that are shared by many business services. Services can be simple or complex sets of services that are interconnected by the Enterprise Service Bus (ESB). The ESB is a service layer that provides the capabilty for services to interoperate and to be invoked as a chain of simple services that perform a more complex end-to-end process. The service layer is designed to handle both normal conditions and respond to failures and adapt to changes. The ESB provides the following functions: Message management is the reliable delivery of messages between services and built-in recovery. Data Management converts all messages between services to a common format, and in turn, converts messages from the common format to the application-specific format within a service. The MITA message format for interoperabilty is based on XML standards. Information sharing and event-notification standards are also defined for allowing information to be aggregated and integrated. Service Coordination orchestrates the execution of an end-to-end business process through all needed services on the ESB. Services can adapt to changes in environments and are supported by a standards-based set of service-management capabilities. Many vendor implementations of an ESB exist, and the functions included in an ESB vary from one vendor to another. The list of functions mentioned previously are key functions needed for realizing an SOA, and for the purpose of simplification in this paper, we are including these functions in our definition of an ESB. Source: http://www.cms.hhs.gov/medicaid/mmis/mita_soa.pdf
  • Join Gene Leganza, VP of Government Research, Forrester, as he discuses how federal civilian, state and local agencies are deploying SOA to change the way services are delivered. During this session, Leganza will outline methods for breaking down silos, lowering costs and defining how you can use these efforts to see measurable ROI in the future. For the most updated Speaker and Agenda information, visit www.soaexecutiveforum.com/gov . Mr. Leganza and other guest speakers at the SOA for Government Executive Forum will be attending the executive luncheon, open to all attendees.
  • As a regional government agency in Australia, Queensland Transport oversees many kinds of transport including motor vehicles. It first outlined an SOA strategy in 1997, viewing SOA as an opportunity for strategic government transformation. Queensland Transport funds SOA evolution at a project level, but the projects are tied together with an overall plan for evolving the SOA. Seeking to improve the efficiency of vehicle registrations, it implemented an XML-based external integration solution (around the year 2000). The integration enables automated processing across enterprise boundaries, including vehicle dealerships. The original system worked quite well, but the more interesting part of the story is in the unanticipated government transformations that the system spawned. First, because the service interfaces were designed according to the business processes involved, Queensland Transport realized it would be easy to plug independent vehicle inspectors into the process. So, rather than the old way of requiring all vehicle inspectors to be government employees, Queensland Transport uses a new, more flexible “staffing” model. Second, Queensland Transport made certain public data available for free through its service interfaces. Some third parties were combining government data with other data and selling the result. Queensland asked why it should not have a cut of such revenue streams and, in some cases, it now does get a cut — a new stream of revenue for the government. Third, following the same process-focused service design method, Queensland Transport built a customer service appointment system (for example, scheduling a driver’s test). One of the historical problems with such appointments is that citizens would make an appointment and not keep it — they only paid for a driver’s test when they took it. In designing the process and services for the new system, Queensland Transport switched the model to one where citizens pay to make an appointment — so now they show up for their tests. Fourth, other government agencies realized that Queensland Transport’s appointment system was flexible enough to fit into their own processes, so they started reusing Queensland Transport’s system. This accomplished from the bottom up the shared service model that governments around the world are failing at doing from the top down.
  • First and foremost, Queensland Transport saw SOA as a design model for its core applications. Starting so early with its first SOA-based system in 2000, it had very little support from vendors and products. XML was simply an easy way to integrate outside with external parties — a layer on top of its core SOA. Business services are modeled in CA’s AllFusion Gen product, generated, and deployed to either J2EE or CICS. Queensland Transport’s applications and web sites access these services using native protocols. A small number of external partners make services available externally. External communication is via XML-RPC (a predecessor to SOAP), which is handled internally by a custom-built XML server. Authentication and authorization for external services is via SSL authentication and is managed by the agency’s web server. In lieu of a repository or UDDI registry, the agency simply provides its external partners with XML Schemas to its partners. For managing the elements of its core service environment, Queensland Transport uses HP OpenView. To gain better control of its XML-based interfaces, it will soon deploy CA’s WSDM product, which will be integrated with and pass management data to OpenView. Since Queensland Transport’s SOA was established when the market was very immature, it will be looking in the future for an opportunity to update the platform. When it does, it anticipates that it will migrate to standard SOAP-based infrastructure and use the opportunity to exchange various elements of its SOA platform.
  • Additional lessons from Queensland Transport: Major vendors make the best cornerstones for an SOA platform
  • Unique (pronounced YOU-nick) is the firm that operates Zurich airport. It sought a solution to improve its depth of insight into and ability to manage airport operations. The solution was to create an airport operations portal that combined key data from various operational applications, but the challenge was that applications such as baggage, ground radar, and airport operations were outsourced to various providers and running on a variety of underlying platforms and operating systems. With the new system, called ZEUS, each external provider was required to implement a SOAP interface. The SOAP interfaces are accessed over a private network, so no further security is used for the connection. On Unique’s side, an EAI product is used to control message flow to and from the source applications. The greatest volume of traffic comes from the radar system, which has small, 120 byte messages, and performance is good (20 ms to 500 ms). ZEUS’s funding was funding was 25% project level, 75% enterprise level. Once the ZEUS system was up and running with its SOA platform, other Zurich airport applications started using the platform. For example, an application to provide SMS notifications for flight delays used existing services in ZEUS.
  • Unique’s airport management portal system, called ZEUS, uses a combination of webMethods and .NET as the core of its SOA platform. Underlying systems (airport operations, radar, baggage, etc.) were enhanced with SOAP interfaces, which originate from the native platform (Unix, mainframe, and even a PC with a modem). Access to the underlying systems is controlled and managed by webMethods, while the core business logic for the portal is written in .NET. Visual Studio .NET and webMethods tools are the primary development tools. For now, Unique’s SOA platform is where it needs to be, with no major priorities for future enhancement.
  • ZEUS is a good example of an SOA that uses SOAP for external connections, although Unique’s environment is simplified by the pre-existence of a private network environment between Unique and its outsourced providers.
  • Standardize for core applications, simplify for broad integration scenarios. When no single application platform dominates everywhere, it can be a challenge to designate one of these platforms as the strategic platform that will provide the integration backplane for everyone. State governments often find that there is no comprehensive platform that can be dominant for such integration, so they need an agnostic choice that will plug in everywhere. The State of Wisconsin recently picked Cape Clear Software’s ESB for just such a situation, as a peacemaker that can connect to the platforms used by all the departments. And because the requirements for interdepartmental integration were naturally constrained, a basic, off-the-shelf ESB was able to provide a good, simple solution at a reasonable price.
  • As a backdrop to the SOA case studies, there are major scenarios that heavily influence the evolutionary paths that enterprises are taking toward SOA. Based on Forrester’s conversations with clients, we’ve constructed six stylized paths to SOA. Some enterprises may follow one of these paths directly, but most shops will have a combination of them. Each path has a particular set of characteristics that result in a typical pattern of SOA investments. Also each path has typical elements of SOA business justification. As you craft your path to SOA, you will most likely mix and match investments across paths based on your own local requirements and priorities — as have each of the firms in the case studies to follow. Forrester’s paths to SOA are explored further in the December 7, 2004, Trends “Your Paths To Service-Oriented Architecture.”
  • Click here to download Gene Leganza's Presentation

    1. 1. SOA - The Key to Transforming Government Services Gene Leganza Vice President, Government Research Forrester Research
    2. 2. Agenda <ul><li>Benefits of SOA for government </li></ul><ul><li>Walkthrough of a social services example </li></ul><ul><li>Example of a federal framework for SOA </li></ul><ul><li>Government examples of SOA implementations </li></ul>
    3. 3. Forrester’s definition: SOA <ul><ul><li>Applications are organized into business services that are (typically) network accessible </li></ul></ul><ul><ul><li>Service interface definitions are first-class development artifacts </li></ul></ul><ul><ul><li>Quality of service characteristics are explicitly specified in the design </li></ul></ul><ul><ul><li>Services are cataloged and discoverable by development tools and management tools </li></ul></ul><ul><ul><li>Protocols are predominantly, but not exclusively, based on Web services </li></ul></ul>A style of design, deployment, and management of applications and software infrastructure in which:
    4. 4. Large firms lead SOA adoption
    5. 5. Large firms make broad use of SOA
    6. 6. SOA platform vision — three core value propositions Service lifecycle environment Core application platforms … Service delivery network Service command platform Service clients Service interfaces Control Change Connection
    7. 7. The elements of SOA maturity <ul><li>SOA vision </li></ul><ul><li>Business-IT collaboration </li></ul><ul><li>Governance -- service interfaces, architecture </li></ul><ul><li>Infrastructure and tooling evolution </li></ul><ul><li>Funding </li></ul><ul><li>Service delivery lifecycle and roles </li></ul><ul><li>Patterns for service design and implementation </li></ul><ul><li>Service value measurement </li></ul>
    8. 8. SOA Restructures Enterprise Applications
    9. 9. SOA Restructures Enterprise Applications
    10. 10. “ Application” definitions: Sample contact center
    11. 11. SOA enables continuous business optimization Citizens Partners Suppliers Your agency YOU Continuous innovation in processes, connections, data, and relationships Other government agencies Private sector
    12. 12. IT steps up to collaborative business design Business and IT Program measurement IT measurement Services Processes Metrics Delivered solution
    13. 13. Services become the center of IT architecture Multichannel interaction Connecting to your digital business SOA Platform Running your digital business Services Your digital government Web Mobile G2X RFID IVR Desktop
    14. 14. Major categories of SOA value Higher process value — internal and external Better constituent service Faster process change Reduced cost of change Even faster process change over time Reduced biz-IT communication cost Deeper business integration — and flexible outsourcing Wider circles of business integration Version 1 Version 2 Step 1 Step 2 Step 3 Step 4 Step 5 Step 6
    15. 15. Agenda <ul><li>Benefits of SOA for government </li></ul><ul><li>Walkthrough of a social services example </li></ul><ul><li>A federal framework for SOA </li></ul><ul><li>Government examples of SOA implementations </li></ul>
    16. 16. Social Services Example: Current Stove Piped Processes Multiple providers, redundant eligibility processing, non-integrated care: Outcome of returning to work at risk Applicant fails to get job after several interviews, stops trying. Applicant stays on benefits till they expire Human Services Agency - TANF Human Services Agency – Child Care Labor Dept - Job Information External Provider - Training
    17. 17. Integrated Service Delivery Multiple Providers, Separate Services, Integrated Care: Outcome of Returning to Work Achieved Applicant fails to get job after several interviews, case worker sets up training, certification yields changed job search and success. Applicant becomes self-sufficient and terminates benefits. Human Services Agency - TANF Human Services Agency – Child Care Labor Dept - Job Information External Provider - Training
    18. 18. <ul><li>Benefits of SOA for government </li></ul><ul><li>Walkthrough of a social services example </li></ul><ul><li>Example of a federal framework for SOA </li></ul><ul><li>Government examples of SOA implementations </li></ul>Agenda
    19. 19. Medicaid Management Information System <ul><li>A patient-centric view not constrained by organizational barriers </li></ul><ul><li>Common standards with, but not limited to, Medicare </li></ul><ul><li>Interoperability between state Medicaid organizations within and across states, as well as with other agencies involved in healthcare </li></ul><ul><li>Web-based access and </li></ul><ul><li>Integration </li></ul><ul><li>Software reusability </li></ul><ul><li>Use of commercial off-the-shelf software (COTS) </li></ul><ul><li>Integration of public health data </li></ul>The Medicaid Information Technology Architecture (MITA)’s common business and technology vision for state Medicaid organizations will emphasize:
    20. 20. Medicaid Management Information System
    21. 21. MITA Business Services
    22. 22. MITA and Platform Independence
    23. 23. Structure of MITA Business Services
    24. 24. <ul><li>Benefits of SOA for government </li></ul><ul><li>Walkthrough of a social services example </li></ul><ul><li>A federal framework for SOA </li></ul><ul><li>Government examples of SOA implementations </li></ul>Agenda
    25. 25. Queensland Transport — Early SOA (1997) <ul><li>Regional government agency in Australia </li></ul><ul><li>Applications </li></ul><ul><ul><li>Vehicle titles and registration, customer service appointments, distribution of public information </li></ul></ul><ul><ul><li>SLAs: 2 sec response for 90% of txns (XML-RPC) </li></ul></ul><ul><li>Key choices </li></ul><ul><ul><li>Implement services using native J2EE and CICS servers </li></ul></ul><ul><ul><li>XML only for external interfaces </li></ul></ul><ul><ul><li>Simple solutions for security and interface definition </li></ul></ul><ul><li>Paths to SOA </li></ul><ul><ul><li>Integration (simple internal, external), infrastructure services, multichannel applications </li></ul></ul>
    26. 26. Pattern: Non-SOAP, basic SOA J2EE (Borland) Business services Oracle Custom XML server CICS Business services DB2 AllFusion Gen tools Web server Web applications CA WSDM (future) XML Schemas XML-RPC External partners Public access PKI Web server CA AllFusion Gen CA AllFusion Gen Internal External Custom web framework monitoring management HP OpenView J2EE calls CICS services XMLSpy Two-way SSL
    27. 27. Queensland Transport — Lessons <ul><li>SO is a business model, not a technical solution </li></ul><ul><li>It’s about business transformation </li></ul><ul><ul><li>Think through the full value chain, not just internal processes </li></ul></ul><ul><li>Use business process analysis to find services of value </li></ul><ul><li>Be prepared for service support issues </li></ul><ul><ul><li>End users will come to you when they have issues, not to an intermediate provider </li></ul></ul>
    28. 28. Unique (Zurich Airport) — SOA-based portal <ul><li>Manages the operations of Zurich airport </li></ul><ul><li>Applications </li></ul><ul><ul><li>Airport management portal — integrates data and transactions from multiple outsourced systems </li></ul></ul><ul><ul><li>Up to 50 msgs/sec @ 20 ms to 500 ms latency (most messages are very small) </li></ul></ul><ul><li>Key choices </li></ul><ul><ul><li>Require each externally hosted application to expose SOAP </li></ul></ul><ul><ul><li>Single access channel to integrate applications </li></ul></ul><ul><li>Paths to SOA </li></ul><ul><ul><li>Rich internal integration, quasi-external integration </li></ul></ul>
    29. 29. Pattern: Layered SOAP, reliable delivery SOA SourceSafe SOAP .NET / Windows 2003 Server Business services webMethods webMethods tools Airport management portal SOAP SOAP SOAP Airport operations Radar data Baggage Other SOAP Local data cache User interaction Other (flight status) Private network connections to externally hosted applications reliable delivery events monitoring policy XMLSpy VS.NET
    30. 30. Unique (Zurich Airport) — Lessons <ul><li>Separate service specification and implementation </li></ul><ul><ul><li>First, define the service interface </li></ul></ul><ul><ul><li>Design interfaces based on process requirements </li></ul></ul><ul><ul><li>Then, design how to fulfill the service </li></ul></ul><ul><li>Do not put business logic in the delivery network </li></ul><ul><li>Get an early handle on governance of data semantics </li></ul>
    31. 31. Govt. of BC, Ministry of Attorney General <ul><li>Justice information system -- court services online </li></ul><ul><ul><li>Anonymous information access from courthouse kiosks </li></ul></ul><ul><ul><li>Planned extensions to law offices </li></ul></ul><ul><ul><li>Future ability to submit new legal cases and documents </li></ul></ul><ul><li>Key components </li></ul><ul><ul><li>Workstations in court houses </li></ul></ul><ul><ul><li>Web services connections </li></ul></ul><ul><ul><li>XML security gateway </li></ul></ul><ul><ul><li>Stored procedures in a back end database </li></ul></ul><ul><ul><li>Legal society issued digital certificates </li></ul></ul>
    32. 32. State of Wisconsin integration strategy: SOA <ul><li>Scope of SOA investment </li></ul><ul><ul><li>General integration platform for G2G, G2B, G2C </li></ul></ul><ul><li>Stated benefits </li></ul><ul><ul><li>Enables the delivery of state-wide services and data sharing </li></ul></ul><ul><ul><li>Leverages existing IT infrastructure and applications </li></ul></ul><ul><ul><li>Low implementation, deployment, and management costs </li></ul></ul><ul><li>Potential applications </li></ul><ul><ul><li>Procurement, Licensing, E-Receipts, Tax Calculation, Criminal Background Checks </li></ul></ul><ul><ul><li>Integration across government and public sector boundaries </li></ul></ul>
    33. 33. State of Wisconsin pilot solution
    34. 34. State of Wisconsin pilot solution IDMS VSAM Complex SQL Access Agency Applications Agency ClientSoft Web Service CICS Linked Programs Direct call Client Soft Port Cross Platform and Remote Applications VB and Java Applications ClientSoft Generated Interface Mainframe Applications CICS and IMS Screen scrapes Via ESB (optional)
    35. 35. Tulsa County: Environment <ul><li>Tech platform </li></ul><ul><ul><li>Mainframe – IBM7060-H30 (Multiprise 3000 model H30) </li></ul></ul><ul><ul><ul><ul><ul><li>Cobol, Assembler, and Natural </li></ul></ul></ul></ul></ul><ul><ul><ul><ul><ul><li>Currently average 180,000 transactions daily </li></ul></ul></ul></ul></ul><ul><li>Business problems </li></ul><ul><ul><li>Increasing accessibility and availability of systems </li></ul></ul><ul><ul><li>Combine multiple platforms into more usable consolidated format </li></ul></ul><ul><ul><li>Reduce overall development and maintenance costs </li></ul></ul><ul><li>Vendors </li></ul><ul><ul><li>Software AG </li></ul></ul><ul><ul><li>Flexibility of Development and Rollout, NET, Java, Cobol </li></ul></ul><ul><ul><li>Able to support all standard security methods </li></ul></ul><ul><ul><li>Mainframe-based </li></ul></ul><ul><ul><li>Intuitive interface for rapid deployment </li></ul></ul>
    36. 36. Tulsa - Results <ul><li>406 users currently accessing first Mainframe Web Service on a daily basis (and growing) </li></ul><ul><li>Consistent with goal of increasing accessibility and usability of government services to the public </li></ul><ul><li>Served as Proof of Concept that enhancements to existing systems are beneficial and well-received (very strong feedback from users) </li></ul><ul><li>Provided affordable solution to add value to applications and remain good stewards of tax-payer dollars </li></ul><ul><li>Developing centralized approach for citizens to access common information and services through our website </li></ul><ul><li>Increased availability and convenience - 24/7 </li></ul><ul><li>New intuitive interface combined old menu options with new mouse driven capabilities </li></ul><ul><li>Empowers us to maintain a ‘best fit’ approach to each specific project and application need </li></ul>
    37. 37. Overall themes and recommendations <ul><li>Business drives architecture </li></ul><ul><ul><li>You need a vision to guide SOA evolution </li></ul></ul><ul><ul><li>SOA creates opportunities for “pluggable business” </li></ul></ul><ul><li>As a strategy for business design, SOA applies to many scenarios </li></ul><ul><ul><li>Services must be designed in a process-centric way </li></ul></ul><ul><li>Learn from emerging patterns in the real world </li></ul><ul><ul><li>Orchestration is a good first step into greater levels of SOA flexibility </li></ul></ul>
    38. 38. Appendix Backup Slides
    39. 39. <ul><li>Your path to SOA will borrow and combine elements from six generic paths to SOA: </li></ul><ul><ul><li>Simple internal integration </li></ul></ul><ul><ul><li>Infrastructure services </li></ul></ul><ul><ul><li>Rich internal integration </li></ul></ul><ul><ul><li>Multichannel applications </li></ul></ul><ul><ul><li>External partner integration </li></ul></ul><ul><ul><li>Core business flexibility </li></ul></ul>Six stylized paths to SOA
    40. 40. MITA Home Page http://www.cms.hhs.gov/medicaid/mmis/mita.asp
    41. 41. Thank You! Gene Leganza +1 203/761-8848 [email_address] www.forrester.com

    ×