Choice Hotels is undertaking a multiyear, $20 million project to recreate our core business engines on AWS. In trying to approach this complex undertaking, we determined that the project itself is a system too. You can apply principles of good architecture and design work in how you approach the project structure and management. Come to this talk by Choice Hotels’ CTO to learn five key lessons and 20 concrete takeaways that you can implement today to help your AWS projects succeed.
2. 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
3. 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
8. 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
9. 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
10. 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.
11. 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)
12. 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
13. All models are wrong; some models are useful.
--George Box, statistician
15. 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
16. 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.
17. ToDo: If the System Could Do Just One Thing
public interface …What? { …
public interface ReservationService { …
public interface ReservationService {
createReservation { … }
}
public class ReservationServiceImpl implements ReservationService {
…
}
18. 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
19. ToDo: Program Services Middle-Out
API/
Service
Interface
Service
Implementation
DatabaseClient UI
21. 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
25. 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
26. ToDo: Define Your Metrics Early
• Determine how you’ll measure progress
• Bake them into services
27. 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
28. 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?
29. The man who invented the ship
also invented the shipwreck
--Paul Virilio
31. 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
32. ToDo: Perform a Due Diligence
As If You Were Buying Your Own Software
33. 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
35. 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
36. 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
37. ToDo: Define the Cereal Box
Make the full-color
marketing brochure near
the beginning of the
project.
This gives you an
elevator pitch
38. 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
39. 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