When the company made apps from these systems available on the Web to help insurance agents decide how to classify their customers and assess risks, using the software required no specialized knowledge from agents other than how to reach the Hartford Electronic Business Center portal via a browser, says Jim Ruel, senior VP of small-business insurance.
At EXP Pharmaceutical, the company can reuse rules on particular drugs, which may be locked in one large application to be available across many applications. EXP has some 30,000 rules or policies tied up in its applications that govern how expired drugs are handled and accounted for. To keep applications in step with rapidly changing drug compositions and disposal procedures, the company is implementing a service-oriented-architecture approach that lets applications adapt to those changes.
By making the rules generally available to other applications, the approach could let EXP "build intelligence back into our applications" and produce new software at a much faster pace, Siler says.
So how is a service-oriented architecture built? An SOA layer can be built atop much of the existing software infrastructure. Implementers may follow whatever standards they choose--none is specified at this point--but most parties agree it's best to follow Web-services standards such as XML; the Simple Object Access Protocol; Web Services Description Language; and Universal Description, Discovery, and Integration. It doesn't matter what brand-name software or hardware underlies the standards, provided they make themselves accessible through Web-services interfaces.
Service-oriented architectures mean that the latest application doesn't need to know very much about the existing software infrastructure. It doesn't matter whether an app is running on a Windows, Unix, or Linux server.
One question IT managers raise is whether companies should build SOA software or buy it. IBM, one of the biggest proponents of this type of software design, sells proprietary message-passing software under its MQ brand name. Also under debate is whether companies require an "enterprise service bus" to pass messages from one software system to another. IBM, Tibco Software, and Sonic Software, a unit of Progress Software, say users need it--and they all offer one as part of their product lines.
Charles Stack, CEO of Flashline Inc., a maker of software that manages other software components for development projects, says buying into those products risks incompatibility should the industry agree on a standard. IBM and Tibco's service buses are based on proprietary messaging systems, and Sonic's is based on the Java Message Service, a standard that gets implemented various ways. No two JMS services function the same way and, consequently, don't easily talk to each other, he says. "Wait for a standard to emerge," Stack says, before making it part of your service-oriented architecture.
This story was updated Aug. 2, 2004, to reflect that Flashline makes software that manages other software components for development projects.