XTech 2005: XML, the Web and beyond.

RSS for E-Business Data Interchange

Discuss this paper on the XTech wiki
View XML source for this paper

Keywords

Abstract

The literature on RSS commonly points out that RSS is not just for news. This case study examines how RSS has proved a useful technology for allowing data interchange in the world of e-Business.

Many organisations wish to exchange XML business documents over the Internet. The UK Life Assurance Industry is one such community. Trading partners are life assurance companies and financial advisers who sell life assurance products to the public. Adviser organisations vary in size from single person companies to organisations employing hundreds of people. Similarly the sophistication of the technical infrastructure available to advisers also varies widely.

This poses a considerable challenge. Advisers do not normally have problems sending documents to assurance companies, as the assurance company invariably has a permanent Internet presence. If responses from assurance companies are immediate, then again there is no problem. However, if responses are asynchronous, or the assurance company wishes to initiate information interchange, it cannot rely on the trading partner having a permanent Internet connection.

This problem can be simply overcome if the assurance company publishes documents to its extranet, and uses RSS to indicate what it has published and where. The adviser organisation can then check for new documents at regular intervals. This paper looks at an example of such use of RSS.

Unequal Trading Partners

It is one of the classic problems of e-Business (which I will take to mean data interchange between contractually related organisations, in support of well defined inter-organisational processes, such as the buying and selling of goods) that not all trading partners are created equal. From the 1960s, we have seen large organisations, such as multinational companies and academic libraries, exchanging more and more information in machine readable form. The growth in uptake of EDI (Electronic Data Interchange) from the late 1960's, fed hopes of completely paperless business transactions, and fine tuned supply chain control.

Inconveniently for this vision, large organisations almost invariably depend on relationships with smaller organisations. For our purposes this group has one defining characteristic: its members traditionally lack the resources or motivation to communicate electronically. Whilst relationships with organisations in this group might not seem to matter when considered in isolation, a large organisation may have hundreds if not thousands of such trading relationships to manage. Collectively these can be both important and expensive to maintain.

The challenge is to make e-Business cheap and simple enough for small organisations to justify the cost and effort of implementation. Where a large organisation purchases good and services from a small trading partner, the more dominant party has sometimes been willing either to persuade their smaller trading partners to implement e-Business systems, and/or to bear some of the cost themselves. The latter approach might involve subsidising the cost of EDI software and message mappings, or, increasingly, developing simple Web based interfaces to order processing systems.

These approaches work best if the less technically capable trading partner has to deal with only one partner via e-Business. Unfortunately it is not unusual for smaller organisations to have several larger trading partners. They might end up coping with different EDI solutions, or Web based interfaces, or a mix. Thus e-Business can become a burden, rather than a benefit to a significant group of trading partners. For e-Business to be genuinely successful it must be seen to benefit whole trading communities, rather than just their more powerful members. We will examine these themes in more detail by considering the experiences of the UK Life Assurance Industry.

The UK Life Assurance Industry

The UK Life Assurance Industry follows the pattern of relatively large organisations, the assurance companies, relying on business transactions with smaller trading partners, the financial advisers. The large assurance companies are traditionally more enthusiastic about e-Business than their smaller trading partners. The relationship between trading partners is made interesting by the fact that the smaller trading partners act as retailers of services (life assurance products) supplied by the larger. Most life assurance companies in the UK sell a proportion of their product through financial advisers not employed by themselves. Financial advisers organisations can be very small, independent companies with one or more adviser; they can be "co-operatives", or networks of thousands of very small companies that group together to share marketing and infrastructure costs; or they may be larger companies with hundreds of advisers. There are around 30,000 registered financial advisers in the UK, mostly working for fairly small organisations (less than 100 individuals), selling the products of twenty or so assurance companies.

Unlike traditional retailing, where the retailer buys products from a supplier, which they sell on at a higher price, the financial adviser is paid a sum of money by the assurance company for each assurance policy sold to a customer (commission). So the assurance company buys the service of "selling life assurance product" from the financial adviser.

e-Business in the UK Life Assurance Industry

Life assurance companies have hankered after the benefits of e-Business for a number of years now. Origo Services, a non-profit making organisation funded by a group of UK assurance companies, oversees the development of e-Business standards in the industry. Origo focuses on the transactions between the assurance company and the financial adviser.

Information Flow in the Industry: Adviser to Assurance Company

So far the most fully supported processes revolve around the generation of price quotations for assurance policies, and any subsequent order placed by a financial adviser on behalf of a client. Standards for data exchange define XML documents used to request a quotation, supply a quotation and to submit an order. As work progressed, the industry came to appreciate that it was unreasonable to expect all financial advisers to invest the time and money necessary to build an XML messaging infrastructure to implement e-Business. Consequently a number of portals have developed to allow financial advisers to create requests for quotes, often via a Web interface, which are then broadcast to target assurance companies, and the resulting quotes aggregated.

The motivation for automating the quotation process came primarily from the assurance companies. The process traditionally relied on paper forms and/or telephone calls from advisers. Supplying a quotation was both time consuming and required considerable human intervention. However, assurance companies had mostly automated the process of actually generating the quotation itself, and could see both a cost saving and quicker turn round of new business if they could expose their quotation systems to advisers.

There are also clear business benefits for the adviser. A person is still required to assemble the information necessary to generate a request for quote, and to make decisions around the resulting quotations. However, the aggregating function of the portal allowed the same information to be used to collect multiple quotations in much less time than would previously have been the case. Furthermore, the use of an intermediary, such as a portal, to provide the messaging infrastructure significantly lowered the barriers to entry. A Web browser and internet connection were more-or-less all that was needed. For adviser organisations with more sophisticated infrastructure, the portals have enabled automatic population of requests for quotes directly from back-office software. Consequently the e-Business quotation process has, by and large, been successful. A technical solution was found that the entire trading community could live with, and, just as importantly, everyone gained clear business benefits.

As the first major, industry-wide, e-Business initiative, the quotation service has set a strong precedent for work on other processes. In the context of this case study, the important thing to note is that the quotation process begins with the submission of information by the adviser, to which the assurance company responds with information. The submission of an order for an assurance product is likewise initiated by the adviser. Consequently an Internet based, messaging infrastructure has developed that assumes that information exchange will be initiated by advisers.

Information Flow in the Industry: Assurance Company to Adviser

However, unsurprisingly, not all business processes are characterised by information exchange initiated by the adviser. Assurance companies have to pay advisers for the policies they sell on their behalf, so the industry equivalent of the invoice was also an obvious target for Origo standards. A standard for defining payments to advisers was established some years ago as part of a set of EDIFACT EDI messages. The invoice payment process (it isn't actually an invoice, but it is conceptually similar) is initiated by the assurance company. There were once EDIFACT message standards for the quotation and ordering processes too, but these have fallen out of use as assurance companies have moved to XML messaging over HTTP. However, the EDIFACT invoice is still alive and well, despite there being an XML equivalent. This is at least partly explained by the high cost and complexity of implementing the infrastructure necessary to receive XML messages from trading partners, relative to the cost and simplicity of setting up an EDI mailbox and some fairly simple software to pick up incoming messages at regular intervals. Even organisations that have some IT infrastructure rarely have staff able to configure or modify their connectivity with the outside world. Instead they have to buy in skills every time they make a change. For many advisers even this is too expensive and complicated to justify, so invoicing is often still a paper based process.

The experience of invoicing has been typical for the implementation of processes that require information to flow from insurer to adviser. Most processes have remained paper or telephone based. Where adviser organisations do have the wherewithal to manage some kind of automation, implementations have been ad hoc, often involving the exchange of large files, perhaps of comma delimited data, by e-mail or CD-ROM.

Over the last few years attempts were made to build XML e-Business standards for other processes that naturally require information to flow from the assurance companies to the adviser. These typically cover the provision of information about existing assurance policies, to help advisers to manage their client base and income stream. Thus far such projects have attempted to bolt onto the existing infrastructure, which assumes an information flow from the adviser to the assurance company, and reflect existing ad hoc, bulk data exchange practices.

The differences between the business processes of assurance companies and advisers have also caused problems. Insurers have developed complex and subtle structures for assurance products over the years. They have developed business systems to manage this complexity.

Advisers on the other hand have a fairly straightforward view of the world, centred less on the low level management of assurance products, and more on managing clients and the income streams generated from selling them products. Just as a retailer of Hi-Fi products only requires a high level understanding of the electronics inside the boxes they sell, that focuses more on the what rather than the how, so it is with the financial adviser and life assurance products.

Proposal Tracking

We will now take a more detailed look at a set of related processes that require information to flow from the assurance company to support adviser business processes.

What is Proposal Tracking

A proposal is either a whole or a subdivision of an application for some life assurance product. An order for an assurance product (commonly known as an application) becomes a proposal at the point when an assurance company gets started on processing the application. The insurer feeds proposals through their systems using the information provided by the adviser about the client, to determine whether or not they will accept the business as proposed, modify the terms as a result of further information (such as a medical report), or refuse the proposal all together. Processing is managed by workflow systems, with direct human intervention kept to a minimum.

Clearly advisers may need information about the progress of proposals as they move through an assurance company's workflow systems. Specifically:

In an ideal world the assurance company would simply inform the adviser every time something interesting happens to one of their proposals. Even existing manual systems don't manage the ideal state. They rely on a mixture of telephone calls from advisers asking for updates, and standard letters of notification from assurance companies. As mentioned above, some assurance companies do provide data in bulk to some adviser organisations, usually at an agreed interval. Also some assurance companies offer some tracking information over their extranets, largely in an effort to cut down the number of telephone calls they receive from advisers. Clearly there is a case for developing a standard set of communications, delivered in a consist manner. This should increase the value of information exchanged and lower costs. Below we will look in more detail at a proposal for the technical implementation of Proposal Tracking standards currently under development. I will point out now that this discussion ignores issues such as security and identification, in order to concentrate on the main topic of the paper.

Technical Implementation

Given that almost all adviser organisations lack the infrastructure necessary to receive XML messages directly from assurance companies over HTTP, an XML messaging service akin to that implemented for quotes, is not a practical solution for Proposal Tracking, no matter how appealing. The messaging infrastructure of the industry is geared to a flow from the adviser to the assurance company, with the adviser initiating data exchange. In this case there is little sense in the adviser initiating the exchange, as the adviser cannot know when noteworthy events occur.

However, some assurance companies can publish Proposal Tracking information to their extranets, and almost all advisers are able to access assurance company extranets. This solution is still far from ideal: the adviser has to speculate that they don't already have up-to-date information, which is time consuming; tracking information available may be limited, and not standardised in scope; furthermore it cannot easily be imported into advisers' back-office systems. However, one doesn't have to look far on the Web to see how such a service could be made more accessible to the end user.

It is tempting to think of a standardised Proposal Tracking system in terms of online news services. As advisers have to come and get information from assurance companies, they need to know when it is worth checking for up-to-date information. It therefore makes sense to set up a regular publication cycle. Advisers then need a convenient way to see what has changed since they last looked, so they need one or more news channels dedicated to information relevant to them.

Enter RSS?

The idea of implementing Proposal Tracking services over RSS

Mark Pilgrim's article on XML.com is a good place to go to for more information on RSS.

follows quite naturally, and is one of several approaches investigated by Origo. RSS is a name that encompasses a number of rival XML mark-ups all used for content syndication. Rather than enter a discussion about which particular RSS markup is best suited to the task, I have made an arbitrary choice to use RSS 1.0 for illustrative purposes in this paper. The actual implementation of Proposal Tracking based on Origo XML document standards has hardly yet begun, and is currently based on existing, RSS-like Origo standards. So this paper reflects something of an idealised, future realisation of Proposal Tracking.

The typical extranet service allows advisers to see the details and current state their proposals have reached in an assurance company's workflow. This pretty much duplicates equivalent telephone services. So we might end up with the following:

An RSS feed consists of one or more channels, with each channel representing a particular subject area. It seems most natural to define one channel for each adviser whose proposals are to be reported. However, the exact coverage of each channel must be determined by the assurance company and its trading partners. Here, for the sake of simplicity, we assume that one adviser gets one channel. The adviser is identified here by the code 1011.

	<channel rdf:about="http://acme.assurance.co.uk/proposaltracking/advisers/1011">

Next we give the channel a title, a description and provide the link to the HTML site to which it corresponds:

	<title>Proposal Tracking: Proposal Status</title>
	<link>http://acme.assurance.co.uk/proposaltracking/advisors/1011</link>
	<description>Acme Assurance Company proposal tracking service for registered advisers</description>

RSS 1.0 is modular in design, so we can now start importing the modules we need to make the service more useful. The mod_dublincore module allows us to add some metadata about the creator of the channel. Importantly, the adviser is told the name of the assurance company, the date and time at which the channel was published, and the fact that the RSS feed is about machine processable data.

	<dc:publisher>Acme Assurance Company</dc:publisher>
	<dc:creator>Acme Assurance Company</dc:creator>
	<dc:date>2004-03-18T20:00+00:00</dc:date>
	<dc:type>Dataset</dc:type>

We import the mod_syndication module, in order to tell the adviser the update period for the channel, the frequency with which the channel is updated within that period, and the base time and date from which the period and frequency can be calculated. Knowing when information will be updated offers a crucial advantage over the plain extranet service. The adviser can automate the process of checking for changes.

	<sy:updatePeriod>daily</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<sy:updateBase>2000-01-01T20:00+00:00</sy:updateBase>

We now have defined our RSS channel, and need to insert some news items. In a conventional news feed, items tend to consist of a headline and short description on the news story, with a link pointing to the location of the full story. For Proposal Tracking each proposal that has undergone a state change is a headline, and its current state is the brief description.

RSS 1.0, defines items as RDF resources. They sit outside the markup of the channel to which they belong, while the channel itself contains the RDF resource names of each of its items. So we might have an item, thus:

	<item rdf:about="http://acme.assurance.co.uk/proposal.tracking/advisors/1011/proposals/P1235">
          <title>Proposal P1235 Status</title>
	  <description>Proposal P1235 is an application by Mr & Mrs Rabbit for an Acme Assurance Company Home Protection plan. 
	  Proposal P1235 has a status of offered standard, reached at 2004-03-18.</description>
	  <link>http://acme.assurance.co.uk/proposaltracking/advisors/1011/proposals/P1235/P1235.xml</link>
	  <date>2004-03-18T20:00+00:00</date>
	  <dc:subject>P1235</dc:subject>
	  <dc:subject>Proposal Status</dc:subject>
	</item>

The item element has an rdf:about attribute, the value of which is the name of the resource represented by the item. In this case the item represents information about a proposal with a reference of P1235. The title and description elements provide human readable information about P1235. This is as far as the extranet service that we are replacing would have gone in this case. However, the RSS item provides a link to an Origo defined XML document, which contains the following elements:

	<proposal_reference>P1235</proposal_reference>
	<proposal_status reached_at="20040318">Offered Standard</proposal_status>

This duplicates the key parts of the human readable text, but in a form that is easily machine processable. We now have a service that is consumable by software as easily as by a human. Actually, if we combine the RSS and XML with CSS and a tiny amount of XHTML, the news feed can double as the human and machine processable view of a Proposal Tracking service. For example, the RSS described above is rendered like this in Firefox when combined with suitable CSS:

Advantages for the Adviser

More importantly, an adviser can now use a simple RSS feed reader to display up-to-date proposal status information. For example, in Thunderbird our example looks like this:

Admittedly an adviser might have to register a dozen or more feeds to see information for all their proposals, however that is less time consuming than having to visit the same number of web sites every day. Furthermore, it is very likely that portals will act as feed aggregators, in which case a subscribing adviser will be able to look at just the one super-feed to meet all their tracking needs.

Larger adviser organisations, with more sophisticated back-office-software systems may not want each of their advisers to set up their own RSS feed readers to track their proposals. Instead they can build additional functionality over a set of RSS feeds, for example, to pump status information directly into their own workflow systems. This might allow an organisation to set up rules to monitor how long proposals spend in particular states (such as when a proposal is being underwritten), and only alert advisers if things seem to be taking too long. Thus the adviser is still assisted by the RSS feeds, but uses them indirectly.

Extending Proposal Tracking

Proposal status information is not actually all that useful on its own. Fortunately there is no reason why RSS cannot support the extension of basic Proposal Tracking to encompass a broader range of information services, without impacting those already implemented. The most obvious extension is for assurance companies to inform advisers when they have requested information from third parties, such as doctors, in the course of processing their proposals. Adviser information needs centre on managing clients, and the income streams generated from selling them insurance products. They are interested in the specific characteristics of assurance products that relate most closely to these needs.

There are several ways to add to the basic service we have already looked at. An obvious approach is to simply add new items to the existing channel, one representing each of the additional information items. So our example ends up looking something like this:

	<item rdf:about="http://acme.assurance.co.uk/proposal.tracking/advisors/1011/proposals/P1235/waiting/">
          <title>Proposal P1235 Waiting for additional information</title>
	  <description>We are waiting for a Declaration Notice from Mr & Mrs Rabbit. 
	  Date requested: 18/03/04. We will chase if not received by: 08/04/04.</description>
	  <link>http://localhost/proposal.tracking/advisors/1011/proposals/P1235/waiting/P1235_waiting_20040318.xml</link>
	  <date>2004-03-18T20:00+00:00</date>
	  <dc:subject>P1235</dc:subject>
	  <dc:subject>Proposal Additional Information</dc:subject>
	</item>
	
	<item rdf:about="http://acme.assurance.co.uk/proposal.tracking/advisors/1011/proposals/P1235/status/">
          <title>Proposal P1235 Status</title>
	  <description>Proposal status is of Offered Standard, reached on 18/03/04.</description>
	  <link>http://localhost/proposal.tracking/advisors/1011/proposals/P1235/status/P1235_status_20040318.xml</link>
	  <date>2004-03-18T20:00+00:00</date>
	  <dc:subject>P1235</dc:subject>
	  <dc:subject>Proposal Status</dc:subject>
	</item>
	
	<item rdf:about="http://acme.assurance.co.uk/proposal.tracking/advisors/1011/proposals/P1235/proposal.data/">
	  <title>Proposal P1235 Key Details</title>
	  <description>Details of the proposal as held by the Acme Assurance Company.</description>	    
	  <link>http://localhost/proposal.tracking/advisors/1011/proposals/P1235/proposal.data/P1235_proposal_20040318.xml</link>
	  <date>2004-03-18T20:00+00:00</date>
	  <dc:subject>P1235</dc:subject>
	  <dc:subject>Proposal Details</dc:subject>
	</item>

In this example adviser payment information is not provided, but could easily be added in the future.

Some adviser organisations may have several thousand proposals from several assurance companies being processed at any one time. Consequently some RSS feeds channels might become rather large, especially if aggregated. In these cases the adviser organisation will most likely use their back-office software to process the feeds, especially as the information is not really intended for direct human consumption.

If a single large channel is inconvenient, there are other ways to slice the RSS. For example, each new information service could be implemented as a separate channel. This might seem a bit tidier, but it does require each adviser to subscribe to four or five feeds per assurance company, and advisers would miss new information services if they failed to subscribe. On the other hand, this approach makes it simple for advisers to ignore information in which they are not interested.

An assurance company could maintain an RSS channel that tells advisers what Proposal Tracking services they have available. The idea of an RSS feed that describes other RSS feeds is very appealing. An assurance company could, for example, maintain a channel that simply reports which proposals are "in the news". Each item in this channel could point to another RSS channel that describes in more depth all the "news items" for its particular proposal.

As well as RSS feeds within RSS feeds, assurance companies could provide complementary feeds that simply rearrange the same information services into different, convenient packages. It is important to note that the underlying resources described by the RSS would remain the same in each case. RSS channels simply provide alternative logical views of the same things. In this way assurance companies can offer different flavours of the same information services relatively easily. For example an assurance company might be asked to provide a single feed for a group of advisers represented by a portal.

Implementation of Proposal Tracking Services

A set of relatively simple information services are combined, via RSS, to create a Proposal Tracking system. The model described above allows assurance companies considerable latitude in how they implement these services. This is useful, as there is a certain amount of variation in what assurance companies plan to do. The two major variations are set out below.

Proposal Tracking over Real-Time Services

Some companies have built, or will build, real-time services to provide the current state of any proposal information requested. Adviser organisations with the appropriate technical infrastructure could access these services directly to retrieve proposal tracking information. However, building RSS channels over defined invocations of these services, makes the services available to all advisers. Amazon.com take this approach. It publishes RSS feeds derived from calls to its own public web services. So you can discover the top ranking sales items for various categories either by making a call to a Web Service, or simply by subscribing to an RSS feed. This approach also allows assurance companies to control direct calls to the underlying services. Alternatively, or indeed, additionally, the RSS feed might link a channel item directly to the appropriate information service, so providing the current state of the proposal. Either way, the assurance company has a very simple, and controlled method of exposing real-time information services to the adviser community.

Proposal Tracking over a Snapshot

Other assurance companies will build a nightly snapshot of all proposals that have changed over a given period, and just publish XML documents derived from it. Consequently RSS channel items will always point at real, published resources, which will become increasingly out-of-date over time.

Advantages for the Assurance Company

Apart from supporting different implementation styles for the constituent information services of Proposal Tracking, the use of RSS as the delivery mechanism also allows companies to phase delivery of a full service with minimal impact to themselves or their trading partners.

Perhaps most important for the assurance company, RSS offers a credible alternative to an expensive telephone based Proposal Tracking service. A set of RSS feeds will provide an adviser with up-to-date information at least once a day, and potentially tells them a lot more than a telephone based service ever could. Of course, it is also possible to render an RSS feed verbally, which leads to the intriguing possibility of offering at least part of the RSS based service as the telephone service it was originally intended to replace. Similarly assurance companies might build simple Proposal Tracking services via e-mail, or SMS messaging, all based on the RSS news feeds that are the heart of service delivery.

Advantages for the Adviser

A set of RSS feeds providing Proposal Tracking information seems a clear win from the adviser view point. A single implementation serves one person with a PC and dial-up Internet connection just as well as a larger organisation with relatively sophisticated back-office software. The adviser can automate information retrieval and is only told about proposals for which there is news. Furthermore, as assurance companies enhance their offering, advisers will be able to take advantage as much or as little as they like, without the need for expensive changes to their own systems.

Conclusions

The main aims of an RSS based Proposal Tracking system are:

The fact that RSS based information services are accessible via widely available user agents, such as Web browsers and RSS feed readers, as well as via more sophisticated back-office systems (ultimately), should help to meet the first aim. The regular publication by assurance companies of lists of news items relating to proposals neatly overcomes the inability of adviser organisations to receive XML messages directly. A standard publication mechanism makes life easier for aggregators in the image of O'Reilly's Meerkat service, for example. Providers of back-office software can draw upon the considerable experience already available when they come to implement support for RSS based Proposal Tracking services.

The second objective is less reliant on the delivery mechanism, but at the very least RSS does not preclude the development of useful services. Creative use of RSS channels will allow assurance companies to offer several different, but useful logical views of the information they publish. Lastly, once in place RSS can be used by assurance companies to deliver other information services, including more conventional news services.

Some Observations

As mentioned above, development of a standard for Proposal Tracking is still far from over. It is worth ending with some observations from the Proposal Tracking project. Most automated information exchange from insurer to adviser has been managed by ad hoc arrangements. Assurance companies tend to run batch processes to assemble data into large files for transfer to the larger adviser organisations. This legacy experience has probably influenced opinion as to how Proposal Tracking should be implemented rather more than lessons learned from existing, comparable, Web based information services.

Consequently discussions have tended to revolve around the standardised provision of a "bulk" service, as something quite distinct from a service to provide information about single proposals. This implies the requirement to implement two, complementary Proposal Tracking services. Interestingly, organisations with more experience of deploying service based applications have been quick to recognise that rather than requiring multiple services, there are just several different ways of either using or packaging just the one one service: in this case either to collect information about all proposals, or to collect information about a single proposal.

Bibliography

[] Content Syndication with RSS, Hammersley, Ben, O'Reilly
2003

Biography

Mark Seaborne

Standards Architect, Origo Services Ltd http://www.origoservices.com

Mark has been working with XML since 1998. He currently works on b-to-b, XML message standards for use in UK Life Assurance Industry. He represents the industry as a member of the W3C XForms WG.