Embed Size (px)
Citation preview
© 2015, Amazon Web Services, Inc. or its Affiliates. All rights reserved.
Eben Hewitt, Chief Technology Officer, Choice Hotels International
October 2015
SPOT205
5 Lessons for Managing
Massive IT Transformation Projects
What to Expect from the Session
• Target audience:
• Technical leaders & decision makers
• Managers, project managers, & architects
• Five fantastic, original practices
• Guidance on how to structure, manage, and optimize a
major IT transformation project
• Show how system design and project design can support
each other to maximize throughput
• 20 concrete, actionable takeaways, noted as TODO
Who Am I?
• Chief Technology Officer at Choice Hotels International
• 6,500 hotels in 35 countries
• We represent 12% of all hotel rooms in the US
• $7B per year transacted through our software
• We’re actually kind of a technology company
• 500 people in my organization with $75M budget
• Prior: CIO at O’Reilly Media
• 16 years as developer, architect, leader
• Author of 7 books on software development, architecture
Thesis
The Project itself IS a system.
Therefore, you can design the project according to system
design principles for maximum results.
The Project: choiceEDGE
What is choiceEDGE?
• 3 Year, $20M transformation project to replace
our 25-year-old central reservation system
and related ecosystem of applications
• CRS written in C, monolithic Solaris app, 7-bit ASCII,
proprietary protocol (the web didn’t exist)
• 40 partner integrations
• Retire 13 applications
• Move 3M lines of code and dozens of mission critical systems
to AWS
• Largest project in our 75-year history
Project Goals
• Reduce risks of legacy systems
• Speed time to market, rules-based
• Cloud-based global distribution for massive scalability
• Inventory anything based on perishable duration & warehouse
• US West, US East, Ireland, then Australia
• Support 50M messages per day
• Fully internationalized
• Accessible anywhere, on any device
• Secure PCI Level 1 certification, fully tokenized
• Enable alternate growth as SaaS
AWS Components We’re Using
AWS components we are using:
• Amazon Route 53, Amazon VPC, Elastic Load
Balancing
• Auto Scaling groups
• Amazon EC2, Amazon S3
• Amazon SQS, Amazon SNS, Amazon SWF, IAM,
Amazon RDS (MySQL)
• Our systems transact $8B per year—and we’re putting
our core business engine on it.
AWS Enables…
• Better focus on our business capabilities (and not on datacenter
management)
• Faster delivery of business features
• Global customer reach
• Near infinite capacity
• Near infinite scale
• Better resource planning (time frames)
• Ability to perform infrastructure cost optimizations (CapEx/OpEx)
• Automated recovery (we’re shutting down DR)
• Environmental consistency (dev > qa > sit >prod)
The Problem
• All we knew was “retire the CRS”
• How do we start?
• How do we manage it?
• We know our competitors have spent nearly $100M with
3000 pages of requirements to show
• But we’re going to beta with real software used by real
people
All models are wrong; some models are useful.
--George Box, statistician
Lesson 1: Find the sine qua non
Ask “what is Essential about this thing?”
• A mode of analysis about the components
• What are the necessary, required attributes of this
object in the system?
• What makes it itself?
• What—if you took it away—would make it not itself
anymore, but something else?
• You MUST have it, or there’s no show
ToDo: Start with the Sine Qua Non
• Project level
• Group and place them on your roadmap.
• System & component level
• Fill in the architecture around them.
• Service level
• Program the interfaces early. You have relative certainty they
won’t be designed away.
ToDo: If the System Could Do Just One Thing
public interface …What? { …
public interface ReservationService { …
public interface ReservationService {
createReservation { … }
}
public class ReservationServiceImpl implements ReservationService {
…
}
ToDo: Make a Cookie Cutter
1. Return static data
2. Write a test
3. Compile and deploy
• Forces you to define conventions (HTTP response codes, naming)
• Forces you to continuously aiming for production
• Forces you to design from the outside-in
• Gives you a cookie cutter for all other services
• Principle of least knowledge, but applied to the project level
ToDo: Program Services Middle-Out
API/
Service
Interface
Service
ImplementationDatabaseClient UI
Lesson 2:
Find the
Candy Crush
ToDo: Front Load Things That Open the Most
Opportunities for Change
• What allows other new things to
start?
• (Clears a column)
• What enables the most parallel work?
• Find capability milestones to ship
• A complete business capability
• Retire a legacy system
The Project Plan Designed as a System
ToDo: Short Circuit Your Propositions in Your
Project Plan
if (A || B)
do this
else
do that
Lesson 3: Define what will help
you learn the most the earliest
ToDo: Load Test Early & Often
• We started load testing just a few months in
• Then we tuned our design, updated the cookie cutter
• On AWS infrastructure, we get 1.2M calls/minute
• 6 times performance improvement
• Still improving
ToDo: Define Your Metrics Early
• Determine how you’ll measure progress
• Bake them into services
Poker and The Pareto (80/20) Rule
Ex: 80% of your profits come from 20% of your customers
Ex 2: Poker Basics:
• Learn the hands
• Learn rough idea of the odds
• Fold your worst hands
• Make modest effort to consider what your opponent might hold
Doing only those things will substantially mitigate your
loses
• It means that because of the distribution of the cards,
80% of the time you’ll be making the same decision
as the best poker players on earth,
even though you’ve spent 20% of the time
learning the game as they have.
Therefore: What is the 20% you can learn or do now,
quickly, to be 80% as effective as the ideal?
The man who invented the ship
also invented the shipwreck --Paul Virilio
Lesson 4: Design for Resilience
ToDo: Create a Pre-Mortem
Consider what you do when:
• Events that are supposed to happen don’t
• Events that are not supposed to happen do
• Surprise events that no one thought of occur
ToDo: Perform a Due Diligence
As If You Were Buying Your Own Software
ToDo: Establish a Competency Center
• Enforce standard development platform
• Java 8, Tomcat 8, Cassandra, Active MQ
• Guidelines and design reviews
• Ensure development is uniform between teams
• Reinforce architectural principles
• Ensure wiki is updated
• Help new people learn
• Reinforces team dynamics
Lesson 5:
Make the
Uncertain Certain
ToDo: Define the Architecture Formally
The purpose of architecture is to:
1. Create integrity / contain entropy
2. Show how the design supports the “-ilities”
1. Service catalog
2. Stakeholders actors use cases
3. Constraints, guidelines, patterns
4. Business, data, infrastructure, application architecture
3. Manage trade-Offs
ToDo: Start at the End
• Start with a single, simple, concrete visual of the end state
• “We know we’re done the moment we power down the current
CRS”
• Work backwards from that image
ToDo: Define the Cereal Box
Make the full-color
marketing brochure near
the beginning of the
project.
This gives you an
elevator pitch
Decompose WorkStreams into Services
• What are the nouns & verbs that concern that
WorkStream?
• Guest, Inventory, Shopping
• Further decomposition gives you something to estimate
• Estimate the whole thing
• CapEx, OpEx, Licenses
• This is not textbook agile
• So, not for method bigots
• It IS for people who need the CFO to get their thing done
The Method
• RUP+Scrum+Waterfall
• 18 WorkStreams tracked against budget
• Story-Paloozas
• 2-day planning events with visual story mapping with product
owners
• Creates “fixed-bid” deliverables
• Management itself works as a scrum team
Remember to complete
your evaluations!
Thank you!
