Introducing
the Centaur Case Study
Introduction
In this chapter, we will take a more detailed tour of the
Centaur system that is the subject of the application case study. By the end of
the chapter, you will:
q
understand something about the market that Centaur is
addressing
q
understand the aims of the system
q
understand some ways in which it differs from a
commercially viable system
q
know the basic structure and functions of the system
q
know where XML is used within the system
Capturing Requirements
Some years ago, I heard of a software house developing a
large and complex system for a customer. This was the biggest system they had
ever undertaken, and they delivered it to the specification, on time and on
budget. At the end of the year, they celebrated this as the best project they
had undertaken all year. And what happened to the system? The customer decided
that the system performance (which had been excluded from the specification to
save time in negotiations) was inadequate, threw it away and started again with
an in-house development team.
On another occasion, a joint venture was established to
develop a new industry-wide system. The project ran for a year, then there were
rumours of problems. The consortium comprised industry suppliers and the
developers of their technology, but the industry traditionally sold through
agents, and the agents had not been involved. When they were asked, the views
of the major agents ranged from indifference to the project to antipathy since
the system did not meet their needs, and would be more expensive and harder to
use than the supposedly outdated technology they already had.
Why do such projects fail? In nearly twenty years of running
development teams, I have never known a project to fail because of the
incompetence of the developers. Instead, they fail because of poor management,
poor requirements, or failure to involve all parties affected by the system.
Why am I telling you this? I have consulted various
interested parties while designing and developing Centaur, but since this is
not a book about project management or development methodologies, you will only
see the results in the product itself, not as documentation in this book. The
design method I used is typical of iterative rapid application development, but
too many people see this as an excuse not to collect proper requirements and
not to define their system. By all means keep your methodology light, but don’t
ignore it altogether. So I would like to make it clear, that although the case
study in this book lacks some features that would be needed in a full
commercial implementation, which I will indicate, it nonetheless fulfils a
defined set of initial requirements, as we shall see soon.
Background
The diagram below shows the traditional model for buying
vacations in the UK:
In recent years, this model has been changing, with tour
operators buying up travel agents and charter airlines to provide a vertically
integrated market. Up until now, these vertically integrated companies have
sold seats on their airlines to other tour operators, and provided shelf space
for their competitors’ brochures in their travel agencies.
Now the market is changing. Investigations by the UK
government and consumer organisations have shown that the major companies are
starting to use their power to push their own products through their agencies.
The smaller tour operators are starting to worry about their seat allocations
on the charter airlines. The 1998 survey
shown below indicated that twice as many agents think that independent tour
operators will be squeezed out by the major tour operator groups as think they
won’t.
The trend seems set to continue, to the point that the vertically
integrated travel agencies are likely to be re-branded under the tour operator
name and cease all pretence of being independent. This will divide the market
into two — the major tour operators with strong branding and a good high street
presence and the smaller, independent, tour operators selling through
independent travel agents.
At the same time, we have new distribution channels.
Although the complexity of travel products means it has taken some time, the
large tour operators are starting to sell through the Internet. Then the likes
of Microsoft Expedia (http://expedia.msn.com/daily/home/default.hts)
are expanding from the scheduled market to packaged vacations. Who will they be
talking to — the top few operators or Mom and Pop Tours? You guess. It goes on,
with portal sites seeing travel as a major market area.
Oh dear, who would be an independent tour operator? Then it
gets worse. In the diagram earlier, there is clearly an intermediary too many
in the loop. Why have both a tour operator and a travel agent in the supply
chain when selling through the Internet? While the tour operator can sell
direct, the independent agents could start putting bespoke tours together using
bookable sites available on the Internet. Currently, the commercial model,
where tour operators use their buying power to get good discounts, may make
this uncompetitive, but I would not want to base my future on this situation
lasting.
Once the top few tour operators are selling through the
Internet, what chance have the rest got of people even visiting their sites?
Unable to compete on advertising expenditure, they will be relying on word of
mouth for future business.
But wait! Isn’t the Internet meant to make it easy for the small guys to look as impressive as
the majors? Well, maybe on static sites, but providing facilities for booking
complex products is expensive, and anyway, why should someone visit a site only
covering vacations in Corfu when they can go to one covering the world?
Enter Centaur. Centaur works on a model where the tour
operator stays in the loop, and addresses the issues of cost and visibility by
operating with a wide range of tour operators. Whether the vacations are booked
directly by the public or through travel agents is a political question which I
can conveniently ignore for the sake of this demonstration system. Another
major part of the business model is that many of these tour operators are
specialists and so are not competing directly with each
other. While a Corfu specialist and a Caribbean specialist
may both be after the same traveler's wallet, they are likely to see the
benefit of co-operating as outweighing the disadvantages.
Let’s come back for a moment to the direct vs. travel agent
question. When we are talking about the Internet, aren’t we meant to be talking
about new paradigms? How about a "vacation café" on the model of the
Internet café? Or supermarkets building coffee lounges with terminals connected
to Centaur and a few experts around to help people book their vacations? Here I
am, making a couple of dollars from your buying this book (you did buy it, didn’t you?), and giving you
ideas for making millions. I hope you remember me in your will.
So Centaur allows many tour operators to share a single
system while maintaining their own branding. Centaur will cover vacations all
over the world for all seasons of the year. Because it will have so many
companies using it, it can afford to advertise and will be big enough to
compete with the major tour operators’ web-based systems. It will provide
integrated searching, allowing the traveler or agent to find the perfect
vacation, regardless of the tour operator, then book on-line. It will be
available from the home, and possibly through a new model for travel booking
through supermarkets, cafés, banks and wherever. Suddenly Mom and Pop are
competing on equal terms.
Centaur Description
|
This diagram shows how Centaur fits into the booking
environment to allow booking of tour operators.
|
|
In principle, the system can be used for either direct sales
or sales through agents. For direct sales, the system can be financed through a
booking fee taken from the revenue that would normally be paid to the agent as
commission. For sales through agents, it is less obvious where the funding
comes from. The only direct payment saved is the fee paid to the value added
networks that currently connect agents to tour operators. In practice, agents
may still want the security of such a network. So the revenue for Centaur has
to be generated by savings elsewhere or the ability to charge more to the
client.
In operation, Centaur collects brochure descriptions of
vacations from the tour operators and stores and indexes these. The traveler
then conducts a search of this database, and gets a list of vacations meeting
his or her needs. It is then possible to refine the search or get more
information on selected vacations. Searching is branded as Centaur, but
individual vacation descriptions carry the tour operator’s branding.
Once a vacation has been selected, Centaur collects
information about the number of travelers and opens a conversation with the
tour operator system to allow quotation, availability checking and booking. The
booking appears as "direct" with the tour operator, Centaur operating
as an intelligent gateway rather than a travel agent:
This diagram shows the opportunity for selling additional
services, either directly or by linking into other sites. These services would include
insurance, guides, maps and other travel accessories. These additional
services, along with advertising, would generate additional revenue for a
commercial system, but are not relevant to the use of XML and so will not be
included in the demonstration system.
The Aims of Centaur
Centaur is being developed for a variety of purposes.
Firstly, it is clear from the above that a system like this is needed in the
travel industry. The threat from major tour operators is to small companies,
and these are often so heads down that they do not address the threat, or they
are so unaware of what technology could do for them that they cannot see the
solution. As a demonstration system, Centaur is designed to increase awareness
of the possibilities for this group by showing them a real working prototype.
Secondly, it is being developed as a prototype for a
production system. Most systems users and purchasers cannot easily express what
they want until they see something different. In other words, it is easier to
say what is wrong with something you can see than it is to specify requirements
on a blank sheet of paper. Centaur provides the initial writing on the paper,
and, as such, is a system waiting to be shot down as "not what we
need".
As a consultant in XML, I spend time developing little
prototype systems to help people become aware of the possibilities of the
technology. With a new technology that many of those who could benefit have
never heard of, this is essential to business development. Centaur is such a system,
but on a bigger scale.
The fourth aim is a bit of a personal one. As a contributor
to the discussions within the United Nations on using XML as a mechanism for
electronic data interchange (EDI), I have come across people who are very good
at playing devil’s advocate. One point I have heard made is that it is
impossible to use XML as a trading language without being a Java programmer.
Some books on XML support this view by leaping straight into Java code even to
display information. If such programming is necessary, XML becomes unavailable
to web site developers and others who do not have a programming background, but
have become familiar with scripting languages. The aim of Centaur is to
demonstrate that powerful web-based applications can be developed in XML using
only standard scripting languages.
And the fifth aim is to provide a case study for this book.
These aims conflict to some degree. The requirement for the
book is to maximise the variety of ways in which XML is used, while minimising
any parts of the system that do not require XML. Hence the elimination of
payment mechanisms, which are complex, well catered for with existing products
and would contribute little to this book. I am also restricting myself to
scripting languages, which could result in a commercial system hitting
performance problems in some areas. Of course, this is one of the benefits of a
prototype — Centaur will indicate those areas where a commercial system needs
some performance enhancements.
Differences from a Commercial System
I have already said that the case study differs from a
commercial system by excluding a payment mechanism. There are other areas where
there is little benefit in implementing complex business logic when trying to
demonstrate the use of XML.
The first is in the direct sell versus travel agent model.
Requirements here are different. A travel agent would need to log in and be
recognised so that commission can be paid. The tour operator system itself
would track commissions due and make payments, so adding this functionality is
purely a matter of one or two additional screens and additional messages
between Centaur and the tour operator system.
Centaur will include a search capability as that is a key
part of the requirement. However, this can be kept simple, since complex
searches merely require more complex logic. For this reason, the range of
vacation types is also limited (for example, no account is taken of ferry
travel or multi-centre vacations). Most commercial travel systems on the
Internet use a keyword search mechanism. I would like to see this supplemented
with the sort of free format "I want to go somewhere hot near a golf
course in August" searches that are familiar to Microsoft Office users.
The other major area of complexity is when the user wants to
cancel or change a vacation booking. In practice, tour operators have different
ways of handling these events, and would almost certainly prefer to do this
over the phone rather than over the Internet so they can explain the
cancellation charges that will be applied and discuss whether insurance covers
these.
A commercial system would include not only vacations, but
also the travel ancillaries such as the insurance, guide books and maps that I
mentioned before. In the UK, tour operators insist that the traveler has
adequate insurance taken out at the time of booking. The user will therefore
either have to take out a policy through the tour operator, or provide details
of existing insurance. This would be an opportunity for the Centaur operator to
earn commission by linking through to a preferred insurance supplier.
And finally, remember the system is simplified. There are no
queuing mechanisms and no transactional controls — familiar areas of commercial
systems and well catered for with existing products. The aim is to expose the
XML, not teach you the details of complex transactional systems. Similarly,
there are no pretty graphics to get you into the vacation mood. Just one logo
and boring text and grey buttons as this simplifies the appearance of the
scripts, all of which are included in the downloadable files, and much of which
is discussed in more detail in later chapters. Doubtless you will spot some of
the other areas where there is a need for more error checking or other
enhancements.
Well actually, that wasn't "finally" at all. By
far the most important difference is that Centaur relies on the facilities of
Microsoft Internet Explorer version 5 — a browser that has only just been
released at the time of publication. This would probably limit the system to
less that 5% of its available market in the short term. Unfortunately, a real
commercial system at the moment would have much of the client-side XML stripped
out. It would be replaced by a combination of server-side processing (for
example where XSL is used to display vacation details) and more conventional
mechanisms in other areas.
Up until now, I have used the term Centaur for both the
demonstration and commercial systems. From here on, I am discussing the
demonstration system unless I need to point out how a commercial system would
differ.
So What Does Centaur Do?
I have already described Centaur as the middle tier of a
three tier system for booking package vacations. What is a three tier system?
It is usually described as a system that incorporates display logic in one
system (the browser), business logic in another (the middle tier) and database
services in a third tier (the server tier):
|
|
As was shown in the diagram earlier, Centaur uses a slightly
different model, combining business logic with a simple database in the middle
(Centaur) tier, and using existing tour operator systems, which include both
databases and business logic, as the server tier. There are two reasons for
this approach. The first is that a vendor-independent search is simpler,
quicker, more reliable and uses less network bandwidth if it is conducted on a
single server. It's simpler because all the information is held locally in a
consistent format, quicker and lower bandwidth because there is no need to
interrogate other servers. And it's also more reliable since everything is held
on a single server, which could have any degree of fault tolerance required,
rather than on multiple remote servers, the failure of any one of which, or the
network in between, would limit the value of the search.
The second reason is that, when we look at the functionality
of the tour operator systems, they generally do not have the facilities for
supplying vacation details. They tend to be old systems that manage only the
transactional elements. This is why most multi-vendor on-line booking systems
currently operating don't show any detailed information about the vacations.
Typically, the information found in the brochure is held in a variety of word
processor documents, spreadsheets and databases and only comes together at the
publisher. So for Centaur, we will have to collect this information once only
and hold it in the local database. This will ease implementation for the tour
operator at the expense of increasing the size and complexity of the Centaur
database.
So Centaur itself holds a database with information about
the tour operators, their vacation destinations and individual vacations. The
user can search for a vacation based on information about both the destination
and the hotels (or villas or whatever) there. In general, we will use the terms
"tour" and "vacation" and there is no reason why Centaur
should not be used for cruises and other sorts of vacation as well.
A Brief Tour of Centaur
The diagram that follows shows typical navigation round the
system. Of course, being an internet-based system, the user can go backwards
and forwards as he or she pleases:
Let's now walk through the process that the diagram
illustrates.
Welcome to Centaur!
When you log into the system (remember that you can build a
copy of Centaur on your own machine – see Appendix A) you should see this
screen:
As you can see, this welcome page tells you a little about
the system and this book. In a commercial venture, I would expect all pages to
make far more use of graphics (especially to get rid of those horrible grey
buttons, which are used all over the application simply because using something
better would not add anything to the XML aspects). This screen could also
include advertising and links to other travel-related products such as
insurance and books.
Finding and Displaying the Vacations
Suppose you click on the button to open a new brochure. This
will take you to the main search screen, from which you can select vacations
based on the type of vacation you want, where you want to go and the facilities
you would like either on site or close by. If you select some criteria and
submit the search, you will get one of three results. You could get no matches
at all, which is quite likely as there are only fifteen vacations in the system
database. You could get so many vacations that the search results would be confusing.
In this case, you will get a message and the opportunity to see the results
anyway or refine your search criteria. Of course, with fifteen vacations, this
is not going to be the case, so the limit of the number of vacations to display
before sending this message has been set artificially low at ten. You will get
this result if you do not set any criteria before searching, or if you search
for all Mediterranean vacations.
Of course, the result we want is a limited number of
vacations as shown here:
Clicking on either of the vacations listed in the left frame
will show its details in the right frame.
The information displayed is similar to that available in a
tour operator's brochure. However, a brochure gives much more freedom to vary
the layout from page to page. I have limited the tour operator to one photo of
the resort and one for the individual vacation. If they want more, they have to
create a montage. Here is the page for a vacation in Hammamet, Tunisia:
As I have it all resorts will be shown in the same format,
but in the real world each tour operator will have a corporate image. One
option would be to use my page layout as a standard, but develop individual
styles for different companies as an extra-cost option. We will explore the
ways that we might achieve this in Chapters 4 and 5.
Using the Brochure
What if you are at home viewing these vacations during the
day and you see several you like that you would like to show the rest of your
family later? Rather than write them down and search for them again, it would
be good if you could save them in your own electronic brochure. Obviously, the
brochure needs be saved and restored, so that you do not have to start from
scratch if you come back to the system later. In the demonstration, the
brochure is saved as a cookie on the client system, which will be wiped after
30 days (so make sure you have cookies enabled when you access the system!). We
will see how to do this in Chapter 6.
There are advantages and disadvantages of this approach
that will be discussed when we look at the brochure in more detail.
|
|
An advantage of the electronic brochure is that you can
conduct further searches with different criteria and add more vacations to
the brochure. This saves having to provide complex Boolean searching such as
looking for a vacation in either Majorca or Cyprus, but nowhere else in the
Mediterranean. The user should be able to view this brochure at any time and
see the same details of the vacations as they did for the original search.
|
Getting a Quotation
Once you have found a vacation you are interested in, the
next step is to get a quotation. Centaur has a screen that will allow you to
complete a form showing the start date and duration of your vacation and the
number of adults, children and infants that you are booking for. From here, you
can go back to the vacation details, but you are more likely to want to submit
the information and get the quotation.
A fully commercial Centaur would, at this point, submit this
information to the tour operator system to check availability and get an up to
date price. It would be possible to calculate the price from the price tables,
but tour operators may change prices without updating Centaur, so it is better
to get the information directly from a system that we know will be kept up to
date. This gives us both access to current availability and protects us from
the situation that an airline got into in the early days of the Internet when
it was prosecuted and fined for having out of date prices on its web site.
In the demonstration system, the tour operator system is
simulated using a random number generator within Centaur, so the price you get
will bear no relation to the brochure price.
|
Once you have submitted the form, you will see your
quotation:
|
|
You can see that you have three options from here. Well,
actually two, as we are not going to let the user book the vacation until they
have accepted the supplier's terms and conditions.
So, assuming you want to go ahead and book, you can click to
view the terms, then accept these. This will return you to the screen above, as
well as enabling the booking option.
Making the Booking
The booking form is pre-populated with the details of the
vacation chosen. There are also fields that can be filled in to specify a
contact traveler, and for any others travelling with you.
|
After submitting the form, the user will get a
confirmation screen for the booking:
|
|
And that is it. At the bottom of the screen (out of shot) is
an Exit button.
Clicking on this will take the user to an exit screen, from which they can get
back into the main Centaur search screen using the startup option (new or
existing brochure) used initially.
The Use of XML in Centaur
|
The two main uses of XML are for data interchange and for
separating content from style when rendering pages for display. As a case
study, it is clearly important that Centaur demonstrates both. The diagram
shows where this is done:
|
|
The interface between Centaur and the tour operator system
is clearly a messaging interface, and so can benefit from the use of XML as a
data interchange technology. As such, it will require a DTD so the parser can
be used to validate messages. This is a design decision that has an
alternative. By enforcing a standard XML interface on all tour operators, I am
forcing them to develop new front-ends to their systems. In a commercial
environment, issues such as this generate power plays, with the possibility of
some tour operators being able to say that their presence is necessary to the
commercial viability of Centaur, and so I should interface to their proprietary
interface. Should a particular tour operator wish to stick with their own
proprietary DTD if necessary we can accommodate this by converting it using the
transformations possible with XSL.
The user interface, on the other hand, is largely a
display-based system that could be built quite adequately using HTML. However,
XML has some real benefits in this environment, which I shall indicate as I
build the interface. There are places where I use XSL to display pages, and
places where I use the DOM and JScript. All these techniques are described in
subsequent chapters.
The brochure is also stored as an XML text string in a
cookie.
The Vacations
Centaur is designed to search for and display vacations from
multiple tour operators. It would obviously make the system more realistic if
we were to use real vacations rather than make them up. So, many thanks to two
UK tour operators — Panorama Holidays and Argo Holidays — that have allowed me
to use material from their Winter 1998/99 and Summer 1999 vacation brochures.
These tour operators fit the Centaur profile well — Argo specialises in
vacations to a single location — Cyprus, while Panorama has a few brochures,
both to specific locations such as Tunisia and for specialist vacations such as
golfing vacations. So, thanks to them, we can look at real vacations in
Centaur.
Summary
This chapter has been very much about the background to the
case study, and the process of user interaction with the system. You should now
understand:
q
some of my views on software development
q
a bit about recent changes in the UK leisure travel
industry
q
the aims of Centaur and the conflicts between those
aims
q
some of the changes that would be necessary to turn
Centaur into a commercial system
q
what Centaur does and how it uses XML
We also now have a list of the basic functional requirements
for our application. It must:
q
be able to interface with, and retrieve up-to-date data
from, tour operator information databases based on search criteria the user
specifies
q
be able to collate that data into an integrated, sorted
data set
q
allow the user to select a subset of the vacations
information from the data set, and persist that on the off-line client machine
as a personalized brochure
q
allow the user to select a vacation from the brochure,
get a quotation, and if they want to, book it
In the next chapter we will take a look at XML and why it
provides the means to satisfy these requirements in a comparatively
straightforward manner, without the need for complex format conversion components.
