Your seat in the clouds awaits you

Ce billet de blog est également disponible en français ici.

Back in November 2011 easyJet announced that starting in the spring of 2012 we would begin a trial of allocated seating and on April 12th we went live on five routes from London Luton and Glasgow. Since then we have gradually extended this trial and we are now offering allocated seating on almost all routes on our network and by the end of November we will be at 100% operational delivery. This is a huge change for easyJet. Free seating, referred to by many of our passengers as “the scrum”, was part of our DNA. It was how we had always operated. It had become part of the definition of easyJet. As our CEO Carolyn McCall said in the article above, the trial could only be deemed successful if it met all three of the following criteria:

1. It had to increase customer satisfaction. We work hard to have happy customers. It’s another thing that’s part of our DNA. Allocated seating had to really make a difference to the passenger experience. Many people said that they wanted it but, once we gave it to them, would it really make the difference they thought?

2. It had to work operationally. easyJet operates one of the quickest turn-around times in the industry. If boarding passengers into allocated seats was seen to have a negative effect on our On Time Performance (OTP) it would not have been considered viable.

3. It had to work commercially. Allocated seating had to prove itself a commercial success as a revenue generating product.

Trial by fire

This highlights the fact that such a move was a calculated risk. We were not sure it would work but it required significant change and investment to find out. One of the major changes was to our reservation system. Our home-grown reservation system did not support allocated seating. The primary advantage of maintaining a bespoke system is that it can be tailored to your exact business needs. No extraneous functionality cluttering up the works. It does, on the other hand, support bookings from around 58 million passengers a year and take over £4 billion in revenue.

Changing the beating heart of our enterprise, our various sales channels like and our operational systems to support allocated seating was no small undertaking, quite apart from the changes to our operational processes. Making those changes to support a trial, an experiment? That called for a quite special approach.

Our first decision was that we definitely did not want to have to conduct open-heart surgery on our reservation system to add this functionality. The I/O load from selling 58 million non-specific seats a year is already a veritable fire-hose. Scaling and refactoring to support the tracking and locking of over 58 million specific seats on a system that can book up to 1500 seats a minute would be a huge project.


Would it be possible, we wondered, to buy “seat-allocation-as-a-service” (SaaaS?) from a third party? Get someone else to do the heavy lifting of tracking the availability of every single seat we have on sale while we just stored the output, a few bytes that represented the selections made for the seats we have actually sold?

Apparently not. However the idea of a separate “seat-allocation-as-a-service” solution attached via a very light-weight integration was too attractive to let go so we decided to build our own.

What this means, in summary, is that the tens of millions of seats we have available at any given time are tracked via partitioned SQL Azure databases and cached in the Azure AppFabric Cache. All the logic, business rules and data relating to …

  • selecting seats
  • handling contention for seats
  • aircraft types
  • seating layouts and configurations
  • price bands
  • which passengers can sit where
  • seating access for passengers with restricted mobility
  • algorithms for automatically allocating seats to passengers who chose not to make a selection
  • and the million-and-one other things that have to be taken into consideration when seating an aircraft

…all this is done in the cloud. Even the interactive UI that displays the graphical map of the aircraft is served from Azure and injected into the booking pages on


The ingenious work to achieve this using JSONP, Ajax and Knockout.js (amongst other things) is a tribute to the fantastic development team at easyJet and may be the subject of a subsequent blog post.

The overall approach however has allowed us to implement an incredibly significant change to the way we operate and sell our flights and deliver it at massive scale without needing to implement much more than small refactorings in our core operational and retail systems. The low cost and massive scale of Azure has made the whole notion of experimenting with something so fundamental an achievable reality. This calculated risk has become a bet we can much more easily afford to make.

Most importantly it has massively reduced the cost of failure. We had to conduct a thorough trial. We couldn’t be sure that it would work. Whether it worked or not was primarily a business decision rather than a technical one.

Now that it has been successful we have delivered a solution that works technically, works operationally, works commercially, improves customer experience and transformed our enterprise. However, if it had not worked and we had needed to turn it all off and walk away, we could have done so without having incurred huge risk, technical debt or cost.


Failure to Communicate

There is a discussion of this article in the EA group on LinkedIn.

At a recent Gartner Group presentation the presenter estimated that between now and 2012 40% of Enterprise Architecture (EA) programmes will be shelved due to poor execution and that a major contributory factor to this will be a failure to effectively communicate the value of EA.
This is not a new problem for enterprise architects and IT architects in general (there are currently 10 widely used IT job titles that include the term architect). As someone who has always tried to use a "light-touch" approach to architecture and who’s job appears to many almost indistinguishable from staring into space, the importance of measuring and communicating value has always been forefront in my mind.
However, it is unusually hard to do this effectively across a wide audience. If EA initiatives are to succeed they must have buy-in at many levels in an organisation. At the recent TechEd EMEA in Barcelona I was out one evening with a mixed group for drinks when a seasoned programmer rather colourfully confided to me that she really didn’t understand what architects did. [I paraphrase] "They just seem like self-important developers and managers who swan around being really up themselves." Now one could argue that this maybe down to the experience of the individual in question, the number of drinks in the individual at the time or that this represents an equal failure or unwillingness to understand, but if ever there was a failure to communicate value there it is in action.
Architecture is actually all about value. Not value in the ROI sense, which is both a difficult and dangerous way to measure EA, but in the sense of really driving out the best value from IT investments across the board. Good architecture is highly valuable because it’s role is to find and ensure the delivery of best-fit solutions to business problems. To ensure the accurate translation of business strategy and requirements into IT strategy and delivery and to achieve maximum leverage and reuse of existing assets. However, because these kinds of activities are largely orthogonal to business units, projects and service delivery their value in terms of ROI is difficult to measure and tends not to reflect their real value to the business.
The business spend in IT is broadly divided into three areas.
  • The Run Spend – operational costs of maintaining services
  • The Growth Spend – introducing new services
  • The Transformation Spend – restructuring existing services to better suit changing business needs
The bulk of EA and other architectural initiatives are concentrated in the second two areas (Growth and Transformation) and it is these areas that tend to be first in the firing line when cuts need to be made. However, without proper architectural focus it is very difficult to produce services with lower longer term running costs or ones that can more easily be transformed. So, the effect over time of reducing the spend on transformation and growth is that running costs increase, often cancelling out the short term gains of the cost cutting.
I have borrowed (and modified) this slide from David Chappell’s excellent presentation at TechEd about the Microsoft Application Platform.
His premise in this presentation is that the primary goal of business strategy is to create competitive advantage through differentiation. Key to creating this differentiation are custom applications on the basis that if you can buy something off the shelf it’s equally available to your competitors, almost certainly old news and therefore does not create competitive advantage.
However, over time, innovation becomes obligation and the value of that service decreases. The first provider to offer a given service gets the most advantage/value, the second less so and so on, up to the point where that service becomes so widespread that not providing it becomes a distinct disadvantage.
The strategic importance then of the application platform is that it should facilitate rapid and cost effective development and deployment of these differentiating applications in the key window of opportunity (C) and provide low operational costs over the longer term (B).
We can look at the strategic importance and value of EA in the same way. (B) is where the operational spend occurs while (A) is where the growth and transformation spend occurs and where much of the EA effort is focused. So we can see that the focus of EA is on delivering maximum value in (A) and creating architectures that will reduce costs in (B).
With a mature EA the lower operational costs have been achieved and much of the major transformation work is complete. Architecture has been created that allows for quicker, easier, cheaper transformation when required leading to greater agility, and maximum reuse and leverage of existing assets. This means that more of the overall spend can be used to achieve greater advantage in the growth area or the same growth can be achieved for less spend. As a result EA rarely has an ROI of its own, rather its value is found in improved ROI across a whole range of other initiatives.

Service Orienteering

There are bushmen wandering in the Kalahari who have heard the term SOA. It has been an industry buzzword for the last 3 – 4 years. However, definitions of SOA are as varied as they are widely spread. To try to untangle these definitions we need to start from the ground up.
Services are simply the next evolution in how we write code. They are the next level of abstraction, the next unit of re-use and encapsulation and the next software paradigm. 10 years ago we talked about objects, 5 years ago it was components and now it is services.
Service Orientation is to services as object orientation was to objects. When we build applications in a service orientated manner we are thinking about our application in terms of the interaction between services. Where we had APIs we have service contracts and where we had shared types we have schemas or data contracts. Instead of clients and servers we have service consumers and service providers.
This explains some of the confusion that surrounds the acronym SOA. When some people are talking about SOA they mean Service Oriented Applications and Service Orientation in general as opposed to Service Oriented Architecture. Another factor that adds confusion is that SOA and Web Services have been used interchangeably to mean the same thing when actually it is quite possible to develop service oriented applications and design service oriented architecture without using web services at all.
Finally we come to SOA where SOA stands for Service Oriented Architecture. This has almost nothing to do with the software development concepts we have just discussed because the “Services” are not the same. In Service Oriented Architecture the services are Business Services and SOA in this context means “architecting” your IT infrastructure so that it is both strategically aligned with and decoupled from the business services it supports. While Service Orientation is a technology that can facilitate this architectural decoupling from a software perspective, they are not the same thing.
The reason we are all obsessed by decoupling these days has to do with complexity. Both the business and IT challenges we face are inherently and increasingly complex. Complexity is here to stay. The people who handle complexity most efficiently and robustly will win whether it’s because they are fastest to market or incur the lowest costs or offer the greatest value or achieve the greatest flexibility.
Decoupling and modularization are efficient. They create agility and facilitate reuse. A group of climbers ascending a mountain who are all roped together get some benefits in terms of security and communication however, they must all take the same route, normally the slowest easiest route that is accessible to the least skilled of their team. They must all travel at the same pace, normally the slowest pace, the one at which their weakest least fit member travels. They must all encounter the same risks at the same time. An avalanche that takes out one member is likely to get the rest, either because they are all bunched up or because they are all roped together and get dragged along. They are not resource efficient. Before they embark on the first step of the journey they must have sufficient resources in terms of food and equipment to get the whole team to the summit and back. They must always attempt each challenge en route in the same order, i.e. the order in which they are roped together or they must stop and go through a reordering process. If one member is injured or falls sick the whole team must stop or slow down or the ascent may have to be cancelled. These factors make them slow and places some if not many mountain tops completely out of their reach.
The same group of climbers that ascended using different routes at different paces and at different speeds and times incurs none of the above disadvantages and gets all of the benefits of being a team if they use radio, GPS and thermal imaging to provide the same security and communication the rope used to provide.
Complex, non-linear, tightly-coupled systems tend to fail in non-predictable and catastrophic ways. The point at which they fail tends to coincide with or result from a change in the state or behaviour of one of the components. This has been described as the domino or ripple effect which in reality doesn’t even begin to describe the problems faced by modern complex systems because both falling dominos and ripples are simple and linear. Non-linear systems have feedback loops and echoes which can exacerbate, magnify or accelerate failures. In complex systems a single event or action can cause a multiplicity of other events or actions which are not the same or in the same order each time.
Complexity and non-linearity are here to stay. These are inherent in the problems we are trying to solve so they are non-negotiable. We cannot do something complex in a simple way except by abstracting the complexity and that simply moves the complexity somewhere else, it does not reduce it. In fact it can add new complexity. Even simply hiding the complexity of a system behind a simple interface can cause problems in terms of its use, for instance it can make resource intensive processes seem otherwise. The only feature we can mitigate to any great extent is the coupling and this is why so much of our effort is addressed here.
How do we benefit from strategic alignment ? Really, when we say strategic we mean “from the strategic level on down” and the alignment means that IT infrastructure is modeled on the business services it supports. The most obvious benefit is that the IT infrastructure is designed to support not only the business as it is today but as it will be tomorrow, it has the businesses strategy engineered into it. It is proactive and not reactive. This makes the business agile because when it needs to change it doesn’t have to wait for the IT infrastructure to be re-engineered to support that change either because the systems have been engineered to allow for change or because their decoupling allows for change in one without necessarily requiring change in the other. When it comes to capacity management (one of the most arcane and yet most critical arts in both Business and IT Management)** the clear mapping of business processes and services onto IT services and processes is of enormous benefit. Key business volume indicators (BVIs) can be identified and profiled to find their resource footprints. What does a BVI cost the business in network bandwidth, system memory, processor cycles, disk space etc. Which systems are involved or affected? If the business plan involves increasing a BVI (e.g. doubling sales) the knowledge of that BVI’s system footprint enables IT to quickly establish if current capacity will support the increased business and if not, which systems will have to be scaled by how much to meet increased demand and how much will that up-scaling or out-scaling cost ? If IT cannot answer these questions in a timely and accurate manner when business decisions are being made this is a constraint on the agility of the business and a risk to the success of business strategy.
**If you really want to get a handle on this talk to Capacity Management specialists Capacitas or arrange to attend one of their excellent seminars.
%d bloggers like this: