Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

slide deck for this session here


Published on

  • Be the first to comment

  • Be the first to like this

slide deck for this session here

  1. 1. SOA Success: Aligning Your Development Organization Chuck Allen, HR-XML Consortium, Inc. Andrew Cunsolo, Talent Technology Corp. Jonathan Mack, Guardian Life
  2. 2. What is SOA? <ul><li>A departure from packaged, monolithic applications. </li></ul><ul><li>Breaks applications into service provider and service consumer roles. </li></ul><ul><li>Requires analysis to identify and break down business processes, sub-processes, activities, tasks, and data into reusable component services. </li></ul><ul><li>Service providers and consumers can connect within the same enterprise or across the Internet. </li></ul><ul><li>Grand vision is for SOAs everywhere – within enterprises, vendor solutions, “ecosphere” partners. </li></ul><ul><li>SOAs are made possible by well-supported interface standards – especially Web services standards. </li></ul>
  3. 3. Why SOA? <ul><li>SOA often is justified on cost savings, but its lasting value is in increased business agility: </li></ul><ul><ul><li>SOA’s goal is to make business agility intrinsic to the systems architecture. </li></ul></ul><ul><ul><li>Promises enterprises the ability to “snap together” components in response to business change. </li></ul></ul><ul><li>SOA also is a response to today’s highly distributed business environment: </li></ul><ul><ul><li>The concept of an &quot;application&quot; now extends beyond an enterprise and beyond the scope of single provider. </li></ul></ul><ul><ul><li>Demand for services anytime, anywhere, through any device creates need for flexible, reusable services. </li></ul></ul>
  4. 4. Business, Technology Model for SOA Potential Reuse Business Capabilities Disassemble into Processes, Activities, and Tasks WS Operations, Services, Processes Rollup Into SOA implementation
  5. 5. Recent Research <ul><li>Survey commissioned by BEA Systems found: </li></ul><ul><ul><li>A majority of the largest global organizations (61%) expect no more than 30 percent of their SOA services to be eventually reused or shared across business units. </li></ul></ul><ul><ul><li>An 84% majority, these same respondents consider service reuse is one of their most critical metrics for SOA success. </li></ul></ul><ul><ul><li>50% say they already have an incentive program to encourage reuse. What wasn’t clear was if these incentives were carrots or sticks. </li></ul></ul><ul><ul><li>59% of the money for SOA projects is coming from business solutions budgets attributed to existing projects. Only 19% cannibalized other IT projects. Even more interesting is the fact that 22% reported they have a specific budget with funds earmarked for SOA projects. </li></ul></ul>
  6. 6. <ul><li>“ Blurry lines” and overlap among these broad SOA patterns: </li></ul><ul><ul><li>“ JBOWS.” A tongue-in-cheek acronym for “Just a bunch of Web services”. No unifying “blueprint,” but called a SOA. </li></ul></ul><ul><ul><li>“ Rent-a-SOA” / “SOA in a box.” Want to buy a SOA? </li></ul></ul><ul><ul><li>“ Outside-In SOA.” SOAs focused on consuming, orchestrating, and managing services from outside. </li></ul></ul><ul><ul><li>“ Enterprise SOA.” Internally developed services for consumption and reuse across and outside the enterprise. </li></ul></ul><ul><ul><li>“ Ecosphere” players. New SOA platforms (even marketplaces) to sell, distribute, and manage components. </li></ul></ul><ul><ul><li>Solution providers. Solution providers use SOA to make suites of functionality consumable as service components. </li></ul></ul>SOA Implementation Patterns
  7. 7. <ul><li>Not right for everyone, but likely a good approach for HRIT: </li></ul><ul><li>Establish a foundation. Do you have the talent? Do you have the technology? Do your solution providers have the foundation? </li></ul><ul><li>Start small. Don’t “boil the ocean,” but have some vision for how SOA efforts will scale. </li></ul><ul><li>Pick a discrete project that has financial justification on its own whether or not you use SOA. </li></ul><ul><li>Focus on a relatively simple process (perhaps two or three services). </li></ul><ul><li>Look out for a second project that reuses one or two of the services from the first project. </li></ul><ul><li>Establish “governance” approaches and service registries early in project to ensure consistency and reuse across the enterprise. </li></ul><ul><li>Continue in a similar fashion to build your portfolio of services. </li></ul>An “Accumulative” Approach to SOA
  8. 8. <ul><li>Gulf of knowledge and effective communication among process owners (HR, for example), corporate IT, and vendors. </li></ul><ul><li>HR decision makers lack the knowledge/background to evaluate the SOA/Web Services claims of their vendors. Also, SOA/WS knowledge isn’t widespread among vendor representatives. </li></ul><ul><li>Great differences in approaches to modeling processes. How do processes and services breakdown? </li></ul><ul><li>Not always sufficient thought about, communication of, web services governance at the enterprise level. </li></ul><ul><li>Related practices and standards for working in highly distributed environments (e.g., federated identity management) exist, but are still maturing. </li></ul><ul><li>First generation WS standards (SOAP, WSDL, UDDI) are well established, 2 nd generation WS standards (WS-Policy; WS-Reliable Messaging; WS-Addressing) are still maturing. </li></ul>SOA/WS Adoption Obstacles