Aligning Your Development Organization


Published on

Published in: Technology, Business
  • Be the first to comment

  • Be the first to like this

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Aligning Your Development Organization

    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
    1. A particular slide catching your eye?

      Clipping is a handy way to collect important slides you want to go back to later.