Embed Size (px)
Citation preview
AGILE LONDON MARCH 2016 @STEVE2358 @SIMONTARRY76
TICKETMASTER
2
TICKETMASTER A DIVISION OF LIVE NATION ENTERTAINMENT
3
TICKETMASTER INTERNATIONAL
4
TICKETMASTER INTERNATIONAL
WE SOLVE BIG TECHNICAL CHALLENGES!
WHY TICKETMASTER? 5
Handle huge traffic spikes during on-sales
Build e-commerce platforms that scale
Exploit channel fragmentation
Maximise benefits of SEO and social media
Distinguish between traffic from bots and fans
Take advantage of Big Data
DECK TITLE 6
2010
DECK TITLE 7
2016 2016
THIS HAS GIVEN US THE CONFIDENCE TO TACKLE INDUSTRY PROBLEMS:
DECK TITLE 8
DEVOPS
TECHNICAL DEBT
CAREER PROGRESSION
9
DEV OPS
174 ENGINEERS
45 37
32
19
31 TICKETMASTER INTERNATIONAL
Same levels of understanding and skill
Break down barriers & silos
Align and bring teams closer together
Develop & release quality products fast
Ensure stability & reliability
DEVOPS STRATEGY OBJECTIVES
Delivering business value
Efficiency & quality of development
Reliability of applications & environments
Service delivery
4 GOALS: MAXIMISE FOR
TICKETMASTER DEVOPS MODEL 5 MATURITY LEVELS 1315 VIEWS ON OUR TECH BLOG POST!
DECK TITLE 12
CONTINUOUS DEPLOYMENT & DELIVERY
GOAL1 GOAL2 CONTINUOUS INTEGRATION
HEALTHCHECKS, MONITORING & ALERTING
GOAL3 ORGANISATION & CULTURE
GOAL4
FLEXIBLE ROUTES TO TARGETS
Matrices provided Vision and Targets
All teams have the same targets
Teams can plan routes flexibly
Choices based on needs and value
Routes can change as needs change
STANDARDISATION Simplify Tools & Defined Key Specifications
Less support overhead
Solve problems once
Share knowledge
Provide Guidelines & Best Practices
Shared common understanding
Definition of Terms
Speak the same language
TOOLSET
Git Source Control
Gitlab Source Control
Access
Jenkins Application
Builds
SonarQube Quality Reporting
Nexus Release Package Archive
Rundeck Orchestration
Chef Configuration Management
WHERE ARE WE? CUSTOM TOOL TO VISUALISE PROGRESS
Shows progress by
team
Summary Overview
KPI REPORTING SHOWING VALUE
Closing the
loop
Business Continuity
Process Quality
SDLC Efficiency
WHAT HAVE WE LEARNT?
Standardised Tooling Changes how we do things
Good Reporting Changes how we communicate
Good Communication Changes what we believe in
Internal & External to Engineering
Culture is changing!
19
TECHNICAL DEBT
HOUSTON, WE HAVE A TECH DEBT PROBLEM!
13 PLATFORMS 5M LINES OF CODE 200 COMPONENTS >9000 SERVERS
What problem are we trying to solve?
Why do we care?
1. Definition
Research has anyone else done this?
Filter the data
2. Process
Creation of model
Tooling and data capture 3. Results
Make the data usable
4. Report
WHAT DID WE DO?
What problem are we trying to solve?
Why do we care?
1. Definition
Research has anyone else done this?
Filter the data
2. Process
Creation of model
Tooling and data capture 3. Results
Make the data usable
4. Report
WHAT DID WE DO?
THE PROBLEM IS BIGGER THAN US Industry consensus:
• Technical debt is a big problem
• Software decays over time
• Immature industry
• Technical debt lacks credibility as a term
Costs are significant:
Economic
Maintenance 60/60 rule
Psychological
1. Definition
Historically, software engineering has struggled to articulate the problem to a non-technical audience
WHY DO WE CARE?
EFFICIENCY
TOTAL COST OF OWNERSHIP
DEBT MANAGEMENT
VISIBILITY OF DEBT COST
What problem are we trying to solve?
Why do we care?
1. Definition
Research has anyone else done this?
Filter the data
2. Process
Creation of model
Tooling and data capture 3. Results
Make the data usable
4. Report
WHAT DID WE DO?
RESEARCH FINDINGS KEY FINDING 1: TECHNICAL DEBT AS AN INDUSTRY TERM MEANS THE MAINTAINABILITY OF THE APPLICATION CODE
KEY FINDING 2: INFRASTRUCTURE DEBT ISN'T A GENERALLY WELL KNOWN OR WIDELY USED CONCEPT
KEY FINDING 3: ARCHITECTURE DEBT IS A KNOWN CONCEPT WHICH IS NOT WIDELY USED AND THERE IS NO CONSENSUS ON DEFINITION
• Infrastructure Performance
• Scalability • Infrastructure Security • Infrastructure
Maintainability • Continuity • Repeatability • Documentation • Infrastructure
Complexity
TICKETMASTER TECH DEBT MODEL
Application Debt Infrastructure Debt Architecture Debt • Code coverage • Cyclomatic
Complexity • Application
Performance • Application Security • Application
Maintainability
• Deviation from reference architecture
• Flexibility • Single Points of
Failure • Architecture
Complexity
OUR APPROACH TO SOLVING THIS PROBLEM HAS GENERATED A LOT OF INTEREST 13.5K VIEWS ON OUR BLOG POST
What problem are we trying to solve?
Why do we care?
1. Definition
Research has anyone else done this?
Filter the data
2. Process
Creation of model
Tooling and data capture 3. Results
Make the data usable
4. Report
WHAT DID WE DO?
ARCHITECTURE DEBT RESIDES IN THE DESIGN OF THE ENTIRE SYSTEM
APPLICATION DEBT RESIDES IN THE SOFTWARE PACKAGE
INFRASTRUCTURE DEBT RESIDES IN OPERATING ENVIRONMENTS
HOW WE ARE MEASURING IT?
It is essential that the process for measuring technical debt is: • Repeatable • Transparent • Consistent
We have therefore aimed to automate the collection of as many of the metrics as possible via automated tooling: • Application Debt:
• Code coverage, Cyclomatic complexity, Time to Interact, Application security • Infrastructure Debt:
• Infrastructure performance, scalability The remaining debt metrics are covered by a manual process
AUTOMATED TOOLING
High level component diagram of the platform made visible to the whole team.
Each component discussed one by one to reach consensus among the team on the score (similar to an Agile planning session)
DATA CAPTURE
Each team member scores the components on a pre-agreed scale of 1-5 (low debt to high debt)
Team identify work items required in order to remove/reduce the tech debt from each component
MANUAL MAPPING
Work items ordered according to the priority in which the team feel they should be addressed which would have the greatest impact on day to day development
What problem are we trying to solve?
Why do we care?
1. Definition
Research has anyone else done this?
Filter the data
2. Process
Creation of model
Tooling and data capture 3. Results
Make the data usable
4. Report
WHAT DID WE DO?
MAKE THE DATA USABLE
MAKE THE DATA USABLE
35
Heading: Category and
System
Definition: Each definition is accompanied by
its meaning
Score: Current and
target score is listed Highlight Note:
Main update since last report or highlight note.
Top Items to be addressed: The highest priority items to be
addressed, with risk of not addressing them, benefit of the
work and schedule (if known)
MAKE THE DATA USABLE
36
EXECUTIVE SUMMARY: ROLLED UP SCORE
DETAILED BREAKDOWN
TECHNICAL BACKLOGS
TECH DEBT SUMMARY
14% YOY REDUCTION WHAT WE LEARNT:
- APM IS HARD TO MEASURE
- APPLICATION & INFRASTRUCTURE DEBT CAN BE REDUCED TACTICALLY ALONGSIDE FEATURE WORK
- ARCHITECTURE DEBT NEEDS SIGNIFICANT DEDICATED RESOURCE AND STRATEGIC PLAN TO SHIFT
CAREER MAPPING
DECK TITLE 39
WHERE ARE YOU GOING?
Where do you want to go in your career? How are you going to get there? What do you need to learn? What support is there for your career goals/ambitions? What resources do you need to achieve your goals? What are your next steps?
Engineer
Designer
Builder
Tester Problem
Solver
Architect
WHAT ROLES DO YOU PLAY?
DECK TITLE 41
Engineer
Designer
Design
Builder
Development
Tester
Testing
Problem Solver
Support
Architect
Requirements
HOW DO THESE FIT INTO THE SDLC?
DECK TITLE 42
DECK TITLE 43
Engineer
Maintainer
Organiser
Police
Plumber & Electrician
Quality Control
Interior Designer
Surveyor
WHAT OTHER ROLES DO I PLAY?
Engineer
Maintainer
Process and Lifecycle
Organiser
Configuration Management
Police
Security
Plumber & Electrician
Systems Engineering
Quality Control
Quality
Interior Designer
HCI/UX
Surveyor
Measurements
CROSS CUTTING SKILLS
DECK TITLE 44
DEVELOPING A COMPETENCY MODEL
Map Locations Highway Code
Accounting
Communication Service
Drive Taxi Negotiate Traffic
Collect Fares Competency
What I Know (Knowledge, Best
Practices, etc)
How I Do It (Attitudinal, etc)
What I do (Functions, actions,
activities, etc) Skill Type
Taxi Driver Skills Framework
Map Locations - Level 1 - Know Cities Level 2 Know landmarks Level 3 Know post codes Level 4 Knows streets
Driving - Level 1 Drives set routes Level 2 Selects fastest route Level 3 Selects alternative routes in jams
Communication - Level 1 Courteous Level 2 Interested in Customer Level 3 - Conversational
Capability
Technical Skills Professional Skills Behaviour Skills
ENGINEERING COMPETENCY MODEL
Technical Skills Professional Skills Behaviour Skills
Level 1 Level 2 Level 3 Level 4 Level 5
Level 1 Level 2 Level 3 Level 4 Level 5
Foundation Professional
Advanced Expert
Capability
Design & Coding Level 2
Software Construction - Design & Coding
Level 2
Working with Others Professional
Recognised team player
Software Engineer I
Competency Developer Tech Skills
QA Tech Skills, etc
Application Design Writing Code
Testing
Team Work Communication
Engineering Skills Framework
WHAT HAVE WE BASED PROFESSIONAL SKILLS ON?
CAREER MAPPING 47
WHY? Defines activities rather than specific
skills
Can be applied across a broad range of roles
Mapping is flexible and allows for team variations
An IEEE (Institute of Electrical and Electronics Engineers) standards based framework for software engineering professionals
Drawn together from 7 different best practice reference guidelines and standards
Software Engineering Competency Model - SWECOM
SWECOM FRAMEWORK
QBR Q1 2015 MARCH 2015 48
Design Requirements Development Testing Support
Life
cyc
le
SDLC Lifecycle Skills 5 Knowledge Areas
These are the activities required to create, release and maintain software which is what we DO!
Your core focus will differ depending on your role group
SWECOM FRAMEWORK
QBR Q1 2015 MARCH 2015 49
Design Requirements Development Testing Support
Measurements
Configuration Management
Security
Quality
Systems Engineering
Process & Lifecycle
Life
cyc
le
Cro
ss-C
utt
ing
Cross-cutting skills 7 Knowledge Areas
Activities that traverse the lifecycle skills
Sometimes areas
HCI / UX
BUILDING THE TM FRAMEWORK
QBR Q1 2015 MARCH 2015 50
Life
cyc
le
Cro
ss-C
utt
ing
Design Requirements Development Testing Support
Measurements
Configuration Management
Security
Quality
Systems Engineering
Process & Lifecycle
HCI / UX
QA Developer Front-end Achitects Devops
Technical
Service Excellence
Personal Effectiveness
Team Work
Visioning Process Be
ha
vio
urs
technical and behavioural skills
COMPETENCY FRAMEWORK
DECK TITLE 51
Consistency across roles in engineering teams
Common language of skills
Flexible framework which can be modified as required
Training needs identified
5 levels of requirements,
skills, knowledge, behaviour
TECHNICAL COMPETENCY MATRIX Competency Tools
Capabilities Capabilities Capabilities Capabilities Capabilities
BEHAVIOURAL MATRIX
PROGRESSION GUIDE A consistent set of levels of attainment for each role:
Cross cutting skills (e.g. Security)
SDLC skills (e.g. Development)
Technical skills (e.g. Data storage)
Behavioural skills (e.g. working with others)
Core competencies are highlighted:
These define the skill levels that must be reached in order to progress your career
DECK TITLE 55
DEVOPS
TECHNICAL DEBT
CAREER PROGRESSION
CREATING THE FUTURE OF LIVE ENTERTAINMENT!
Q&A
DECK TITLE 56
THANK YOU Stephen Williams: VP Engineering E: [email protected]
T: @Steve2358
Simon Tarry: Director of Engineering Strategy E: [email protected]
T: @simontarry76
LNEJOBS.COM
