Service Oriented Architecture (SOA) is an IT term probably recognized by most large firms. That’s not surprising, since most experts agree SOA has a lot more value for organizations that use of a multitude of applications and IT-enabled business processes, often described as “enterprise” scale.
SOA isn’t hardware or software but rather a way of building and developing software applications. It’s more of a strategic or even philosophical approach to building a computing environment. There are tools that allow application developers and IT organizations within businesses to build SOAs.
With SOA, the idea is to create the ability for complex applications to interoperate through the sharing of information, functions and processes. It’s done through a sort of software “glue” often described as middleware and provides the ability for these complex applications to interoperate through sharing information, functions and processes.
“The primary benefit of SOA is the ability to reconfigure and reconnect applications more easily,” says software consultant David Chappell of Chappell & Associates Inc. in San Francisco. “The A in SOA is what’s really important. It’s an approach to designing, building and connecting software.” SOA allows business applications to expose “services” that can be used independently from the applications to which they might be tied. These services intercommunicate with each other, doing things like relaying instructions for simple data passing or much more complex processes such as co-ordinating multiple application activities in different software packages.
SOA can make it easier to tie different types of applications and IT resources together, making them work like a single and shared whole.
SOA isn’t a new concept. According to Chappell, the idea of SOA has existed for at least 10 years, but for the longest time it simply wasn’t practical to implement.
The idea is growing. Market research from Forrester Research Inc. suggests there’s strong interest in the SOA concept, especially among larger companies. Research published by the firm in 2005 showed almost three-quarters of survey respondents from companies with 20,000 or more employees said they were using or planning to use SOA. Conversely, only about one-quarter of companies with less than 1,000 employees said they were likewise planning or using SOA — and more than half of that group said they weren’t pursuing SOA at all.
Chappell agrees the smaller the company, the less value there is in a concept like SOA. Likewise, business professionals aren’t apt to care much about the SOA concept either, he says. “SOA is usually an IT undertaking,” Chappell says, explaining that its greatest value is seen in the efficiencies gained in IT operations.
Chris Brakel of Microsoft Canada Co. has a different take. He suggests there may be significant value in SOA for a smaller company, especially one that is technology focused — say, in the business of building IT products or providing IT services, such as managed hosting.
While Brakel agrees that a company’s IT organization benefits the most from SOA, business professionals also need to understand it.
“How do you describe the value of SOA to a business individual?” Brakel asked. “Find a business-focused problem to which you might apply SOA.”
Go one step further. If it’s IT’s role to support business and if SOAs make IT a more efficient and productive set of processes, then there’s clearly enough reason for business professionals to care about the concept.
SOA is emerging today because major software vendors have agreed on common standards that allow applications to communicate with each other. That standard is SOAP (simple object access protocol), or the more familiar term, Web services.
“What’s driven SOA is the vendor agreement on SOAP,” Chappell says. “It means it’s potentially easier to connect (different) software from different vendors. There hasn’t been a common standard to tie applications together until recently. This is new in the past five years.” But the big caveat is that, while SOAP is useful, it’s still not enough to build a true SOA. SOAP is fine for simple, direct connections between software, but it’s not so easy for networked applications, Chappell says.
“If I want to tie two of my software packages together and I’m using a network that’s always available…then that’s a good argument for SOAP. “The truth is, applications aren’t (available) all the time and the links between them aren’t always reliable,” he says. “In cases like that, simple, direct connections like the kind enabled by SOAP just aren’t sufficient.” Even though there’s agreement on the brand of glue being used to cement applications together to enable SOA, there’s a great deal more work still to be done to make it stickier.
McLean is editor-in-chief for IT World Canada. He can be reached at [email protected].
