SAS e-service development projects and generality - Google Sites

E-service and generality (SAM SAS 5.0)

November 23, 2010

SAS e-service development projects and generality Author(s): Eva Söderström, Jesper Holgersson Date: November 23, 2010 Project: SamMET (SAM SAS 5.0) Status: Public

E-service and generality (SAM SAS 5.0)

Table of Contents Introduction Document scope Methodology EBMS-related development projects Problem description Project developments Project requirements Reasons for lack of generality Lessons learned

November 23, 2010

E-service and generality (SAM SAS 5.0)

November 23, 2010

Introduction Document scope This report documents the findings from the SAMMET SAS case concerning the EBMS-associated development projects, their relation to the e-service, along with an analysis of generality issues. The results are presented in textual form. Note that the terms e-service and web service will be used synonymously throughout the report.

Methodology The project overview and generality issues were studied using interviews with the SAS project participants. The primary sources for the projects, their contents and relation to one another are en program manager, en senior architect, and one project manager. For generality issues, an additional three interviews were used, all from one of the development projects.

EBMS-related development projects The following development projects have a stake in and a relation to the EBMS e-service: -

Taxfree shopping at the airport: The plan is to enable SAS customers to pay with EuroBonus points when they shop at the airport. o

-

EB webshop: Contains the same kind of idea as the taxfree shopping project. They have purchased a standard product like a webshop, where different products can be bought using points or a combination of points and cash. Parts of this development has been ordered already, and this project is the most advanced. o

-

Status: Partially implemented and partly closed. EB prognoses och montly prognosis are not published, but no new booking platform has been developed. Seat prognosis was cancelled after going live with Amadeus.

Value-based redemption: Selling trips, but with the difference that it in the airline business varies what availability different seating classes have. Customers can buy seats for points, and check how many points a certain seat would cost. This is the new way of selling airline seats in the EuroBonus area. o

-

Status: Implemented and closed

New Internet Award booking: A new booking application for the EB trip. This feature is available today, but its solution is not modern and not user-friendly. o

-

Status: Cancelled.

Status: Ongoing. Phase 1 is live now.

SAS Internet portal upgrade: There are semi-personalised pages in the booking feature, with points about to expire and so on. The project concerns updating the member pages and present the information in a different way, expose new information compared to today, and use the web service instead of the current solution. The latest purchases should also be visible.

E-service and generality (SAM SAS 5.0) o -

November 23, 2010

Status: Ongoing. There has been one sub-delivery, the main delivery is in November 2010

EB points display: A small project concerning displaying how many points that may be gained from booking a common trip. This project is also advanced. The development probably won’t need to be ordered, but volumes must be reviewed first. o

Status: Implemented

The taxfree shopping project is directed towards partners while the others are customer focused.

Problem description Project developments When the e-service was developed, it was to be designed for airline and hotel at the same time, but the former was cancelled. This concerned the new EuroBonus dialogue. At the same time, a new distribution platform project was initiated, which made it unnecessary to complete the airline part. Therefore, the requirements for this project remained incomplete. The requirements that existed were those for the hotel part. One general requirement was to make the e-service as general as possible based on the requirements that existed. The EuroBonus dialogue chose to call the hotel application. A seating prognosis was built into the EuroBonus dialogue to be able to review a large period at once and multiple destinations at once. The seating prognosis was the main result. Since then, the webshop was initiated. In the revenue part, an accrual has been made to gain points. The functions have existed before, but were built into the Internet Booking Platform, which calls the EBMS system (an AS400) via an MQSeries. The functionality is built-in, and the calls from EuroBonus management system (EMBS-PTS) are relatively generic. The functionalities you build on can be used for other calls, but there is a lot of functionality built-in to the AS400, and additions are needed in that to receive web services calls. Even if the EBMS-PTS is generic, the back-bone system is not, which affects what you can do. Project requirements Current projects are reviewed per project, more or less, and therefore have insufficient knowledge about the requirements placed on an e-service by the other projects. There are coordination attempts, but there is also still a need to explore how existing requirements documentation is structured. The user requirements are still defined per project. The e-service interface is considered in relation to the e-service, but have different processes for the end-user requirements. The interface between technical and user requirements need to be reviewed in the future, but is not of present priority. The user guide provided to the supplier/developer who is to call the service is fairly technical, which it has to be. Each web service is documented with input and output, but need another way of packaging since hand-overs are not functioning properly today.

E-service and generality (SAM SAS 5.0)

November 23, 2010

Reasons for lack of generality The simple explanation is that if you ask a specific project to develop a generic solution, it is very difficult for them to raise the perspective to what is generic from what is project specific. They developed what they needed. It should have been made a project of its own. The following list is a summary of reasons for why the EBMS-PTS e-service was not as general as originally intended: -

-

-

-

-

-

-

The calling system is a web service that assumes a customer who is known or logged in, which does not account for the cash registry in the taxfree shopping case. Parameters have been built into the functions for EuroBonus management system for hotel which are not applicable for the Heinemann or Webshop functions. Number of rooms is an obligatory information to provide, but not relevant for a webshop Requirements from the other projects have not been considered, leading to lack of functionality. o For example, Heineman’s cash registry components may require a cash registry identifier, which is currently not available. o For example, all cash registry bookings should not be shown under ”view my bookings”, but only those relevant for the specific customer. Changes have been ordered. There is a risk that the hotel function stops working if the EBMS-PTS is changed. There were functions developed used by Hotel, and if you change these functions, Hotel must change its calls. Instead, new general functions/methods need to be developed, and existing ones remain. Version management of a web service – how long should an old version be supported when a new one is being developed? It is one thing with internal services, and another with external ones. There are integration contracts, but the template is the same as for every other system. It should work, but not for example if services are built into other systems. In the process, requirements are stated that existing services – if there are any – should have their own SAD documenting them specifically. There is yet to be a web service registry containing and describing all major available services and SAS applications in maintenance. This is not currently used in the projects, which may be a problem and result in reinventing the wheel. There is therefore a risk to re-invent the wheel. There is a product catalogue used by Maintenance called CentraCite, where the services and applications are registered in an application. CentraCite is not used in the projects, and it should be common to all. Web service development takes place on a current needs basis, not from long-term considerations Points calculation from price to points should take place in the EBMS. This assumes that EBMS has a product registry or integrates against one. That is true in the hotel case, but not for the webshop or Heineman Add/replace points must always take place in a flow: first get price, then deduct points. There was a flow of several methods built into the web service, which meant restrictions in situations where that flow was not needed. It suited the Hotel flow, but not all the others.

E-service and generality (SAM SAS 5.0) -

November 23, 2010

The key concept for each transaction is not always a booking number as for flights and hotels, but can be a receipt number Award type is different between hotel and other point purchases Backbone systems, EBMS, is not flexible and is built on old technology which is not serviceoriented, which makes it difficult to build a general service layer on top of it

Lessons learned The following key points are lessons learned from the problem of lack of generality: • •

•

• • •

•

For a general problem, have a general project Keep in mind that there is a dependency with the backbone system and its limitations to the e-service. Do not have too high expectations of generality, since it is based on systems that are limited in for example functionality. SAS’ expectations were slightly too high. The decision was made too quickly that others also were to use a general web service. There were no documentation of general use cases, and the maintenance aspect was forgotten. They were a little too enthusiastic. Despite planning, there will be unexpected situations that will be hard to manage, and which can affect generality. For example method changes you did not expect to need change. Management speak of the general service that everyone should use, and expectations easily arise without being based on solid information. Develop a user guide to hand to non-technical staff those. A general service that had a technical user guide was too difficult for them to understand what it meant, which contributed to raising wrongful expectations. Spread register tools across both development and maintenance, and within all of SAS Group IT to make sure everyone has the same expectations.