Introduction

PremiumBill’s technical design was not driven by specific technologies, but it does reflect decisions made in response to both business and technological trends. We noted the following trends that that are leading towards increased complexity of business software:

§         More data is being captured and processed than ever before.

§         Software is being relied upon to make more business decisions than ever before.

§         A greater number of software systems are interconnected in support of processing the business

On the technology front, we factored in the advantages of Web Services, XML, and browser-based interfaces using a Service-Oriented Architecture (SOA) model. SOA focuses on business-level processing, with a service is defined as software that is providing a specific, related set of business functions and operating as an independent entity.

A key advantage to SOA-compliant systems is that they are loosely coupled to other systems. By using well-defined, business-level interfaces – without application calls being embedded directly into other applications – SOA systems can be updated or even replaced – easier than other systems. The loose coupling places PremiumBill (designed as a software service) in an excellent position for continual product advancement with minimal impact to other applications in the enterprise.

PremiumBill Design Goals

As we set out to design and build PremiumBill, we arrived at the following high-level goals:

• Any new solution must be the best of breed, comprising a rich set of features to meet the business needs of insurance carriers.
• The solution must be designed for integration, reducing the time and effort required to implement the system no matter what other systems a customer may have in place.
• A browser-based interface should be utilized for any out-of-the-box interfaces, making the solution fast and easy to deploy.
• The solution must support industry standards and be responsive and adaptable to continual technological and business changes.
• Users must be assured that their data and business processes are secure and confidential. Security must be an integral part of the solution, not an after-thought.
• Patterns and best practices must guide the architecture and its implementation.

PremiumBill Architecture

AMS Services’ PremiumBill solution is built around a layered architecture. Each layer has clearly defined roles, responsibilities and relationships. These in turn define an application that performs a well-defined job and performs work based upon an “interface contract”. One characteristic of a service-oriented application is that it stresses interoperability, generally by exposing methods via standard interfaces such as Web Services. PremiumBill employs multiple services that are communicating with one another to perform particular tasks that comprise a business process.

The following diagram illustrates the key components of the PremiumBill architecture:

PremiumBill Architecture

Web Services

The web services published by PremiumBill provide the only entry points into the billing application. They have two roles.

1. They define the interface contracts through which billing services are accessed.
2. They serve as gatekeepers, cooperating with the Security layer to determine if a user is authenticated, (known to the system) and authorized (permitted to access a part or the whole of the system).

Built from the ground up to support Internet standards (XML, SOAP, WSDL), PremiumBill web services are platform agnostic, providing an open integration path to more readily meet the demands of your business.

User Interface

The architecture diagram indicates that the User Interface layer is an ASP.NET application, accessing PremiumBill functionality through exposed Web Services.  PremiumBill’s use of ASP.NET provides you with an out-of-the-box, browser-based user interface for all core processing.

A browser-based interface was chosen specifically to address the ease of deployment – software does not need to be installed on every desktop, eliminating a software distribution and management issue. 

Adapters

Application integration (inputs and outputs) make use of “adapters.”  Adapters serve two crucial roles in the overall architecture:

1. Adapters act as a middleware component.
2. Adapters act as extensibility mechanisms.

As a middleware component, adapters can bridge the gap between legacy systems that do not or can not natively communicate via Web Services.  Adapters can sit between PremiumBill and the application (such as a policy system), exchanging and formatting data between the policy system and PremiumBill.

As an extensibility mechanism, adapters can communicate to specific systems that work with PremiumBill.  For example, adapters can be designed and coded for various check writing solutions, printing solutions, etc. without requiring changes to PremiumBill.

Adapters themselves can take many forms. They can be partially embedded into other applications, acting when called directly by the application, or they can be more loosely-coupled, such as a file listener waiting for output to be generated before taking action.

Coordination Objects

The coordination objects are invoked from Web Services or internal PremiumBill services and drive the billing business processing.  There are objects for various categories of processing, such as payments and maintenance.  The coordination objects access the business rules and parameter objects and orchestrate work between the core business objects to perform billing transactions.           

Business Objects

Business objects comprise the lowest level of business processing. Each object in the system has a specific role and responsibility to operate on data items appropriate for that role. A typical billing transaction will need to use several different objects: some objects will represent the client or agency to be billed, there will be rules and parameter objects that provide processing instructions or values, objects that contain the items to be billed, etc.

Application Logic, Rules and Parameters

The ability for PremiumBill to function, as well as the ability to modify how PremiumBill behaves, is captured in application logic, business rules, and parameters as described in the following sections.

 Parameters

Parameters are named entities that define a feature or option of the system.  The value of a parameter may determine the run-time behavior of the system.  An example of a parameter is: "Round To Nearest Dollar." If this parameter is enabled, the system will always round currency amounts to the nearest whole dollar value.

Business Rules

Business rules are:

·         The mechanism used to decouple the “way we do business” from an application.

·         Invoked to provide a decision based on data and logic.  A business rule, through executing decision logic and (optionally) examining data values during that execution will:

a) Determine if a data value should change, or

b) Determine the next business process path to execute.

·         Meant to enforce implementation-specific business procedures on how a system operates; however, business rules are bound by the initial design and scope of the system.

·         Describe an enterprise's way of doing business.

·         Domain specific.

·         Written statements that specify what a system must do to support the needs of a specific business.

An example of a business rule: The person managing a territory gets a commission on all sales within that territory.

Application Logic

Application logic encompasses the entire implementation of a complete business system.  Data access, security, system configuration, business logic (hard-coded or invoked via a business rules engine), exposed application services, the user interface, everything that defines a complete system is contained within Application Logic. 

Persistence Layer

The persistence layer sits below the business objects and business object to a database.  Its primary advantage is that the database is abstracted from the business objects, allowing changes to be made to the database without having to re-compile code. It allows a developer to focus on the business objects and not on the mechanics of data storage.

Security

By implementing a configurable, adaptable, service-oriented architecture that exposes Web Services in a loosely-coupled design model, PremiumBill provides a great deal of advantage from an implementation and support standpoint.  However, this “designed for integration” approach does raise the bar in terms of security.

Standard business security relating to user access to the system (authentication and authorization), business transaction are provided for in the security model for PremiumBill.  Additionally, since data is being transmitted in and out of PremiumBill via XML Web Services, the Web Services themselves must be secured so that unauthorized use of those services is prevented.  Security is embedded into the user interface and the SOAP headers that are part of the XML transaction so that the users are not inconvenienced with challenges to their identity for every transaction and the XML transaction supplies a correct security token.  This strikes a balance between security and usability.

Since data is transmitted over a network, and will contain sensitive information, PremiumBill can make use of standard encryption mechanisms such as Secure Sockets Layer (SSL) to provide additional protection of data. 

Summary

AMS Services has put considerable time and effort into designing PremiumBill so that is meets the total needs of our customers.  A strong emphasis and focus on the user requirements shaped the business functionality of PremiumBill.  Along with this, observations and studies of insurance carriers helped us to understand the pain points that needed to be factored into the design.  An assessment of emerging technology trends, use of design patterns and best practices provided the final ingredients to shape the overall system design and architecture.  The result is a next-generation system designed to meet the needs of the market today and in the future.