The discussion of the merits of on-demand versus on-premise applications takes a new twist. Joe McKendrick at ZDNet asks the question:
“Is SOA essentially ‘Software as a Service’ contained within the enterprise walls? The analogy makes a great elevator speech, especially if one is hard-pressed to describe the philosophy of SOA to end-user customers.” See Why not sell SOA as ‘internal’ SaaS?
There are countervailing responses to this thought, one stating, “SOA is weighted down by heavy internal enterprise infrastructures, while SaaS offers far nimbler and cost-effective third-party service options”.
This response seems to mistake the intrinsic concerns of the enterprise for the essential nature of the architecture: the enterprise has much legacy infrastructure that simply cannot be disregarded, and which must eventually be integrated into its entire computing system.
As McKendrick points out, “there are several issues that need to be addressed in a converged SOA-SaaS offering, including security, software licensing, and network and service reliability.” Indeed, and these are huge issues for every organization, and the things that keep IT awake at night.
It’s true that the business people within a company find it hard to understand service oriented architecture, and IT has a hard time explaining it. Any semantic tool that helps may prove useful. Demonstration probably works better however.
“The IT team knew for 3 years that a BPMS and SOA solution was the answer to the problems that they faced each day. But IT had not figured out how to sell it and how to fund it. Finally, the pain became so great that IT realized that they had to figure out a way to sell these concepts to the business. First they showed that the cost/benefit just in IT was substantial. This got people’s attention. Once they got people’s attention, they were able to engage the business and gave the business ownership of transforming the company. Once the business had bought in, the rest was history. So what is the moral of the story? Aligning technology with real business cases increases your ability to sell technology to those who write the checks. ” From How to get the business to sell SOA for you
It may in the end be easier for evangelists to focus on services: this is something everybody gets. When Dovetail CRM comes into an Amdocs Clarify install and presents the department with a myriad of new functions, some of the best magic is happening through services consumed by the thin client, either though Dovetail’s huge library of APIs for Clarify or through web services.
Agents find they can open or amend cases through email, and make Ad Hoc queries on the fly in an open-case situation. IT finds it can easily customize a particular application for a unique function using Dovetail Web Services. These are simple yet crucial business processes that the business people understand intimately: it’s not a great step to talk about services in the same breath as processes.
Any serious corporate IT endeavor will be marked by an intensive planning process, in which business people and technical people will try to come to agreements about what they’re doing. Equally, business processes and technological services need to become aligned. As we’ve noted often, this is a very difficult task, and yet a crucial one.