Great casestudy on BPM with BAA.

1. mwd
advisors
Best Practice Insight
Case study: BAA
Neil Ward-Dutton
Premium Advisory Report
February 2011
This report examines the implementation of technology from Pegasystems within BAA, the UK‟s
leading airport operator.
MWD case study reports are designed to help organisations considering or actively working with
BPM technology understand how others have worked to obtain benefits from BPM implementation,
and how they have worked to overcome challenges that have arisen along the way. All MWD‟s case
study reports follow a standard model, and are researched using a standard process which is driven
by senior MWD analysts.
This report is published as part of MWD‟s premium BPM advisory subscription service. You can find
out more about this service at http://www.mwdadvisors.com/services/cas.php.
Review this research in context
For further insight around the best practices highlighted in this research and to discuss this in the context of your
own organisation, you can schedule a private advisory session with our expert analysts by emailing
clientservices@mwdadvisors.com or call on +44 (0)20 8099 4301.
MWD Advisors is a specialist IT advisory firm which provides practical, independent industry
insights that show how leaders create tangible business improvements from IT investments. We use
our significant industry experience, acknowledged expertise, and a flexible approach to advise
businesses on IT architecture, integration, management, organisation and culture.
www.mwdadvisors.com
© MWD Advisors 2011

2. BPM case study: BAA 2
Case study key facts
Organisation BAA
Industry Travel, construction
Current BPM goals Continue development of Real-time Heathrow programme to gain end-to-
end oversight and control of airport operations; use technology to drive
greater resource efficiency and improve passenger experiences.
Process scenarios  Sequential workflow
 Straight-through processing
 Case management
 Content lifecycle management
 Collaborative process work
 Value chain participation
Current approach In 2008 BAA started a major programme to replace a number of ageing,
custom-built airport operations systems and comply with forthcoming
European Union regulations related to the Single European Sky ATM
Research (SESAR) programme. After an initial procurement project led to a
dead-end, BAA carried out a business architecture effort which helped the
company realise that many of its requirements were not aviation-specific,
but could be met with general-purpose software technology. After further
analysis it carried out another procurement exercise, this time focused on
BPM technology.
BAA‟s Airport Collaborative Decision Management (A-CDM) system is the
first fruits of the resulting investment, and forms the first piece in a larger
programme to completely replace its operations systems called Real-time
Heathrow. The implementation is technically very advanced and revolves
around real-time optimisation of airport resources to create and manage
schedules for flight turnarounds. Both human participants (from multiple
organisational teams and departments) and information systems are brought
together in the A-CDM system to enable managers to minimise flight
turnaround times – and in turn save BAA and airlines money and improve
passenger satisfaction.
Outcome Following implementation of A-CDM at London’s Heathrow T5,
on-time departures have increased from 60% to 85%. Improved
resource planning enabled by A-CDM has improved passenger
throughput in the terminal, and increased the efficiency of overall
terminal operations.
BPM tools and suppliers Pegasystems‟ SmartBPM Suite; Pegasystems consulting and implementation
used services.
© MWD Advisors 2011

3. BPM case study: BAA 3
Company background
BAA is the UK‟s leading airport operator. It owns and operates a number of airports in the UK
including London Heathrow, Stansted and Edinburgh. It also has interests in the USA (retail
management at Baltimore-Washington, Boston Logan and Pittsburg airports).
The company was originally established in 1965 when the UK Government‟s airports were privatised.
BAA became a public company when it floated on the UK stock market in 1987; it delisted in 2006,
prior to its acquisition by Spanish company Ferrovial, the world's largest private manager of
transportation infrastructure.
In 2008 the BAA‟s UK airports handled a total of nearly 146 million passengers, where it employs
around 13,000 staff.
Project background
According to Eamonn Cheverton, Enterprise Architect at BAA, the airports business is a conservative
one when it comes to implementation of new systems: although most systems aren‟t genuinely safety-
critical in nature, the scale of operations at an airport like London‟s Heathrow means that systems
problems can have very significant impacts on local infrastructure as well as on BAA‟s business – for
example a major systems failure at Heathrow can quickly lead to gridlock on one of the UK‟s largest
motorways (which feeds the airport). For that reason, airports tend to upgrade their core operational
systems only when change is to an extent forced upon them (by changing regulations, security
requirements, or airlines‟ requirements).
In 2008 two catalysts for change came about, particularly in the area of operations. One was that the
existing custom-built systems were rapidly approaching end-of-life; the other was the institution of a
new European Union directive to drive greater interoperability of traffic control systems across
European airspace (SESAR).
BAA started by running a procurement project – the scope of which covered operations, staff
information systems, flight information systems, billing and airport planning – that initially assumed the
new operations system would be custom-built, just like its predecessor.
Having found that all the bids were difficult to justify in terms of expense – based on a comparison
with an approach based on continuing to maintain the existing system – BAA decided to look again at
its requirements. A team of architects, led by Cheverton, carried out a business architecture exercise
designed to map the high-level business domains, capabilities, services and processes within the scope
of airport operations, and as this exercise unfolded it became apparent that many of BAA‟s
requirements were actually generic demand- and capacity-planning requirements that were applicable
across industries, not dissimilar to those typically addressed by some customer relationship
management (CRM) implementations. An aviation-specific system was not necessary.
With this insight, BAA then re-ran its procurement exercise, but this time it focused on BPM
technology as the foundation for its replacement system rather than custom development.
Nevertheless, „pure‟ BPM technology functionality was only part of the requirement; BAA also needed
a platform that could be used to implement core system business logic and rules.
Implementation characteristics and status
BAA chose to work with Pegasystems as a result of its second procurement exercise, and is working
with the supplier on a number of projects that together will form an end-to-end operations system.
To date, the most significant application that‟s been deployed is the Airport Collaborative Decision
Making (A-CDM) system, which is focused on managing the turnaround of aircraft from arrival to
departure.
© MWD Advisors 2011

4. BPM case study: BAA 4
Managing the turnaround of aircraft is a complicated real-time optimisation exercise that has to be
carried out in the context of a number of constraints – including security (some airlines‟ aircraft can
only be parked in certain locations) and stand sizes (not all stands can accommodate the largest
aircraft) and of course the availability of airport resources. Within the system, each aircraft
turnaround is handled as a case, and in order for case work to be completed the system drives
collaboration between a number of human participants (such as flight crew managers, refuelling and
cleaning crews) and systems (such as air traffic control). Using sophisticated sets of Pega rules, the
system schedules departures and arrivals to minimise the time each aircraft spends on the ground,
stationary or taxiing.
Behind the scenes of each turnaround case, the A-CDM system uses the concept of „resource plans‟
to co-ordinate the management of resources (stands, gates, security, check-in desks, aircraft, and so
on) that need to be available in order to take a flight from arrival to departure. Before the
implementation of the A-CDM system, airport resources which all had to be co-ordinated in order to
optimise airport operations were all managed by teams that were organised within separate lines of
business. A-CDM resource plans create one „place‟ where the management of these individual
resources is brought together. What‟s more, resource plans have to be dynamic – because the
airport‟s operating environment is dynamic. Passenger volumes spike, security threats come and go,
and weather patterns change, and all these things and more have an impact on the availability of
resources. A-CDM uses the concept of „Defcon levels‟, each of which represents a certain level of
stress on airport resources. Each level is associated with sets of policies that themselves affect
resource allocation; a monitoring tool actively manages Defcon levels in order to keep automated
resource allocations in line with the overall operational environment.
Since the deployment of A-CDM, BAA has also used Pegasystems‟ technology to deliver smaller
applications focused on Works Approvals permits management and asset data validation.
The approach
As mentioned above, when it comes to the implementation of new core operational systems BAA is
by necessity conservative. Despite this BAA has embraced Agile methods for software delivery, and
it‟s applied those techniques to the development of -CDM and the current projects underway to
deliver the broader Real-time Heathrow operations vision.
Strategy
BAA doesn‟t consider BPM in itself as a strategic activity; however Pegasystems‟ BPM technology is
absolutely core to the way that BAA is committing to deliver operational improvements to airlines
and passengers through A-CDM and, ultimately, the Real-time Heathrow programme.
Architecture
Architecture work, with a particular focus on business architecture, has been absolutely fundamental
to the delivery of A-CDM and the Real-time Heathrow programme so far. Without work on a
business capability and service map, Cheverton and his team wouldn‟t have been able to embark on a
systems replacement programme like it has done. The architecture team used the NATO
Architecture Framework (NAF) as the initial blueprint for this work, as it was mandated by the
European Union for the implementation of SESAR, of which A-CDM is a deliverable.
What‟s more, BAA‟s business architecture effort continues to inform the development of the Real-
time Heathrow initiative – primarily by highlighting which functional components need to be shared
across multiple business capabilities and services, and should therefore be designed for reuse.
At the same time, BAA‟s SOA effort – which has been in place for a number of years and mandates
the integration architecture for all systems needing to connect to others, including a canonical data
model for integration based on standards specified by OASIS, IATA and others.
© MWD Advisors 2011

5. BPM case study: BAA 5
Organisation and people
BAA‟s risk-averse approach to core operations systems development has led it to commission
Pegasystems to carry out all the detailed implementation work, but nevertheless the effort is a
collaborative one. BAA provides projects with IT architects, business analysts and project managers
(following the Scrum method). All development work is marshalled into 42-day „sprints‟, with no
project allowed to have a budget of greater than £75,000.
Business stakeholders have regular „hands-on‟ involvement in development sprints: at least once a
week, they‟re involved in progress reviews. BAA uses Pegasystems‟ own project management and test
management frameworks within sprints, and it uses Pegasystems‟ Direct Capture of Objectives
(DCO) application to work collaboratively with business representatives during each „inception phase‟
(which kicks off each set of three sprints and is designed to prioritise the work backlog and individual
software requirements).
Although Pegasystems is responsible for carrying out the detailed implementation work, key BAA staff
have taken Pegasystems training – specifically so BAA could be confident it was acting as an „intelligent
client‟ (asking the right questions and making reasonable demands of its supplier). BAA‟s own people
manage the overall delivery of on-site training to internal staff, with BAA providing programme-
specific architecture orientation and training, and Pegasystems providing detailed training elements
specifically focused on use of DCO.
Prior to the start of BAA‟s relationships with Pegasystems it was already familiar with the use of
Scrum, but it‟s found that in order to consistently deliver results with a mixed in-house / third-party
team it‟s had to weave a lot more formality into its Agile approach. What‟s more BAA has found that
to really get the benefits of the Scrum approach in development, it‟s had to reengineer the IT
management processes that fit around development (for example portfolio management, deployment,
testing and so on).
Governance
Although the wider Real-time Heathrow programme is still under construction, BAA has already had
to manage significant change to the released A-CDM system and to the new elements in development.
Some of this change comes about through new „user‟ requirements, but much of it is due to
architectural or technology platform change. At the same time as it has continued releasing
functionality, BAA and Pegasystems have upgraded the underlying technology platform twice and
overhauled the user look-and-feel once; the team has also had to re-engineer its integration code a
number of times due to changing data object structures mandated by its airports‟ integration
architecture standards.
With all this change in its technology environment, BAA has to have a very structured approach to
change management. Changes to new requirements or to released system functionality are managed
in a governance layer that „wraps around‟ BAA‟s Agile software delivery method; a formal change
control process, with involvement of IT architects and business analysts, prioritises change requests
and interleaves them with the Agile backlog to insert their implementations into future development
sprints.
Reusability is also a key goal of BAA‟s governance approach. Its business architecture foundation,
started in 2008 as part of the initial technology procurement exercise, continues to highlight
components that should be designed for reuse. The architecture team manages its business
architecture capability and service maps outside Pegasystems‟ tools, using the MEGA Suite.
Technology and infrastructure
Pegasystems technology forms the core of the A-CDM system, and of the wider TAM implementation
programme. The A-CDM user interface combines Pegasystems technology with Microsoft SharePoint,
and back-end integration with external systems is managed via Oracle‟s WebLogic application server
and Progress Software‟s Sonic Enterprise Service Bus (ESB).
© MWD Advisors 2011

6. BPM case study: BAA 6
For Cheverton, standards are important in BAA‟s efforts but they‟re not to be followed slavishly – the
key is fitness for purpose. For example, as we‟ve mentioned above, BAA has borrowed from the Nato
Architecture Framework (NAF), IATA and OASIS in its high-level architecture work; in addition, it
makes a lot of use of web services and XML standards in its integration technology layer. But when it
comes to modelling, the company is not pursuing BPMN for the sake of being standards-compliant: it‟s
found that business representatives don‟t find BPMN models easy to understand, so it‟s using a
lightweight cut-down modelling notation that it‟s derived itself. As far as BAA is concerned, the key is
to have a consistent approach to modelling that everyone can buy into. And because development
work is being driven by Pegasystems rather than BAA, any potential hiring constraints that might
spring from not using BPMN are avoided – BAA has ensured that Pegasystems developers are happy
to work with the modelling notation it‟s settled on.
There‟s one other technology-specific note particularly worth taking about BAA‟s implementation
with Pegasystems: BAA has mandated that the Pegasystems developers it contracts must not write
external compiled code as workarounds. Rather, they must use generally-available functionality within
the Pegasystems platform for implementation of all features. The reason for this is that having made a
conscious decision to avoid going down the custom development route for A-CDM, BAA does not
want to end up with a system that relies on custom proprietary code. In Cheverton‟s words: “We
have a horrible history of complex, expensive package upgrades because we‟ve used custom code to
tailor what we‟ve bought. We want to avoid this in future wherever possible.”
The results
Since the A-CDM system has gone live at London‟s Heathrow T5, BAA has managed to increase on-
time departures from 60% to 85%. This means BAA pays fewer penalties. Improved resource planning
enabled by A-CDM has improved passenger throughput in the terminal, and increased the efficiency of
overall terminal operations.
Recommendations for BPM adopters
In carrying out this case study, we asked representatives from BAA to share any recommendations
they‟d offer to other potential BPM adopters. Eamonn Cheverton offered two points in particular:
Firstly, make sure that before you start any BPM effort you have in place a solid set of business
architecture reference models (particularly models that capture definitions of business services and
business capabilities) – together with a well-defined performance framework that identifies
stakeholders‟ responsibilities and associates these with business change goals and priorities. By
providing a clear context for business changes, these models help to inform business cases and tease
out change project benefits, costs and risks – as well as clearly identifying those who will have to play
a role in project success.
Secondly, before you choose a BPM technology provider, you should carry out serious tests to see
which providers can support your change needs. Cheverton advocates conducting a two-day “cook-
off” process. In this process a number of vendors are first invited to implement a set of proof-of-
concept requirements, and then, on the second day the requirements are changed without prior
warning. The process helps identify which vendors‟ tools are really able to support rapid change.
© MWD Advisors 2011

7. BPM case study: BAA 7
Best practice insights
Through the implementation of A-CDM and the ongoing development of the Real-time Heathrow
vision, BAA has demonstrated two best practice insights that you should think about in the
context of your own implementation:
Don‟t carry out process analysis and design as a standalone exercise; make sure that all the
relevant stakeholders have a consistent understanding of the wider goals and context of the
initiative. A business architecture exercise like the one carried out by BAA is a great way to not
only create shared understanding to frame your BPM programme correctly, but also provide
architectural principles that will steer ongoing development work to maximise opportunities for
reuse (and therefore drive improved consistency and quality of the implementation).
If you‟re using a third-party supplier to carry out the development work for your BPM
implementation, strongly consider mandating an Agile method as the project management
structure for delivering functionality and ensure that your key IT and business stakeholders (IT
architects, business analysts, business managers) have regular opportunities to participate in
priority-setting and reviews of deliverables. An Agile approach by your software delivery partner,
with consistent engagement from your people, ensures ongoing recalibration and checking of
development efforts – which is particularly important in the context of using BPM tools, where
new functionality can be delivered very quickly.
© MWD Advisors 2011