Something Afoot In Insurance
This is the first of a series of posts about what a REST API should look like.
It started life as a set of internal conversations and … well, let’s call them “debates” to be generous to the participants … which eventually crystallized into a proposed co-ordinated approach to RESTful APIs. This begat a very successful insurance production implementation, leading to the adoption of the approach by all of CSC’s insurance software product groups.
That cycle was triggered several years ago by the realization that, in order to play in a modern digital ecosystem, CSC’s existing insurance solution offerings needed a makeover — a radical makeover.
CSCs Journey to the Digital Enterprise papers emphasize the role of the API (application program interface) to transform an enterprise application landscape and meet the challenges of the digital, mobile age.
Quoting the Digital Applications paper:
Services based on application programming interfaces help organizations combine information from older back-end applications in new and powerful ways, creating what’s known as the API economy. The resulting “full picture” information set can be used to further enrich customer experiences and improve employee decision making. These APIs support loose coupling for improved agility and sharing.
A recent CSC Tech Town Hall addressed the same themes, reinforcing the critical importance CSC places upon this aspect of digital transformation.
Where CSC is a software provider, we too must transform our software offerings to satisfy the digital expectations of our customers. We have to eat our own dogfood! So, in short, CSC’s existing insurance solutions needed to be API-enabled (among other necessary far-reaching enhancements not covered here!). So we dug in!
What about SOAP?
Now, an API doesn’t HAVE to be RESTful, right?
SOAP is a valid, well supported API protocol that most of our insurance software already offers, and well-defined industry standards are built on top of it — so job done, surely!
Not so fast — let’s look at these two facets of the existing APIs.
We’re not going to discuss if and how “REST is better than SOAP” — those arguments will rage on forever and you can find plenty of … well, let’s call them “debates” to be generous to the participants … using your favorite search engine.
SOAP has been successful in well targeted environments and for tactical technical integrations. It remains useful in certain contexts, for example when a single provider intends to expose only a small number of discrete services (e.g. insurer interfaces to Government healthcare systems in France).
However there are two points we would like to highlight:
SOAP as an integration style
Firstly, SOAP is “transport independent” (you can use it over HTTP, JMS, SMTP, smoke signal …). So, in the myriad SOAP-related standards (WS-*), we find pages and pages of detailed specifications of features that already exist in HTTP.
Hence, when using the now-defacto standard integration protocol of HTTP (adding an S to keep the boss happy!), there is a proliferation of extra (unnecessary?) infrastructure and complexity needed to run SOAP. And you also lose the use of other features of HTTP (caching being but one glaring example). Implications abound!
Secondly SOAP services (at least in insurance) tend to be highly focussed on existing expected functionality, exposing transaction services that the developers expect to be of use to the existing consumer base. This is what we call an “inside out” approach, as opposed to an “outside in” philosophy that engenders far more agile collaboration between service providers and consumers.
While some of these services may be reusable, many aren’t (see the next point for why), and adding new functionality/services requires development in the provider (server) system as well as the consumer (client) system.
For a participant in a digital applications ecosystem, where the software is provided as-a-service and uses to which data and functionality can be put are not pre-envisioned (see the quote from Digital Applications paper above), this is an unsustainable model.
Industry standards built on SOAP (or not, even)
Those points aside, our service-enabled insurance ecosystem was intended to allow us to apply discrete engineering principles to our software. Integration based upon precise service contracts and published, nearly immutable interfaces would provide Lego© blocks (or nuts and bolts, plugs and sockets) of business functionality that we could snap/screw/plug together to form complete applications.
All components would integrate together in their own well-defined domains, interchangeable within their function. The solution would be plug-n-play at the business service level, similar to, say, motor vehicle parts, motherboard architectures — and muskets. Utterly reliable!
Industry bodies came together to define standards for all insurance data, activities (transactions) and even connection points – ACORD, OMG, Telebib and others. “If we can identify all the connections with what each connection can do,” so the thinking went, “then we can just write software to the standard and get instant interconnectability.” The implementation would be where we could differentiate (better, stronger, faster).
But Legos (nuts/bolts, plugs/sockets) fit together because they are all the same and they don’t actually do much of anything. Legos don’t have any sort of behaviors that the Lego “engineer” must take into account when constructing her Tie fighter, house, or castle. She may need to consider color or size, but a yellow block does exactly the same thing as a grey block, which is to say, it fills space. One might need to select the right block to create movable sections in the construction, but a piece that provides a pivot or rolls does just that one thing.
As we rapidly realized, insurance processing is not a Lego model! It is a complex business that is subject to regulations, codified and enforced by a horrifyingly large number of authorities across states, countries, municipalities and extra-national jurisdictions, none of which are the same. Some are close, but really each authority thinks they’ve got it right and the others have it wrong.
It turns out that our “Lego” models needed to take into account “the room” in which the young Lego engineer constructs her masterpiece. In the living room red bricks only work on the ground floor, but in the kitchen the blue ones fill that role. When she carries her pride-and-joy castle from her bedroom to the kitchen, the drawbridge no longer functions or is subject to a new set of drawbridge regulations. So she needs to modify her castle to comply with kitchen regulations. But now it won’t work in her bedroom! ARGH!
But you know, if we could just get the kitchen regulators to agree with the bedroom regulators, then we could design a drawbridge that would work in both rooms.
“WAIT”, cries the reader to the strains of an overstretched analogy reaching its elastic limit. “There is no real difference between the bricks themselves!”
True — and that’s our point. Business services aren’t Legos. There are clear differences in the way our software components must behave, even if they fulfill largely the same function and maybe even fit in the same place in a topology as we move from location to location and provider to provider. And this often influences not just behavior, but also, critically, the interface itself.
Simply put, there isn’t enough uniformity in the problem space itself to impose a rigid standard. If we try to impose such a standard it is immediately at odds with the reality on the ground. If we make the “standard” too soft or extensible it renders it … err, non-standard. We actually find ourselves in a worse position than if we just created a different drawbridge or castle, even, for each room.
We are faced with a problem, then. It is demonstrably prohibitively expensive to maintain unique castles for each room — and each resident of each room — but the standards approach of the past has not helped us.
A Radical Solution
So, if not SOAP-encapsulated standards, then what?
Enter the valiant knight, Sir Royston of the Fielding, come to slay these dragons with his sword, REST, and lance, HATEOAS*.
The thesis was read (it required a lot of coffee), publications were procured (we’ll cite them as we go), forums were consulted and the internal jousting … er … debates … commenced.
Finally the birth of what we believe to be a fairly radical approach to REST was announced!
And THAT’S what the rest of this series will cover … we do love a good cliff hanger!
* P.S. (Martin) look, HATEOAS – Hypermedia As The Engine Of Application State – is just a fancy way of saying “Links Tell You What You Can Do Next” – so we call it LiTYWYCDoN!
P.P.S (Bill) No we don’t, and stop trying to push that stupid acronym on the world!
Martin Bartlett–Distinguished Engineer
Martin Bartlett is a principal in CSC’s insurance practice in the South and Western Europe region. Since joining CSC in 1988, Martin has played a central role in the architecture, design, development, implementation, deployment and support of some of CSC’s most far-reaching strategic projects in the insurance domain. He is considered the chief technical architect of GraphTalk A.I.A. and is a strong advocate for cloud-deployed SaaS solutions and the API economy.
See Martin’s bio.
Bill Ohnemus — Distinguished Engineer
Bill Ohnemus is a principal in CSC’s insurance industry practice in the Americas with 30 years of broad and deep experience developing and implementing solutions. As a solution architect, he is often sought out to coordinate and manage the technology direction for CSC’s insurance industry solutions, with recent emphasis on APIs and the supporting frameworks.
See Bill’s bio.