1. Design based on OpenTravel standards. During the design of the transaction model, assume that OpenTravel messages will be the basis for all transaction messages. For segments where messages don’t yet exist, assume that messages will be developed or participate in the work group that helps define the messages. If you are already transactional, work with your technology vendors to ensure that OpenTravel standards are applied to the system (sooner rather than later). Any new integrations or partner connections should be made using standard messages.
2. Use OpenTravel compliant technologies. Many destinations that are dabbling with transactions are using or considering Destination marketing systems that use built-in booking engines. In most, if not all cases, these booking engines require local suppliers to load inventory into an extra-net for sale through the destination’s website. This is a model that is, in my opinion, philosophically inverse to the OpenTravel Model. Work with best of breed technologies for each segment and ensure they all use OpenTravel messages. If you find a technology partner you really like but they are in a segment where messages do not yet exist, then work with them to create the standards and then implement them.
3. Build for inter-connectivity. This means separating the system architecture into layers and keeping the connectivity layer completely separate from the database, business logic, and interface layers. This is not new technologically, but, surprisingly, not as common as it should be. The layer that actually connects to the supplier systems (whether direct connect or to an intermediary system) should connect using OpenTravel messages. Again, if you are considering a closed and proprietary DMS, then think twice and take a close look at the provider. A closed system may simplify things in the near short term, but this is the WRONG approach and will cost more to maintain and update in the long term.
Destinations have the ability to influence the adoption of standards throughout their region. Although many organizations might balk at the standards initially, it is not something that should be negotiable (for the most part). Let your stakeholders, both internal, external, and vendor partners know that using OpenTravel standards is important and that preference will be given to those partners that comply. Your ultimate decision to use a partner or connect to a supplier will be based on your relationship with the vendors, but in the short term, your support for OpenTravel standards sends a message that openness and connectivity are important. In the long term, this is a much stronger and more extensible approach and reaps the most potential benefit for all stakeholders both large and small.