Okay, deep breath. Now let’s get to the question of why you should care about the infrastructure or architecture that your travel technology provider uses?
Some say that their customers don’t care about how the software is built. They are buying business solutions, not technology. They say all customers care about is whether they can turn on and off, purchase based on usage and don’t have to care about scalability and reliability.
But, just because customers don't care about understanding the technology very deeply, and shouldn't have to care how about the details on their software provider runs their technology operations is a very different statement than saying that the architecture model isn't important to them.
So here are the top 10 reasons that you should care about how your travel technology provider builds and operates their products:
1. Lower cost.
Okay, this goes first because it’s what people usually care about most. Cloud and Multi-tenancy are huge levers to reduce the cost of delivering the application and therefore the number one way in which a travel technology company can reduce the costs to users.
Developing a single code-base rather than maintaining several different flavors, managing a homogenous infrastructure, increasing utilization of computing resources via a shared infrastructure all contribute to keeping costs down.
2. Higher application availability and reliability.
System architecture has a massive impact on both availability and reliability. Wait…aren’t these the same thing? No. Availability means whether or not you have access to the application at a given point in time.
Reliability deals with the inherent stability of the platform – how often will it fail. Your technology vendor can hide unreliable software with multiple redundant systems, keeping the application available, but the cost of establishing and maintaining those redundant systems can jack up the prices to you.
3. Better scalability.
For some customers may seem to be less of an issue than it really is. If you have a limited inventory (e.g. a 6-room B&B) to sell and your individual business growth is inherently limited, you may not feel the need for a highly scalable application.
But very often your technology vendor is supplying the same application to many customers. If they are successful they will have many clients and experience rapid growth. So can they add all those customers without impacting the service they provide you?
When dealing with perishable inventory a system crash because of scale can leave you with an outage and a potential for lost sales which can never be recovered.
4. Faster implementation time.
This is a very big issue. The cost of implementation of software is often multiples of the initial acquisition cost. And depending on the level of complexity, it can also take a very long time to get you up and running, delaying you from receiving the value of the software.
Typically SaaS uses a configuration rather than a customization model to implementation which greatly reduces implementation timelines. Similarly, application consistency can also reduce training costs.
5. Vendor sustainability.
This may be perhaps the most important aspect. Architecture matters because it goes to the sustainability of the platform. In a recent post, noted SaaS blogger Phil Wainwright wrote about multi-tenancy:
"To say that multi-tenancy is only of interest to vendors and has no relevance to customers is a bit like saying Wintel compatibility is only of interest to PC manufacturers, and so customers should not worry about it.
"Try telling that to the enterprises that invested and wasted millions of dollars in rolling out DEC Rainbows or IBM PS/2 Microchannel machines in the mid- and late 1980s. If a vendor is selling you a proprietary dead-end that will be obsolete before its time, I’d say that’s a factor of huge importance to customers. Don’t let anyone tell you any different."
6. Faster introduction of new features.
Multi-tenant applications utilize a single code base which improves the efficiency of the development operations. While sharing a common code base amongst a diverse user base can result in varied requests for new features, it also helps identify the most commonly request features and deliver those to market more quickly.
7. Quality of service.
The homogeneity of infrastructure, application and database enables providers at each step of the chain to offer more granular and specific Service Level Agreements including Quality of Service which can enable you to support the requirements of your business.
8. Improved performance.
If you’re using an on-demand application, a major impact on an individual’s perception of the application’s performance is related to network latency – how long does it take to send data back and forth to the main server. The big cloud providers spread the infrastructure over multiple geographies and even effectively move the app around the globe in a follow the sun mode, to reduce latency and improve the user’s productivity. This can also ameliorate need for employing CDNs (Content Delivery Networks like Akamai) which in turn may reduce cost.
9. Reduced integration challenges.
Integration is a very big issue for large and small companies alike. The architectural choices a travel technology provider makes has a big impact on how well they can support integration with other applications that the solution needs to interact with.
10. Better disaster recovery.
This is largely an operational issue rather than a technical one. Using a shared infrastructure and common application and database schema reduces the cost of DR.
So nearly 2,000 words later (including Part One), do you have a different view than when you started reading?