I have recently been told that almost all the technology RFPs going out have at least one question regarding support for SOA. I have also seen an opinion that most, if not all, policy administration system vendors in the US list SOA compliance as a feature of their systems, which is interesting because I am not aware that any UK based vendor would claim the same thing. In the US though, both carriers and policy administration vendors are locked in this dance, a dance that we've done before.

It seems to be a constant problem about how to reach potential insurance customers in younger demographics. Most of those conversations, unsurprisingly, have involved carriers connecting with customers via their Web sites. However, a recent story out of the Philippines serves as a reminder that there are other ways for insurers to expand the scope of their multi-channel distribution models.

An increasing amount of Scyllogis’ business is taking over the support and ongoing development of existing package systems within the insurance industry; Scyllogis provide an attractive  alternative to the original vendor for many reasons. Therefore, we were very interested to spot that Oracle were trying to put a stop to SAP performing a similar service, via a lawsuit in the US.

The Oracle Corp. lawsuit accuses SAP AG of "corporate theft on a grand scale" for the illicit downloading of Oracle software by SAP subsidiary TomorrowNow Inc. Texas-based TomorrowNow provides third-party software maintenance to Oracle customers.  At the heart of the Oracle case is the economic value of the maintenance contract in a mature software industry and the viability of third-party support, said Gartner Inc. analyst Dan Sholler. Germany-based SAP and Redwood City, Calif.-based Oracle are going head to head because SAP's TomorrowNow provides maintenance support for Oracle's PeopleSoft.

Scyllogis has not utilised offshore developers to date. The reason is twofold: Firstly, we are not convinced that this delivers the imagined savings. The development daily rates are certainly lower but more ‘water tight’ specification is needed that increases the necessary effort from the more expensive analysts. More project management is needed (again from the more expensive resources) and the development tends to take longer thereby cancelling out the cheaper daily rate. Secondly, the remoteness of offshore does not lend itself to the agile approach, where constant interaction between users, analysts and developers is key.