Similarly, Service Oriented Architecture (SOA) is getting a lot of attention these days. Again, the basic concept behind SOA is not new and has existed for a long time. SOA basically involves exposing functionality from distributed systems in the form of stateless functions; this is similar to other distributed system architectures such as CORBA and DCOM. What is making SOA much more popular and prevalent than CORBA or DCOM ever did is the web services standards such as SOAP, WSDL, UDDI etc. Similar standards existed with CORBA and DCOM as well but were not open enough and led to vendor or technology lock-in. With web services, all the major vendors are behind the same set of standards, so there is a higher chance of interoperability between various systems and hence a higher potential ROI for SOA.
SaaS deployments are revenue generating businesses targeted directly at end users, whereas SOA deployments are usually created within IT environments and the services are exposed to other applications as opposed to end users. This way SaaS and SOA are very complementary in nature. In fact, they can't exist without each other.
What are the key elements of a SaaS platform? Every SaaS platform has to have a few core things in place, these are: multi-tenancy, ordering and provisioning, user authentication and authorization, service catalog and pricing, service monitoring,
Now, let's take a look at the key elements of a SOA platform. A typical SOA platform deployment consists of service producers and consumers from across the enterprise. Service producers publish services via the SOA platform, which get consumed by multiple service consumers. There has been a lot of focus on the technical aspects of a SOA platform e.g. service bus, communication protocols (e.g. SOAP), service interface definitions (e.g. WSDL), service discovery (e.g. UDDI) etc. The importance of service monitoring, management and governance is also well understood, but this is not enough. In a typical large enterprise, the service producers and consumers could be applications or systems belonging to different departments, organizations or even subsidiaries within the enterprise. In such environments, services cannot be produced and consumed informally without proper service management in place since there is a cost associated to hosting and exposing a service by the service producer. In order to derive this cost, the total cost of operations or ownership (TCO) needs to be taken into account besides the cost to create the service. Also, there are security concerns around publishing the services openly. This leads to the need for service catalog management, provisioning, authentication, authorization, usage metering and cross-department charging. As highlighted before, these are also the core elements of a SaaS platform. So as an enterprise SOA deployment matures, it is suddenly in need of the core functions of a SaaS platform.
Let's take a look at the flip side of this. Every SaaS platform needs to support the ability to add new service offerings and modify existing offerings in the service catalog with minimal changes to the core platform components. These additions or modifications should not lead to creation of a whole new SaaS platform for every service. Instead, all the basic functionalities of the SaaS platform such as ordering and provisioning, authentication and authorization, service catalog and pricing, metering, billing and invoicing, payments etc should be reused for multiple service offerings. Such reuse necessitates the need for a SOA platform. Further, use of a SOA platform enables other advantages such as a more flexible and plug-n-play architecture leading to lower overall cost of ownership.
It is probably quite intuitive that most complex architectures including SaaS architecture will benefit from SOA capabilities, but a SOA platform needing SaaS capabilities is not that intuitive. There has been a lot of hype around SOA for a while but most SOA deployments in large enterprises have either not been successful or have not provided the expected ROI because the SaaS elements are missing in these deployments. In order to realize the full benefits of large-scale SOA deployments, it is essential to have a SaaS like service management functionality in place. This is where SOA and SaaS together can enable the concept of "IT as a service" and help take IT to the next natural step in its evolution.
References:
http://cloudcomputing.sys-con.com/
http://cloudcomputing.sys-con.com/?q=node/1047073
http://en.wikipedia.org/wiki/Software_as_a_service#SaaS_and_SOA.5B10.5D
5 comments:
This is a great post Lubna! What you describe, and the notion that many SOA deployments have failed because they've been missing the SaaS elements is dead on. I don't want to sound like a commercial, but you've just so clearly articulated the essence of what SaaSGrid is all about for enterprise IT. It's enabling internal IT departments to benefit from the key components of mature SaaS delivery. Please contact me, as I'd love to chat with you.
- Jesse
This is a great overview on comparing and contrasting SOA and SAAS with great examples. I just want to add something I read about Service Oriented Architecture on SOA and SAAS.
When the pioneers in software as a service, such as Salesforce.com, first entered the market, many CIOs didn't trust it. The requirements for software as a service were driven largely by business unit management who were attracted by the prospect of not having the overhead of running systems.
Many IT organizations reluctantly went along with the software-as-a-service experiment, with many of them harboring the expectation that when these applications became “mission critical,” IT would need to move to a traditional software licensing model. It didn’t happen. By running the same application for many different companies, Salesforce.com achieved powerful economies of scale.
If software-as-a-service providers add Web service interfaces and provide all the associated interface information to their customers, software as a service can be integrated within a service oriented architecture.
So if companies implementing SOA realize that they’ve developed some applications that they can offer as services, they may have a new source of their revenue.
Thank for the inputs Vivian! I completely agree that integrating both software-as-a-service and SOA would bring in a lot of value for a company. The flexibility of SOA coupled with the on-demand functionality of Software-as-a-service can prove to be very advantageous. Software as a Service can take advantage of Service Oriented Architecture to enable software applications to communicate with each other. In this, each software service can act as a service provider, exposing its functionality to other applications via public brokers, and can also act as a service requester, incorporating data and functionality from other services. An example is Enterprise Resource Planning (ERP) Software providers leverage SOA in building their SaaS offerings (SAP Business ByDesign from SAP AG).
Hey I read this pretty late ,
Aboutt SOA , dont you think its to be just a set of over hyped RPC's.
I don’t think SOA is a set of RPC’s. Today, a vast majority of corporate systems are co-located and communicate using RPC. If you see RPC and SOA solves two different problems. RPC is all about getting systems that are co-located to effectively communicate with each other whereas SOA is all about getting distributed systems to communicate. One more difference worth mentioning is that in RPC scenarios the communicating systems are almost always owned by the same group. But in SOA different groups usually own the communicating systems and so 'robust' and 'flexible' messaging is critical. In this sense I feel that SOA and RPC need not be related.
Post a Comment