Don Goodenow
Director, Product Management, Reinsurance & Collections
StoneRiver
In my last post, I outlined how regulatory requirements have become more demanding of insurance carriers. Is this something we as software vendors should be concerned with? If so, what should we be doing about regulatory requirements?
Regulatory changes can directly and dramatically affect the way a carrier does business, so regulatory changes are important to a software vendor. The solutions we as vendors provide must correctly address the specific situations that can result in non-compliance with SOX and the MAR.
The regulatory changes and the economy’s financial problems have come as many vendors are undertaking a major refactoring of their Java-based products. These efforts should deliver the processing components a company needs in the new environment.
The technology that vendors use is an important consideration for carriers. Vendors must also be mindful of the new regulatory requirements and generally accepted accounting and control processes when we develop or enhance our products. We recognize that for carriers to appropriately evaluate a product, they must evaluate both the technology upon which it is built and the overall design and construction of the product.
Technology
The technology used can either enable or encumber a software product. It’s important for users to understand the capabilities and limitations imposed by the technology underpinning a product.
Many vendors, Stoneriver among them, are developing their new offerings using predominantly open source technology components acquired from certified sources (e.g., OpenLogic). Many of these components are commercially supported (e.g., Mule, Adobe Flex runtime, BlazeDS, etc.). These trusted source and supported “open source” components are generally regarded as being at the same level of reliability as proprietary solutions; many would argue that they are more reliable.
These components aren’t selected simply to reduce the cost of product ownership. They enable vendors to build a modern processing suite that delivers the processes and controls needed to support good management practices and mandated financial controls.
Design and Construction
A company can’t design and build an acceptable system if its people don’t have the needed knowledge and experience. Vendors need staff with an extensive depth of both technology and insurance industry experience if they are to be qualified to design and develop the insurance products for today and tomorrow.
Many new product offerings are based on a Service-Oriented Architecture (SOA) and built to operate on an enterprise service bus. StoneRiver’s is called the Insurance Integration Platform™ (IIP). SOA architecture can deliver a host of powerful features, enabling insurance processing components to use common service components. SOA service components reduce process and data redundancies, streamline the control of component processes, and eliminate problems related to keeping multiple versions of the same data synchronized.
Common service components also make it possible to design process, control and audit mechanisms into the suite that are consistent within and among components.
The following support features should be considered for inclusion in an SOA architecture and for tight integration with insurance processing components:
- Enterprise Configuration
- Financials
- Party
- Documents
- Notepad
- Distribution Services
- Workflow
- Business Rules
- Business Intelligence
In upcoming posts we’ll review of each of these functional areas to understand their power and how they enable a company to manage their processing in compliance with regulatory requirements.