Were business process management (BPM) and service-oriented architecture (SOA) made for each other? The two are like "kissing cousins," according to Celent's Donald Light. Another industry watcher, Vivek Mehra, vice president, global financial services and insurance, for technology consultant Keane, doesn't believe BPM and SOA were envisioned in that way but adds, "That's how it's panning out."

Light, a senior analyst in the insurance practice, describes SOA as an important landmark on BPM vendors' technology road map. "In terms of the reality of 2007 applications and technology in the BPM space, vendors don't have a story to tell to a prospective buyer that doesn't include SOA," he says. "The reason the SOA story is so important [with BPM] is a vast working majority of insurance companies have some kind of SOA element to their own IT road maps and architecture."

There is little doubt the two sides co-exist well. Mehra credits the SOA technology itself. "Its availability and applicability is very strong in the insurance space," he observes. The question of adoption still remains, though. "There's a serious lag in the insurance community compared with the rest of financial services," says Mehra.

BPM designs, orchestrates, and controls the execution of business processes, explains Light. SOA, in effect, designs, orchestrates, and controls the exchange of information in applications and databases. "With relatively minor exceptions, you cannot exercise processes within BPM unless you are exchanging information among applications and databases," he says.

The promise of SOA is the ability for software to be written and reused, indicates Mehra. SOA to business users is not pertinent, though. "It's a technology paradigm," he says. "If you write a piece of software and design it for reuse, you don't have to keep reinventing it if someone else wants to use it."

For example, if a business user wants to look up name and address for a customer, programmers can write the process to find a name and address once, and anyone else within the enterprise can reuse that function without having to rewrite the program. "The concept is software made into a modular fashion that can be reused and plugged in and also be technology agnostic–it works regardless of your investment in a particular platform," says Mehra. "The promise of reuse is a powerful concept because it brings reduced costs in application development, ease of maintenance, and the ability to think of software as a building block, combining services to make more powerful business services."

Some of the BPM vendors used to sell their wares as an SOA function, an application server, workflow tools, or business rules engines. "Now, [vendors] are using the moniker BPM because for the business user the technology is sort of irrelevant," asserts Mehra. Business users have a process and do their tasks and know the workflow. Most couldn't care less what the technology is. "For an IT shop, what makes BPM attractive is now you can apply the same SOA paradigm," he says. "You get clarity in the process by putting SOA in with the [BPM] tool. You get the ability to add and delete rules without coding anything, and what makes it possible is the underlying design of the technology is done using an SOA paradigm."

SOA has been a boon to BPM because it allows the business to make some fundamental changes in the way the business operates. Prior to SOA, business users would conduct process analyses, but when they went back and tried to map the changes with IT, they learned systems changes were very expensive, and in some cases, they couldn't accomplish what was recommended. "With SOA so prominent, the tools are there to implement these BPM proposals that are becoming popular in the industry," says Bill Hartnett, general manager of the insurance solutions group for Microsoft. "It's been an enabler for that side of the business."

SOA and its running mate, Web services, are terms that are used by different organizations–insurers and vendors–in different ways. At its highest level, SOA means exposing functionality in a reusable way, Light believes. "It has been a feature of environments for a very long time in the sense IT groups figured out it's better not to reinvent the integration or connectivity wheel every single time," he says.

BPM is more of a tool than SOA, though. Mehra suggests the two intersect with concepts such as when a carrier performs a credit check. "If you can identify discreet steps, you can codify those steps without programming," he says. "You are making the workflow discreet. You are creating events and a process workflow. That marries well with SOA because the concept of BPM is once you codify the process, you can change it without programming."

SOA enables BPM because the concept is the same, explains Mehra. "If you consider SOA the way in which you construct an underlying piece of software, and if you consider BPM as sort of putting a workflow or process definition on top of the SOA, then you can consider SOA to be an enabler of BPM," he says.

Not surprisingly, SOA and BPM often are spoken of in the same breath. "[SOA] marries well with the concept of a process step or a function," continues Mehra. "When you combine many functions together, you get a process step. That's how software vendors are converging on this space."

Hartnett believes a combination of BPM and SOA allows insurers to align technology and make it a slave to the business process vs. the other way around. "Mainframes have structured ways of doing data processing, and insurance grew around what the mainframe data processes were," he says. "So, business processes have been a slave to the technology that was popularly in use. With the advent of SOA and more flexible architecture, we believe you can flip that around."

When mainframe systems came into use 40 to 50 years ago, they were a great boon to the insurance industry. "You had to structure your operations and business processes around what the machinery could run," says Hartnett. "Over the years, a number of arcane and not very useful processes evolved, and we still run the business that way."

The reason SOA has become popular and developed as an architectural technology to begin with, according to Hartnett, is what he calls an "unholy alliance between business processes and traditional legacy technology." What carriers wound up with were huge processing systems that not everyone understood, he remarks.

As the business grew, customer quality concerns arose because the mainframes couldn't service customers well. "That situation became so critical the industry needed to look at a solution, and SOA became the solution," contends Hartnett. SOA has allowed companies to look at their business process first. For the insurance industry, that led to establishing processes for the right way to settle a claim and even more granular issues such as the right way to settle a $100 claim vs. a $100,000 claim and how to make sure the right adjuster got the right claim. "If you can design your process to support the kind of customer experience and employee experience you are trying to create within your organization, then you can use SOA to map out the technology pieces to the BP pieces," says Hartnett.

The Generali Group in Slovenia faced two key issues when it directed its attention to a BPM solution. The first was the company was preparing to launch a new direct sales channel with call center and Internet; and second, a new insurance product was about to be introduced, according to Branko Kmetec, chief process officer for the carrier. "This was a business project with a tight deadline, because of the existing situation with processes and the IT infrastructure," he says. The Generali infrastructure consisted of several legacy applications that made it difficult to communicate with each other. "We were looking for a solution to manage processes regarding the new sales channel and the new product," explains Kmetec. "Metastorm [Generali's BPM vendor] had a different approach–developing by designing. It was an interesting approach, taking a position between our IT and the business guys."

Generali's reaction to the problem was to combine two steps. "One was to be able to give access [to the business users]," says Kmetec. "The second was to build Web services, which was a key way of communicating with systems."

Integrating the Web services turned out to be quite easy and fast, reports Kmetec. "We did some testing and were quite satisfied with the results," he says. "It was so easy and so fast we went with it."

The SOA initiative is quite strong in Generali, affirms Kmetec. "We use it more on a business-project basis rather than on an enterprise initiative," he says. "We don't have an official SOA initiative, but it is the preferred way to integrate."

Kmetec indicates the biggest problem when Generali started the project was it did not have a clear idea of what would happen. "We had some diagrams, but compared with real issues, there was a lot of information missing on the systems side and on the human processes side," he says.

Because of the tight deadline, the project had to be completed within three months. Fortunately, a month or two after the launch, everything stabilized and optimized the processes. "We were able to adapt to the market and to our customers," notes Kmetec.

Generali always is looking to make process improvements, Kmetec relates, and in a little over a year since going live with the BPM solution, the carrier has made 50 such improvements. "When we started with this initiative, we found we could set up other processes," he says. "The BPM initiative is quite strong with us, and it's enabling us to automate several processes."

There are three things insurers need to be concerned with in the marriage of SOA and BPM, Mehra believes. For a lot of carriers, the first problem is the process itself is not always documented. "You will find processing documentation is sketchy at multiple levels," he says. "The tool is not going to fix the process if [the process] is broken."

The tool is just a means of codifying what exists. Before a company even can think of building BPM or SOA, Mehra advises carriers first have to think of how to optimize the process–filling in the missing gaps and handoffs–especially between different business silos.

Questions need to be asked, such as: Where are the handoffs? What are the process steps? Only when those are answered can a carrier think about codifying that information in a tool. Then IT people can think of connecting the processes using SOA. "It's a progression," says Mehra. "You can't just attack it with a BPM tool. That's what firms need to be aware of."

The second issue for insurers to recognize involves process enablement and workflow, continues Mehra. Any type of technology middleware works only as well as the underlying data. He uses an analogy: People can fix the plumbing at their house, but how do they make sure the water is safe to drink? In this case, the data is the water. "You can fit the BPM and SOA applications, but if your data is inaccurate or incomplete or you can't provide it in a timely manner, you might as well scrap the investment because you are not going to get value from it," cautions Mehra.

In order to get true value from BPM and SOA, Mehra suggests companies need to invest in making sure their data is trustworthy along with investing in the data architecture. "There are many pieces to the puzzle on the enterprise landscape," he says. "Buying a BPM tool or buying an enterprise service box, which is used interchangeably with SOA these days, is not the answer."

The third area of concern for insurance companies is governance of the enterprise, reports Mehra. Because BPM and SOA by themselves can't exist or succeed in a vacuum, Mehra points out the only way they work is if carriers have good program management and IT governance in place. "Without [governance], all of this is meaningless," he warns. One of the things carriers need to remember is SOA enables BPM, and lines of business have a shared interest in reusing technology.

Reusing technology doesn't happen by accident, Mehra emphasizes. "No one is going to have the incentive to make something reusable by another division," he says. "SOA makes a bold assumption lines of business will cooperate and invest in a shared infrastructure."

SOA governance has become a big deal with insurance carriers, Mehra comments. Insurers had to find a way to address the issue of once they've created the first level of services and the first reusable components, how do they publish them? SOA relies on a Yellow Pages type of construct to see whether the service exists. If it does, users find the address for it and use the service, notes Mehra. Governance creates a policy of making the service available throughout the enterprise and determines who pays for the service. "A system of chargeback to a division becomes important and requires some type of governance," he says.

The first driver behind the SOA enablement of BPM, according to Hartnett, is improving the level of customer and employee experience when inferior technology is involved. "There's a whole decade worth of customer expectations that have been set," he says, pointing to the ease of use customers find with Web sites from Amazon and eBay, among others. "The insurance industry finally woke up a few years ago and realized it couldn't meet those customer expectations," says Hartnett. "If it didn't get its act together, someone would come along and change the way insurance is sold, so the industry had to we figure out how to use these new tools and processes."

"Experience" is a watchword of what people are trying to achieve, continues Hartnett. "It's not just improvements but transformation," he says. "The best example is Progressive getting comparative rates online. It's that approach that captures the customer imagination and eventually captures the employee's imagination."

Hartnett also believes the gains in technology have been impressive in the last 18 months. "There has been close to $30 billion worth of pure research and development that has gone into improving the basic technology that runs the insurance industry and American business," he says. "The technology itself has become a tool rather than an obstacle. It makes it possible to build SOA architecture without a lot of heavy lifting."

Maturity of the technology has been an issue with SOA in the past, remarks Mehra, but the industry is at the point where the tools have matured, and so the promise of building a service once that can be reused regardless of platforms is coming true. Still, the adoption level among insurance firms is lagging behind other financial services, he adds. "It's clearly not at an enterprise level," he says. "We're seeing more of an organic-type growth as opposed to the top-down version–an enterprise mandate to create reusable shared services that people invest in across lines of business."

Mehra also believes carriers have to determine whether they have the expertise to build the services. "Traditionally, insurance companies have struggled with legacy systems, so their big challenge has been to keep abreast of the changes in the last 15 years rather than jumping to SOA," he says. Carriers have had to struggle with data issues, make sure codes can be trusted, and make sure they are in the process of upgrading their legacy systems or extending the life of their legacy systems.

Despite the challenges, Mehra observes many of the leading-edge insurance carriers are investing in SOA, though not with enterprisewide adoption. "You can drill this fancy plumbing, but if you don't have the data, it's not worth your while," he says. "It comes down to data and analytics, and insurance companies don't have a handle on that yet."

In the past, Hartnett got in trouble for saying things such as, "Insurance is the Amish of financial services." But he maintains his words should be taken as a compliment because during the height of the dot-com bubble, the insurance industry was more circumspect about what it was doing and didn't rush out and spend money on what proved to be useless technology. "The mainframes in use were pretty good machines and ran the business well for a long time," he says. "The insurance industry missed a generation of frantic spending by others that didn't lead to much advancement. Insurers were much more rational about what they were doing and found the right technology to bet on and employ it in ways to move the business forward."

Today, Hartnett contends there have been advancements by the industry, but he describes them as "lumpy. Some [insurers] are doing a good job. Others are still asleep, but there are some very smart [insurance] execs out there pushing their business forward."

What will drive usage, predicts Light, is an increased level of templates and frameworks from vendors. "BPM solutions are not plug and play," he says. "In a sense [BPM] is like any other major core system. It takes time, effort, and money to get it going."

Carriers need skilled people, both on the technical and the business side, Light notes. "It's easier for the larger companies to find those kinds of people and make those investments," he says. "It's harder as you go down the scale in size. That's the fundamental explanation as to why there's difficulty. To the degree a vendor can offer a quick-start BPM kit and have sufficient granularity in terms of processes, that makes it easier for people from a smaller company to make the cost investment to keep it going. It's never going to be a plug-and-play kind of application."

Special Reports /

Perfect Match

Related Stories

Recommended For You