• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
SOA and ERP
 

SOA and ERP

on

  • 3,063 views

 

Statistics

Views

Total Views
3,063
Views on SlideShare
3,062
Embed Views
1

Actions

Likes
1
Downloads
88
Comments
0

1 Embed 1

http://www.slideshare.net 1

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • We’re not making this up! Here are some comments from the Meta Group, indicating some of the problems associated with ERPs as they have evolved to this point. So where is the industry heading to address these challenges? The industry is adopting a new paradigm – the Service Oriented Architecture. The emergence of standards is driving this paradigm shift because a standards-based architecture can truly be infrastructure, and application independent. The old joke used to be “Standards are great – there are so many to choose from!”. And there’s many a true work spoken in jest! But these days, especially since the emergence of XML and SOAP, there has been a recognition that if applications can expose their functionality as a series of well-defined standards-based services defined solely in terms of their inputs and outputs, and communicating using standard communication protocols, customers can define the steps in a business process without having to etc. etc.
  • Most people have heard the term ‘Web Service’ as well as possibly all these other technical jargon term like ‘XML’, ‘SOA’, and ‘BPEL’. But what does it all mean Let me try to explain it using a real life example …
  • Let’s pretend you want to build a house from scratch. First thing you do – hire a general contractor (GC). GC locates a Concrete Company, picks up the phone and calls to ask for an estimate and when can they come out to pour the foundation. Next, he’ll call and coordinate when the lumber is delivered and the framers can come out and put up the frame. Then the same thing for the roofer. While the frame is being put up, he might call and get a couple different estimates from electricians and choose which one has, not only the best rates, but which one can meet the schedule. Same for the plumber. Finally, the painter comes out and puts the finishing touches on your brand new house. This is a good example of a Service Oriented Architecture (SOA). Now, let’s put this in an IT perspective – and in particular, Oracle integration. The General Contractor is a BPEL Process – who’s primary purpose is to orchestrate all these heterogeneous activities from disparate systems – in this case companies – to achieve a common goal – build a house Each of the contractors are, in Oracle Integration terms, Web Services. Let’s look at one of these transactions in more detail He communicated with the concrete company ( Web Service) over the telephone with the voice going back and forth ( XML) How did the GC find what he wanted? He looked in the Yellow Pages (UDDI) and found the listing (WSDL). He quickly and easily obtained the information he needed (price quote and availability) without having to know anything about the Concrete business. Any other contractor can call this same Concrete business and get the exact same information. And finally, the voice communication was delivered over a standard protocol, or medium – in this case, the phone lines. With web services, this standard protocol is SOAP Hopefully, this explains a lot of the technical terms and you have a better understanding of what a Services Oriented Architecture is
  • You referred to service oriented applications – why is that going to be important.
  • Mixture of converted legacy & systems developed in the past decade Whilst individual internal designs may be strong, functionality is not available outside the systems I.e. project based development – optimisation of a project’s deliverables perhaps at the expense of deoptimising the overall landscape Strong database integration without a coresponding integrated function design – tight coupling via the database Net result is poooooooooooor responsiveness to change. The most important point!!!!!!!
  • As years passed, these departmental solutions slowly gave way to out-of-the-box applications (JDE, ORCL, PSFT, etc.) which provided similar if not more functionality. These applications helped automate a lot of the departmental processes and data capture (I.e. HRMS, MRP, etc.). The value prop here was that I.T. no longer needed to develop and maintain these application. They simply provided the infrastructure support and management for them. For each deployed application there were many infrastructure options and very little standards support amongst each of them. This required new training and skills development for each new application. In addition to the complexity of maintaining such an environment, the other short coming with these solutions were that they were pretty much focused internally with very little or no consideration for any external business processes. So an order management solution, for example, captured an order which was printed and shipped to manufacturing for fulfillment. As you can imagine, the opportunity cost due to the lack of integration would have been quite large depending on the volume of orders they needed to fulfill. Analogy: Stores – butcher’s stores bought food from multiple farmers and provided a single place where people could go to buy all of their meat – whether it was beef, chicken, lamb or whatever.
  • As years passed, these departmental solutions slowly gave way to out-of-the-box applications (JDE, ORCL, PSFT, etc.) which provided similar if not more functionality. These applications helped automate a lot of the departmental processes and data capture (I.e. HRMS, MRP, etc.). The value prop here was that I.T. no longer needed to develop and maintain these application. They simply provided the infrastructure support and management for them. For each deployed application there were many infrastructure options and very little standards support amongst each of them. This required new training and skills development for each new application. In addition to the complexity of maintaining such an environment, the other short coming with these solutions were that they were pretty much focused internally with very little or no consideration for any external business processes. So an order management solution, for example, captured an order which was printed and shipped to manufacturing for fulfillment. As you can imagine, the opportunity cost due to the lack of integration would have been quite large depending on the volume of orders they needed to fulfill. Analogy: Buying dinner for the family – have to visit stores selling multiple products – customers have to visit the butcher, the baker, the greengrocer, and the wine store to assemble all of the ingredients needed for the whole meal. Each store required a different cash transaction, travel, and so on. Portal = A strip mall. Park once, but visit all the stores without having to drive from place to place.
  • Adaptability and Agility are two key business requirements of most companies today. To deliver these requirements, a standards based approach has been proposed over the last few years. It is a Service based approached where the key component is an Orchestration layer that sits above the collection of applications. It is at this layer the enterprise business process is assembled using standards based interfaces. This approach is often referred to as a Service Oriented Architecture. The resulting applications are usually referred to as Composite Applications. Today, using standards based tools and interfaces, the I.T. department is now able to deliver new modifications and additions to the enterprise business process much more quickly. This approach also means that organizations can now have some insight into the entire business process the orchestration layer has visibility into the overall business process. Constraints still do exist at the individual application level. Some applications will allow slices within their business processes to be exposed and consumed while others wont. Most applications, like SAP, are exposing individual functions/APIs as a Service object today but still work under a certain process model. Others with Event based models, like those from Oracle (PSFT, EBIZ, JDE) are more flexible in adapting to the user new requirements. (Analogy: Bringing the whole shopping experience into a Supermarket. Now you can shop for all your groceries including the produce and meats at the supermarket. There might be times when you might find the local butcher a better option (ie. Cheaper, better quality, custom services, etc.). With SAP, as long as the butcher shop is part of the supermarket you’re fine, if it exists outside the supermarket then you only can use the butcher services in the supermarket or those that are affiliated. With Oracle, you are free to purchase and employ the services of the local butcher if he meets your needs.)
  • Adaptability and Agility are two key business requirements of most companies today. To deliver these requirements, a standards based approach has been proposed over the last few years. It is a Service based approached where the key component is an Orchestration layer that sits above the collection of applications. It is at this layer the enterprise business process is assembled using standards based interfaces. This approach is often referred to as a Service Oriented Architecture. The resulting applications are usually referred to as Composite Applications. Today, using standards based tools and interfaces, the I.T. department is now able to deliver new modifications and additions to the enterprise business process much more quickly. This approach also means that organizations can now have some insight into the entire business process the orchestration layer has visibility into the overall business process. Constraints still do exist at the individual application level. Some applications will allow slices within their business processes to be exposed and consumed while others wont. Most applications, like SAP, are exposing individual functions/APIs as a Service object today but still work under a certain process model. Others with Event based models, like those from Oracle (PSFT, EBIZ, JDE) are more flexible in adapting to the user new requirements. (Analogy: Bringing the whole shopping experience into a Supermarket. Now you can shop for all your groceries including the produce and meats at the supermarket. There might be times when you might find the local butcher a better option (ie. Cheaper, better quality, custom services, etc.). With SAP, as long as the butcher shop is part of the supermarket you’re fine, if it exists outside the supermarket then you only can use the butcher services in the supermarket or those that are affiliated. With Oracle, you are free to purchase and employ the services of the local butcher if he meets your needs.)
  • So how will Project Fusion differ from SAP’s SOA approach? The major difference (and requirement) here is that it is a Business Analyst who is typically doing the assembling unlike the earlier scenarios where there was a heavy dependency on I.T. Why are Service Oriented Architectures relevant to our customers? What does it mean and what are the benefits? Service Oriented Architectures take integration to a higher level. Business Processes change over time, and companies need to respond to those changes very quickly. Companies tend to consolidate systems. Existing processes need to be supported by new service providers. Services are being outsourced, but still need to be integrated with the process. Specific services are available that are not part of your existing system. In a SOA environment you can integrate them easily. In a SOA, not only integration is being standardized (XML/SOAP) but also the definition of process flows is standardized (BPEL, BPMI). The benefit of standardization makes integration with different solution partners much easier and flexible. The end result of a SOA architecture is flexibility and lower TCO. Analogy: Services: Regional variations. A grocery chain may wish to offer different selections of produce in different parts of the country. Since they have a pre-defined infrastructure for managing produce, they can easily switch out produce from one vendor and add produce from another without major changes to the overall shopping process from the customer’s point of view. Owning the stack: If the supermarket chain now buys back into the “supply chain” I.e. it buys some of the farms that provide it with meat, then they can standardize, lowering costs, and improving overall customer service, since they’re more in control of the whole delivery and customer service experience.
  • So how will Project Fusion differ from SAP’s SOA approach? The major difference (and requirement) here is that it is a Business Analyst who is typically doing the assembling unlike the earlier scenarios where there was a heavy dependency on I.T. Why are Service Oriented Architectures relevant to our customers? What does it mean and what are the benefits? Service Oriented Architectures take integration to a higher level. Business Processes change over time, and companies need to respond to those changes very quickly. Companies tend to consolidate systems. Existing processes need to be supported by new service providers. Services are being outsourced, but still need to be integrated with the process. Specific services are available that are not part of your existing system. In a SOA environment you can integrate them easily. In a SOA, not only integration is being standardized (XML/SOAP) but also the definition of process flows is standardized (BPEL, BPMI). The benefit of standardization makes integration with different solution partners much easier and flexible. The end result of a SOA architecture is flexibility and lower TCO. Analogy: Services: Regional variations. A grocery chain may wish to offer different selections of produce in different parts of the country. Since they have a pre-defined infrastructure for managing produce, they can easily switch out produce from one vendor and add produce from another without major changes to the overall shopping process from the customer’s point of view. Owning the stack: If the supermarket chain now buys back into the “supply chain” I.e. it buys some of the farms that provide it with meat, then they can standardize, lowering costs, and improving overall customer service, since they’re more in control of the whole delivery and customer service experience.
  • So Why Oracle? To summarize, Oracle provides proven technology, the richest set of applications, industry leading Grid Computing, the greatest business insight and complete end to end security. Why? So our customers can realize the promise of Service Oriented Architecture… Better decisions and an agile enterprise all at the lowest cost.

SOA and ERP SOA and ERP Presentation Transcript

  • SOA and ERP
  • Selim Burduro ğ lu Enterprise Architect Friday, December 2, 2005
  • Agenda
    • ERP Market Trends and Evolution
    • What is Service Oriented Architecture (SOA)?
      • What makes up an SOA?
      • Definitions and Brief Description
    • SOA Stages for ERP
    • Project Fusion & Oracle Fusion Middleware
    • Evolution of Application Architecture
    • Benefits of SOA
    • Bottom Line
  • ERP Market trends
    • Continuing vendor consolidation
    • Fewer large new deals, more sales to existing customers
    • Emphasis on recurring revenue
      • Maintenance, hosting, subscription licensing
    • Focus on midmarket and industries
    • Growing importance of SOA platforms in technology buying decisions
    • Simplicity and usability (UI, tools, reporting)
    • Lifecycle Management (implementation, upgrades)
  • Evolution According to The Emergence of ‘Applistructure’ Ken Vollmer March 18, 2003 The increasing availability of prebuilt horizontal and vertical business processes designed to be used with application integration middleware is a trend that will have significant impact on the software market … The increased usage of prebuilt business processes is resulting in a blurring of the boundary between application software and infrastructure middleware and creating a new class of software that could be referred to as “applistructure” software.
  • Evolution According to
    • ERP systems became a universe of their own
    • Integration was never a key strength of ERP system
    • ERP vendors are stuck in own development history
    • Users don’t like revolutionary changes to the applications world
    • Web Services and SOA (Service Oriented Architecture) are the new driving forces for architectures
    Source: ERP&SOA – A Contradiction? Meta Group Interactive Briefing Paris – 29 April 2004 Ruediger Spies (VP Enterprise Application Strategies)
  • Evolution Summary Applistructure Applications Infrastructure “ the emphasis in the war for domination in ERP systems is moving away from business functionality and toward a battle about platforms .” Stewart McKie of Ventana Research March 14, 2005
  • Applistructure
    • A successful applistructure will comprise five elements:
      • Continuously decrease the operational cost of information technology
      • Permit a fast and flexible reconfiguration of business processes
      • Deliver secure and reliable service levels
      • Permit upgrades and product enhancements on the fly
      • Allow different technology providers as well as custom/legacy code to plug and play seamlessly
    Source: Applistructure: The Next Big or Bust Thing for Enterprise Applications? Monday, January 03, 2005 Erik Keller
  • What is SOA?
  • ? SOA XML WSDL BPEL UDDI SOAP WS-S
  • General Contractor X BPEL Process XML – Extensible Markup Language UDDI – Universal Description, Discovery and Integration Service WSDL – Web Services Descriptive Language Web Service Web Service Web Service Web Service Web Service Web Service Web Service BPEL – Business Process Execution Language SOA UDDI “ Concrete Estimates” call 555-1234 (WSDL) XML XML SOAP SOAP – Simple Object Access Protocol
  • Definitions
    • A service is a unit of discrete business functionality.
    • A service oriented architecture provides a standards based platform that allows services to be provided, discovered, and consumed by each other, to facilitate the creation of a orchestrated business process.
    • A service oriented application is a set of application functionality that fully leverages the power of a service oriented architecture .
  • SOA stages for ERP
    • Integration of heterogeneous applications across multiple platforms
      • Time frame: Now
    • Modular components within suites
      • Time frame: Two to three years
    • Market transformation to standards-based architectures
      • Time frame: End of decade
  • The Future of Applications
    • Leveraging Infrastructure to lower cost of obtaining and using new application functionality(Composite App) – Applistructure
    • Based on an Application Infrastructure – Service-Oriented Architecture
  • Common Architecture Today FBT PAY G NTS TRDS Client Customs RRE IPS Integrated A/C Refunds RBA Def Payments Excise CR PKI ECI ADD AWA ELS Client Staff Remote Staff TAX AGENTS GCI Call Centres WOC CCD TASS Staff Phone Compliance Staff BOA Ref material Bus. Intel NTS A/c BEP CDCC CWMS BANK DDDR 1 Data……. Penalty Business IVR 1
  • What is SOA Really About?
    • 40
    65 % of IT Budgets spent on Integration Activities % of ERP Application Implementation Costs spent on Integration
  • Integration vs. Interoperability
    • Integration
      • Two (or more) applications exchange data
    • Interoperability
      • Two (or more) applications are able to exchange information (if they want to).
    It is About Reusability!
  • Project Fusion Oracle Fusion Middleware Oracle Information Age Applications
    • Project Fusion
    • A evolving process or “journey”
    • Initiative to build
      • SOA-based Information Age Applications
      • and the Fusion Middleware required to enable them
    EBS JDE PSFT Project Fusion Time
  • Oracle Fusion Middleware
    • Family of integrated, standards-based, customer-proven products
    • Enables greater agility, better decisions, and reduced cost & risk today
    Fusion Middleware IS that infrastructure. And is available now! Development Tools Orchestration Security Portal Integration Management Collaboration
  • Evolution of Application Architecture Infrastructure DB Tools Applications
  • … and more applications… Applications Infrastructure DB Tools DB Tools DB Tools
    • Issues
    • Inconsistent look-and-feel
    • Inflexible, hard to change
    • Poor information access, integrity
    • Leads to…
    • Multiple user interfaces
    • Fragmented processes
    • Silos of data
    DB Tools
  • Evolution of the Platform Emergence of Orchestration Applications Infrastructure Business Process The Onboarding Process DB Tools DB Tools DB Tools DB Tools Core HR eRecruit Badging Security
    • Promise of Middleware
    • Agility & interoperability
    • Reduces TCO
    • Adaptable BPs
    • Middleware
    • ‘ Platform’ solution based on industry standards
    • Single vendor sourced
    • ‘ Holistic’ business process management
    ‘ Middleware’ Orchestration
  • Evolution of the Platform Emergence of Orchestration Applications Infrastructure Business Process The Onboarding Process DB Tools DB Tools DB Tools DB Tools Core HR eRecruit Badging Security
    • However today’s applications...
    • Still manage their own workflow
    • Need to retrofit industry standards
    • Don’t natively leverage the Middleware capabilities
    ? ? ? ‘ Middleware’ Orchestration
  • Evolution of the Applications Emergence of Services Oriented Architecture (SOA) ‘ Middleware’ Applications Orchestration Infrastructure Business Process The Onboarding Process SOA SOA DB Tools DB Tools DB Tools Core HR eRecruit Badging Security Services Services
    • SOA
    • Applications
    • Standards based Business Process Management
    • Common language shared by applications
    • Plug and play functionality
    DB Tools
  • Fusion Middleware: The Enabler Orchestration + Infrastructure ‘ Middleware’ Oracle Fusion Middleware Services Applications Orchestration Infrastructure Business Process Business Process DB Tools Services SOA SOA DB Tools DB Tools DB Tools
    • Oracle Fusion Middleware
    • Family of integrated, standards based, components
    • Based on existing, mature technology products
    • Over time adding the best design ideas from
      • eBusiness Suite
      • PeopleSoft Enterprise
      • JD Edwards EnterpriseOne
    DB Tools
    • Data Hubs
    • XML Publisher
    • Identity Mgmt
    • Integration
    • JDeveloper
    • Oracle Portal
    • BPEL / BAM
  • Application Server Leader Source: Forrester Wave™: Application Server Platforms Q1 ’05 O r acle M ic r oso f t IBM SAP BEA S y s t ems Sun M ic r os y s t ems R is k y B ets C o n t enders L eaders St r ong P e r f o r mers C u r r e n t o ff e r ing St r a t egy W eak W eak St r ong St r ong M a r ket p r esen c e N o v ell
  • Applistructure Leader Source: Applistructure: The Next Big or Bust Thing for Enterprise Applications AMR Research Report, 1/3/05
  • Oracle’s SOA Provides
    • Integration Repository – Provides single definition of all interfaces and catalogs all published APIs
    • Business Activity Monitoring – Allows business users to set performance targets, monitor exceptions
    • Business Process Execution Language – using GUI and Enterprise Services, business analysts can adjust business processes
  • Benefits of SOA
    • Simplified Integration – Connect disparate applications quickly by creating standardized services
    • Increase Reuse – Applications components are easily used saving development time and increasing application reliability
    • Easier Maintainability – Changes/Version are not all-or-nothing
    • Greater Agility – Rapid deployment of business processes or modifications of existing ones in response to market changes
    • Reduced Risk – Adaptable processes and single security model for accessing services enables ongoing regulatory compliance in a timely, cost-effective manner
  • Applistructure
    • A successful applistructure will comprise five elements:
      • Continuously decrease the operational cost of information technology
      • Permit a fast and flexible reconfiguration of business processes
      • Deliver secure and reliable service levels
      • Permit upgrades and product enhancements on the fly
      • Allow different technology providers as well as custom/legacy code to plug and play seamlessly
    Source: Applistructure: The Next Big or Bust Thing for Enterprise Applications? Monday, January 03, 2005 Erik Keller
  • Why Oracle? Insight – Agility - Lowest cost
    • Proven technology to implement SOA
    • Richest set of applications services
    • Industry leader in grid computing
    • Delivers accurate information faster, for smarter decisions
    • With end-to-end security
  • The Bottom Line
    • Web Services is an enabler of Service Oriented Applications not the answer
    • Service Oriented Applications should be transparent to end users and increase productivity
    • Oracle is committed to delivering the both the parts and the solution to meet your business needs
  • Q&A A Q &
  • Thank You!