A Toolchain for Lean Architecture at American Airlines

A Toolchain for Lean Architecture
at American Airlines
Shahir A. Daya
IBM Distinguished Engineer, IBM
Arun Dhanabal
Senior Manager, American Airlines
Think 2019 / 3768A / February 14, 2019 / © 2019 American Airlines & IBM Corporation

Agenda
1. Overview of the American Airlines project
2. How we ran architecture
3. Architecture practices
4. Lessons learned
5. Q & A
2

Overview of the
American Airlines
project
3

The Problem Statement
The AA team
wants to adopt Agile
methods but is
hampered by the
technology used in
the website, the
complexity of the
applications, the
difficulty to perform
regression tests on
the applications,
and the
organizational
structure of the
team.
The current AA.com
website is a
monolithic Java
application hosted
on 80 Tomcat
servers. The same
feature/functions
were developed
separately for the
various channels
that resulted in
duplicate code.
The applications are
difficult to extend
and not up to date
with modern
application
development
frameworks or
approaches. 80% of
effort to maintain
current Apps.
Their hosting
provider(s) were
reaching EOL on
their hardware
platform, and AA
was facing a huge
capital cost just to
keep doing the
same old thing…
4

This is what we set out to do… Transform
using an Agile method and DevOps approach,
the existing AA.com, mobile apps, and kiosks
to a more modern application architecture,
running on IBM Cloud, enabling agility in
continuous innovation and at the same time
transforming the current AA siloed
development organization to a modern one.
This is what we set out to do…
5

IBM Cloud Garage Method
Combining industry best practices
for Design Thinking, Lean
Startup, Agile Development,
DevOps, and Cloud to build and
deliver innovative solutions.
To learn more visit:
https://www.ibm.com/cloud/garage
6

How we ran
architecture
7

The role of the architect
• The Architecture Team set the
boundaries
• Build Squads had flexibility in
making their own decisions
within the boundaries
• We found that squads that had
end-to-end ownership and
accountability of the product
they were building did not like
to be dictated to by architects
and rightfully wanted the
authority to make decisions
that impacted them
Source: https://www.ibm.com/cloud/garage/content/code/role-of-an-architect
8

Core team and guild structure
Think 2019 / 3768A / February 14, 2019 / © 2019 American Airlines & IBM CorporationThink 2019 / 3768A / February 14, 2019 / © 2019 American Airlines & IBM Corporation
9

Decentralized governance
Think 2019 / 3768A / February 14, 2019 / © 2019 American Airlines & IBM Corporation 10

Architecture
practices
11

Architecture team backlog
• GitHub project board
• Basic Kanban style board
• Required discipline to groom
the backlog frequently and
have architects update the
board.
• We used labels extensively.
For example, to specify area
of concern or identify
activities that required help or
those that were open for
participation by Architecture
Guild members.
12

Documenting Architectural Decisions
• Architectural Decisions were
for cross-cutting concerns
you would expect for a Cloud
Native / Microservices based
architecture for digital
products
• These decisions impacted all
of the Build Squads
• We needed the decisions to
be easily accessible and
consumable by the squads
• We choose GitHub issues
and leveraged labels for the
workflow
13

GitHub for Documentation
Git has proven to be a remarkably flexible and powerful tool for developing design documentation and
capturing design decisions. The primary benefits of using git have been:
1. Markdown is a very simple language to learn and author content in. It is easy to write nicely formatted
documentation just using the markdown editor that is available on GitHub.com without having to memorize
complex markup commands.
2. Markdown makes it very easy to link documentation pages together through hypertext links. In fact, it can
very easily be used as a simplified version of the wiki editing language used in wiki pages - while clicking on
a blank local link does not create a new page, the visual differentiation between one with and without a link
(e.g. without a link in parenthesis) makes it easy to know which linked pages need to be filled in. Given that,
you may never need wiki’s.
3. The built-in version control (it is, after all Git!) makes merging the work of multiple authors very simple.
4. Graphics are handled just as easily as text in Github. You can create graphics using any number of online
tools (such as draw.io) that check directly into Github, or you can create graphics locally and check them into
Git very easily.
5. The final advantage is of course, that it is simple to directly integrate your documentation and design
decisions in the same repository, or a sub-repository as your source code. Keeping the two together makes it
extremely unlikely that they will go out of sync - especially if you open GitHub issues against design
documentation in the same way as you do against the code.
14

Documenting the architecture of a product
• Lightweight architecture
documentation
• Markdown in GitHub repo
• Focus on key diagrams with
standard notation
15

Managing technical debt
• The Squad Lead and Architect
were responsible for managing
their squads technical debt
• Every time they needed to take
on technical debt, they were
required to create a backlog
item to pay the debt off and
document the details of the
debt which included the
ongoing impact on SW delivery
i.e. the interest that needs to
be paid until the debt is paid off
• We choose GitHub issues
16

Lessons learned
17

Lessons learned
2. Document architecture in
tools that developers use /
visit frequently.
We found that it was better to document
any Architecture Team artifacts that
were to be consumed by the Build
Squads in GitHub.
Making it easier for the developers to
consume.
1. Evolve the architecture
one iteration at a time.
Decisions made too early are risky.
Make decisions just before you
need them.
Architecting two sprints ahead.
Get comfortable with having to revisit
and change decisions.
18

Lessons learned (continued)
4. The Architecture and Platform
Engineering teams need to
start ahead of ramping up the
Build Squads.
We found that the Architecture and
Platform Engineering teams were
always chasing the Build Squads to
provide guidance and implementation of
cross-cutting components and it is very
difficult to catch up without taking a hit
on the performance of the Build Squads.
3. Don’t dictate to Build Squads
especially if you want them
to have end-to-end ownership
and accountability of the
products they build.
Developers want to make their own
decisions if they are going to be
accountable.
19

References
1. "American Airlines Case Study", ibm.com, 2019. [Online]. Available:
https://www.ibm.com/case-studies/american-airlines. [Accessed: 02- Jan-
2019]
2. K. Brown, S. Daya and D. Lalor, "The role of an architect: Setting
boundaries", ibm.com, 2019. [Online]. Available:
https://www.ibm.com/cloud/garage/content/code/role-of-an-architect.
[Accessed: 02- Jan- 2019]
3. K. Brown, "Build effective squads", ibm.com, 2019. [Online]. Available:
https://www.ibm.com/cloud/garage/content/culture/practice-building-effective-
squads/. [Accessed: 02- Jan- 2019]
4. K. Brown, "Roles in a squad", ibm.com, 2019. [Online]. Available:
https://www.ibm.com/cloud/garage/content/culture/practice-roles-in-a-squad/.
[Accessed: 02- Jan- 2019]
20

References (continued)
5. K. Brown, "Architecture in the development lifecycle", ibm.com, 2019.
[Online]. Available:
https://www.ibm.com/cloud/garage/content/culture/practice-architecture-in-
development-lifecycle/. [Accessed: 02- Jan- 2019]
6. K. Brown, "Pay back technical debt", ibm.com, 2019. [Online]. Available:
https://www.ibm.com/cloud/garage/content/culture/paying-back-technical-
debt. [Accessed: 02- Jan- 2019]
21

Notices and disclaimers
Performance data contained herein was generally obtained in a
controlled, isolated environments. Customer examples are presented
as illustrations of how those customers have used IBM products and
the results they may have achieved. Actual performance, cost,
savings or other results in other operating environments may vary.
References in this document to IBM products, programs, or services
does not imply that IBM intends to make such products, programs or
services available in all countries in which IBM operates or does
business.
Workshops, sessions and associated materials may have been
prepared by independent session speakers, and do not necessarily
reflect the views of IBM. All materials and discussions are provided
for informational purposes only, and are neither intended to, nor shall
constitute legal or other guidance or advice to any individual
participant or their specific situation.
It is the customer’s responsibility to insure its own compliance
with legal requirements and to obtain advice of competent legal
counsel as to the identification and interpretation of any relevant laws
and regulatory requirements that may affect the customer’s business
and any actions the customer may need to take to comply with such
laws. IBM does not provide legal advice or represent or warrant that
its services or products will ensure that the customer follows any law.
© 2018 International Business Machines Corporation. No part of this
document may be reproduced or transmitted in any form without
written permission from IBM.
U.S. Government Users Restricted Rights — use, duplication or
disclosure restricted by GSA ADP Schedule Contract with IBM.
Information in these presentations (including information relating to
products that have not yet been announced by IBM) has been
reviewed for accuracy as of the date of initial publication and could
include unintentional technical or typographical errors. IBM shall have
no responsibility to update this information. This document is
distributed “as is” without any warranty, either express or
implied. In no event, shall IBM be liable for any damage arising
from the use of this information, including but not limited to,
loss of data, business interruption, loss of profit or loss of
opportunity. IBM products and services are warranted per the terms
and conditions of the agreements under which they are provided.
IBM products are manufactured from new parts or new and used
parts.
In some cases, a product may not be new and may have been
previously installed. Regardless, our warranty terms apply.”
Any statements regarding IBM's future direction, intent or
product plans are subject to change or withdrawal without
notice.
22

Notices and disclaimers continued
IBM, the IBM logo, ibm.com and [names of other referenced
IBM products and services used in the presentation] are
trademarks of International Business Machines Corporation,
registered in many jurisdictions worldwide. Other product and
service names might be trademarks of IBM or other
companies. A current list of IBM trademarks is available on
the Web at “Copyright and trademark information” at:
www.ibm.com/legal/copytrade.shtml.
Information concerning non-IBM products was obtained from
the suppliers of those products, their
published announcements or other publicly available
sources. IBM has not tested those products about this
publication and cannot confirm the accuracy of performance,
compatibility or any other claims related to non-IBM products.
Questions on the capabilities of non-IBM products should be
addressed to the suppliers of those products. IBM does not
warrant the quality of any third-party products, or the ability of
any such third-party products to interoperate with IBM’s
products. IBM expressly disclaims all warranties, expressed or
implied, including but not limited to, the implied warranties of
merchantability and fitness for a purpose.
The provision of the information contained herein is not
intended to, and does not, grant any right or license under any
IBM patents, copyrights, trademarks or other intellectual
property right.
23

Thank you
Arun Dhanabal
Senior Manager, American Airlines
—
arun.dhanabal@aa.com
+1-817-931-7477
aa.com
Shahir A. Daya
IBM Distinguished Engineer and CTO, IBM
—
sdaya@ca.ibm.com
+1-416-478-6445
ibm.com
24

A Toolchain for Lean Architecture at American Airlines

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to A Toolchain for Lean Architecture at American Airlines

Similar to A Toolchain for Lean Architecture at American Airlines (20)

Recently uploaded

Recently uploaded (20)

A Toolchain for Lean Architecture at American Airlines