slide deck for this session here

  • 3,344 views
Uploaded on

 

  • 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
3,344
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
1
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
  • A departure from packaged, monolithic applications or even traditional ASP or hosted applications. An approach for organizing and leveraging distributed capabilities or services. SOAs divide an application into two parts: service provider and service consumer. Providers and consumers may be within the same enterprise or connected across the Internet. Why hasn’t this been done before? This would seem to be the natural way to think about network delivered applications. Long over due step – to network delivered applications. Application heritage – trace back to where HR systems were things that existed within the 4 walls of a computer room. Where do SOAs exist? A grand vision is for SOAs everywhere – enterprises, vendor solutions, “ecosphere” partners. Achieving service orientation involves breaking down business processes into component services – but hopefully in more agile, collaborative, and opportunistic way than traditional business process re-engineering (BPR). Defining services indepedent of the way they will appear or present themselves to a user and independent of technology. Enabled by “loose coupling” via widely adopted Web services standards to offer and use distributed services. Where do SOAs exist? A grand vision is for SOAs everywhere – enterprises, vendor solutions, “ecosphere” partners. SOA contemplates leveraging resources beyond the enterprise – so the enterprise’s SOA becomes more valuable, useful as vendors and partners similarly adopt service oriented ways of doing business.
  • SOA does not necessarily have to be like a business process re-engineering exercise of the early 1990s. Achieving service orientation can be accumulative, opportunistic, and more collaborative than those exercises typically were. Rather than doing all the heavy lifting, SOA implies you are going to leverage/reuse components – even architectures – provided from the outside in ways that were much more flexible than the BPR in the 1990s. On the other hand – it’s your business – you should hold/control at least the high-level blueprint! You might need to do some analysis! A SOA shouldn’t be something that just happens to you! SOA shouldn’t be a completely unmanaged JBOS! Your SOA may (even should!) leverage SOAs of vendors, solution providers, but can you can really buy your SOA? Where to start? SOA divides applications into service supplier and service consumer. Look at the activities involving interactions between service supplier and service consumer. What are the scope of business processes covered by the SOA? How do these processes break down into sub-processes, activities, and, in turn, tasks. Procedures usually describe how tasks are preformed. Is any of this explicit or documented at any level? If not, getting at least a high-level model together is a good thing. Where in the business process do the interactions between supplier and consumer take place? What is the data necessary to execute that interaction? What variations and options must be accommodated? What does the message exchange pattern look like? Which party initiates and how? What are variations? Can today’s process be optimized? What legacy processes can be eliminated? Focus on the business model – versus the technology model. On the technology side, be aware that Web services are applicable at every level you model on the business side. Web services technology performs multiple roles: A web service can represent a single piece of business logic. A web service can perform a “controller function” over other web services performing specific business functions. A single web service can coordinate the execution of business process activities that rely multiple web services. Web services can be “fine-grained” or “course-grained”. In other words, they can be narrowly scoped for a specific task or generalized.
  • SOA everywhere! There are blurry lines among these patterns and one entity can perform more than one role: “ Rent-a-SOA” / “SOA in a box.” HR organizations will look for benefits from the SOA embodied within vendor solutions. “ Inside-Out SOA.” Registries of internally developed services for consumption and reuse across and outside the enterprise. “ Outside-In SOA.” SOAs also will focus on consuming, orchestrating, and managing services from outside. Solution providers. Solution providers use SOA to make suites of functionality consumable as service components. In ASP or SAAS situations, you benefit by “renting” the provider’s SOA. “ Ecosphere” players. New SOA platforms (even marketplaces) to distribute and manage components (e.g., Salesforce.com AppXchange, Strikeiron). “ JBOS.” A tongue-in-cheek acronym for “Just a bunch of services”. No unifying “blueprint,” but called a SOA anyway. Can a JBOS evolve into a SOA? Yes, but not without a plan.
  • SOA is not a destination, but a journey! The “accumulative approach” is one way to begin the journey! May not be appropriate for everyone. Some enterprise architects argue that it is a myth that you can start small – but to the extent HR has any role in implementing SOAs, I realistically I don’t think there is much choice.
  • Gulf of knowledge and effective communication among process owners (HR, for example), corporate IT, and vendors. HR decision makers lack the knowledge/background to evaluate the SOA/Web Services claims of their vendors. Great differences in approaches to modeling processes data semantics. How do processes and services breakdown? Is there sufficient match between the semantics and granularity of your provider’s services and your requirements? Not always sufficient thought about web services governance at the enterprise level. What governance standards should be applied company-wide? How should they be enforced? Related practices/standards for working in highly distributed environments (e.g., federated identity management, WS Security) exist, but are still maturing. 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.

Transcript

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