This might sound odd to some of you reading this, but I am regularly asked the following question ... "What is the difference between SOA and SaaS?".
Given the acronym soup of the IT industry I am not surprised to get that question and expect to for some time to come. The simple answer is that:
- Service Oriented Architecture (SOA) is a means of designing and building software. It is a manufacturing model.
- Software as a Service (SaaS) is a means of receiving software through an external party to your business similar to telephone or power utilities. It is a sales and distribution model.
Both SOA and SaaS are hot topics in IT as both deliver in very specific ways material reduction in costs of IT operations and deliver a more agile alignment between business needs and IT solutions. The manner in which those benefits are delivered is the key difference. And in many ways, to capture the majority of the cost reduction and agility benefits it is often best to incorporate both SOA and SaaS in your IT landscape.
Why incorporate both SOA and SaaS?
The main reason is that it makes sense to in-source as well as out-source some aspects of your business including IT. SOA provides a means to deploy and quickly re-configure as business conditions change the applications, databases an other infrastructure hosted in data centers owned by your company. Recent versions of many departmental and enterprise application stacks from major software providers deliver products with a SOA design and implementation. Often ERP functions such as order management, general ledger, and manufacturing planning are still predominately delivered in this fashion.
SaaS provides a readily accessible means to out-source the applications and databases (as well as some cases the functions) of a business. Some key examples include sales force automation, [http://www.saas-showplace.com/payrollservices.html] payroll, [http://www.saas-showplace.com/] expense reporting and recruiting. One of the key considerations with SaaS is how to effectively integrate these outsourced applications with the internally hosted ones.
This integration problem poses many challenges beyond the basic question of getting data moving between the source and destination. SaaS applications live outside the mostly hardened corporate firewall. Security and reliability are important considerations when moving things like identifying employee, supplier and customer information (such as bank accounts, tax id numbers, etc.). These are often financial transactions so they need to be audited and have a confirmed record of completion. And finally, SaaS applications get introduced to companies usually through a departmental initiative rather than a enterprise procurement process. So integration needs to be effectively managed to not drag down the SaaS deployments while at the same time not creating a "wild west" of one off integrations across major enterprise data systems.
In my next couple of posts, I will cover architectures for integrating internally hosted IT infrastructure with SaaS using SOA. I will also provide my thoughts on how a "soft appliance" like Intel SOA Expressway is a key ingredient in ensuring scalability, reliability, security as well as appropriate IT governance.