Bpost - ARS/PRS

July 2005 - August 2006
Content:  
       

Management Summary

The purpose was to develop a platform of Web Services, which were to consistently represent and manipulate master data of customers and contracts, as well as a Web Application using these services. In addition to these data services, a number of business capabilities (such as for example a bulk solvency check) were exposed to the Bpost application landscape as well. Since at any given time during the project, there were at least 20 consumer application utilizing the services, the design of a governance model and deprecation strategy for these services was an additional requirement.

Team Composition

IT Sponsor: Peter Waterschoot
Project Manager: Dirk Meersseman
Architects: Bart De Cock, Peter De Kinder
Functional Analysts: 3 analysts
Developers: Gerard Gilsoul, Bert Walschap, 4 additional developers
DB Administrator: Thierry Brouwers

Novelty Items

Since so many consumers of the web services were dispersed across the application landscape of Bpost, it became no trivial matter to deploy a new version of a web service, prompting the need for development in each of these consumers. At first, consumer classes would be provided by the ARS/PRS team as a library to be included in all consumers. However, as time progressed, the decision was made to start deploying different versions of the services next to each other, indicating their version in the namespace utilized. A governance approach was formulated that all services would have up to their 3 last versions in place, meaning the current version as well as the two previous ones, each of these having code in them to enrich or transform the message calls and returns to fit with the contract of the current version.

Lessons Learned

Having had a lot of issues with backwards compatibility, which prompted the need for a deprecation strategy, a decision was made at a certain point in the project to switch all services from an RPC/literal binding to a Document/Literal binding. The loss of strict validation of the service calls was accepted in light of a more flexible service contract in order to increase the time-to-market of the new versions.

Another recurring issue was that of data quality. When a customer is added multiple times in the database (for example through different channels such as Bank van de Post and as a residential customer), this needs to be cleaned up to have a proper 360° view of customers. To resolve this, a merging functionality was introduced, which would merge two existing customers into a single one, keeping intact the historical data of both, as well as the unique identifiers linked to these customers (through rerouting algorithms in the service operations) in order to guarantee the business continuity of the consuming applications.

Project SOA EIM Public Sector