A Tool for Explaining SOA to the Business

Share it on Twitter  
Share it on Facebook  
Share it on Linked in  

Today, I want to continue a thread I started yesterday when I wrote about how IT should sell SOA to the business. The question is whether you should go into the more technical aspects of SOA or just focus on how it will benefit the business.


Certainly, there's a strong case for not talking about the technical aspects and just focusing on the business benefits. As someone who's harped a lot in my pre-blog past about IT/Business alignment, I can certainly support this -- after all, the business wants to know what value this has for the bottom line and customers.


But I don't believe this means you should avoid talking about the technology itself and why it's different. In fact, I think business will be very curious about why SOA will actually deliver some of the business benefits past IT projects promised to deliver, but didn't.


But this raises another question: How do you talk about the technical benefits of SOA without boring or overwhelming business people?


Recently, I interviewed Harriet Fryman, the senior director of product marketing for Cognos, for an Integrating the Enterprise Executive Briefing. (If you've only read the blogs on this site, you might have missed my weekly Q&As with industry leaders, experts and vendors. Check it out -- I think you'll be pleasantly surprised.)


Cognos offers a BI platform built on SOA, and Fryman shared how the move to SOA has impacted the company's product offerings and development process.


Fryman also related that customers are often confused about SOA and its value proposition:

When we talk to customers, they articulate value like reliability, like running in a heterogeneous environment. They can articulate the value and why they get the value, for example -- I can respond to peak periods because I can spawn to different platforms, but if you ask them what they get out of SOA, there's still a maturity link between SOA and the value add. And this is because there are a lot of definitions of SOA in the marketplace.

Because of this disconnect, Fryman spends a lot of time defining SOA to Cognos customers. And to do that -- wait for it -- she must discuss SOA's technical aspects. She begins by explaining that it's a platform built to be distributed, modular and loosely coupled. She then breaks it down into what she terms the Seven Principles of SOA. Here's how she explains it:

1. It's open and standards-based. 2. It's platform-neutral. It's encapsulated so that a ervice is the same service on Linux or Windows. 3. It's location-transparent. So it shouldn't alter to the user or IT what service is running where across the global infrastructure because when you call that service, it should know because of the network to go and get a response without knowing where that service resides. 4. It's peer-to-peer. There should be no master or slave. Every service is created equal. Which means those services can spawn and scale out without a single point of failure. 5. It's loosely coupled. So I can enhance capability within a particular service without impacting another service. 6. It's interface-based. So that, really, each service is a black box for the other services. 7. It's coarsely grained. It must be at a business level that you act with the service, not down in the bits and bytes. That makes it more reusable and it reuses the amount of chat between the services.


And then we take that and translate it into value for the customers: Efficiency, reliability and agility.

Now, I'll grant you, Fryman may be giving this speech to people who work in IT. But given that Cognos sells a Business Intelligence solution, I'm guessing she also spends a fair amount of time explaining SOA to business people.


I think her model for the seven principles works as an educational tool -- otherwise, I wouldn't be mentioning it to you now. The language is simple and, yet, it explains what makes SOA such a new and significant shift for IT.