The Start-Up In Your
Enterprise
Our Story of Disruption
Chris Jackson
July 2016
1
qingqing. Shutterstock
Me
2
My Work
Established in 1844
Adaption is in Our History
Inspiring Mission
Passionate People
From ISBN to FQDN
Embrace the Challenge!
3
Organisational Context
4
CIO/COO/CTO
Technology
Operations
Global Product
OPERATIONS
NETWORK
NEW: CLOUD PRODUCT ENGINEERING
DEVELOPMENT
PRODUCT DESIGN
…
SECURITY
QA
EA
A Brief History…
• Internal IT bureaucratic and slow to deliver
• Lack of standards in application design and build
• Spotty adoption of QA and Security standards
• Release process is manual, slow and high-risk
• Absence of collaboration between engineering and ops
• Roadmap planning horizon is 3-years out
A perfect storm is brewing…
5
Our Inception Point
• On the precipice of perpetually failing
• Previous initiatives were huge programs
• Developers running their own tooling
• Business headwinds increasing
• New leadership
• End to end review of tech strategy
6
• Appetite to do something different
• Appetite to do something different
• Appetite to do something different
• Appetite to do something different
• Appetite to do something different
• Appetite to do something different
Introducing Project Bitesize…
Bitesize - Born Different
7
Bitesize - Our Start-Up Story
8
Aug’15
Sep’15
Oct’15
Nov’15
Dec’15
Jan’16
Feb’16
Mar’16
Apr’16
May’16
Jun’16
FOUNDED
CUSTOMER #1
VC ONBOARDED
(Selected as Preferred Platform)
CUSTOMERS #2,3,4
A-SERIES FUNDING
PRODUCTION!
Copyright HBO Entertainment
How
Hard Can
This Be?9
10
PROBLEM #1
Fixing DevOps
“We don’t need Ops, we already have a DevOps team
with Jenkins”
11
PROBLEM #2
What Is the Product?
Understanding what Developers want…
12
PROBLEM #3
Governance
Governance is what
prevails when there is a
vacuum of common sense.
Me, every day…
“
”
13
So What
Did We Do?
Why Containers?
14
Open Source at Pearson
15
Ingress ControllerPython Client Kubernetes Pack
KnowledgeEducation
Sharing Information
Open Source
Sharing Code
Marketing Slide…
16
Accidentally
#serverless
17
Developers
“I need a…”
“I want to…”
Platform API
Developer Tooling
Interfaces/Plugins…
Platform Tooling &
Automation
Global Enabling Functions (TechOps, Security, QA…)
Human feedback loops, reinforce system trust model
Platform API Abstraction
18
Security Engineer
Network Engineer
Testing Engineer
Project Manager
Architect
Application Engineer
Cloud
Platform
Engineering
Global PMO
Enterprise Architecture
Customer Teams
CISO Group
Global Network
Global QA Group
A Vehicle for Enabling Functions
Application Developer Community
DevOps Target For Pearson
19
Global Technical Community
Community
Engagement
Developer
Experience
Next-Generation Application Platform
Best Practice
and Standards
Initiatives
New Technology
Adoption &
Integration
Hackathons,
Brown Bags
and Meetups
“Do we already
have a … I can
contribute to”
If This… Then That - The New Operations
20
Things that Happen Desired Response Mechanism to Execute
Stuff People Care About Stuff People Concentrate On
Trigger Systems Workflows
Tooling
“A synthetic transaction is failing”
“I want to deploy my application”
“Our A/B soak completed
successfully”
…
Re-spawn pods, notify owners
Execute deployment process
Converge all production instances to
B deployment
…
Cognitive Learning & Decision Making
Systems (e.g. Watson)
Long Term Vision
21
Trigger Systems
Log Analytics, Monitoring, SOC…
Operational Run Books
Codified and On-Demand
Service/App Metadata
Service Registry/Discovery
A Sentient Managed Service..?
WHERE WE
NEED HELP
22
Areas for Breakout Discussion
23
• How does our Startup manage “hyper-growth”?
• When does DevOps it stop being DevOps?
• How do we recognise productivity gains vs cost savings?
• Skill transformation, how do we engage Pearson’s veterans?
• Setting the maturity bar, how do we qualify Platform suitability?
Get Involved?
https://github.com/orgs/pearsontechnology/
More coming soon…!
@chriswiggy
We’re hiring… http://pearson-technology.jobs/
24
DOES16 London -  Chris Jackson - Disrupting an Enterprise from the Inside

DOES16 London - Chris Jackson - Disrupting an Enterprise from the Inside

  • 1.
    The Start-Up InYour Enterprise Our Story of Disruption Chris Jackson July 2016 1 qingqing. Shutterstock
  • 2.
  • 3.
    My Work Established in1844 Adaption is in Our History Inspiring Mission Passionate People From ISBN to FQDN Embrace the Challenge! 3
  • 4.
    Organisational Context 4 CIO/COO/CTO Technology Operations Global Product OPERATIONS NETWORK NEW:CLOUD PRODUCT ENGINEERING DEVELOPMENT PRODUCT DESIGN … SECURITY QA EA
  • 5.
    A Brief History… •Internal IT bureaucratic and slow to deliver • Lack of standards in application design and build • Spotty adoption of QA and Security standards • Release process is manual, slow and high-risk • Absence of collaboration between engineering and ops • Roadmap planning horizon is 3-years out A perfect storm is brewing… 5
  • 6.
    Our Inception Point •On the precipice of perpetually failing • Previous initiatives were huge programs • Developers running their own tooling • Business headwinds increasing • New leadership • End to end review of tech strategy 6 • Appetite to do something different • Appetite to do something different • Appetite to do something different • Appetite to do something different • Appetite to do something different • Appetite to do something different Introducing Project Bitesize…
  • 7.
    Bitesize - BornDifferent 7
  • 8.
    Bitesize - OurStart-Up Story 8 Aug’15 Sep’15 Oct’15 Nov’15 Dec’15 Jan’16 Feb’16 Mar’16 Apr’16 May’16 Jun’16 FOUNDED CUSTOMER #1 VC ONBOARDED (Selected as Preferred Platform) CUSTOMERS #2,3,4 A-SERIES FUNDING PRODUCTION! Copyright HBO Entertainment
  • 9.
  • 10.
    10 PROBLEM #1 Fixing DevOps “Wedon’t need Ops, we already have a DevOps team with Jenkins”
  • 11.
    11 PROBLEM #2 What Isthe Product? Understanding what Developers want…
  • 12.
    12 PROBLEM #3 Governance Governance iswhat prevails when there is a vacuum of common sense. Me, every day… “ ”
  • 13.
  • 14.
  • 15.
    Open Source atPearson 15 Ingress ControllerPython Client Kubernetes Pack KnowledgeEducation Sharing Information Open Source Sharing Code
  • 16.
  • 17.
    Accidentally #serverless 17 Developers “I need a…” “Iwant to…” Platform API Developer Tooling Interfaces/Plugins… Platform Tooling & Automation Global Enabling Functions (TechOps, Security, QA…) Human feedback loops, reinforce system trust model
  • 18.
    Platform API Abstraction 18 SecurityEngineer Network Engineer Testing Engineer Project Manager Architect Application Engineer Cloud Platform Engineering Global PMO Enterprise Architecture Customer Teams CISO Group Global Network Global QA Group A Vehicle for Enabling Functions Application Developer Community
  • 19.
    DevOps Target ForPearson 19 Global Technical Community Community Engagement Developer Experience Next-Generation Application Platform Best Practice and Standards Initiatives New Technology Adoption & Integration Hackathons, Brown Bags and Meetups “Do we already have a … I can contribute to”
  • 20.
    If This… ThenThat - The New Operations 20 Things that Happen Desired Response Mechanism to Execute Stuff People Care About Stuff People Concentrate On Trigger Systems Workflows Tooling “A synthetic transaction is failing” “I want to deploy my application” “Our A/B soak completed successfully” … Re-spawn pods, notify owners Execute deployment process Converge all production instances to B deployment …
  • 21.
    Cognitive Learning &Decision Making Systems (e.g. Watson) Long Term Vision 21 Trigger Systems Log Analytics, Monitoring, SOC… Operational Run Books Codified and On-Demand Service/App Metadata Service Registry/Discovery A Sentient Managed Service..?
  • 22.
  • 23.
    Areas for BreakoutDiscussion 23 • How does our Startup manage “hyper-growth”? • When does DevOps it stop being DevOps? • How do we recognise productivity gains vs cost savings? • Skill transformation, how do we engage Pearson’s veterans? • Setting the maturity bar, how do we qualify Platform suitability?
  • 24.
    Get Involved? https://github.com/orgs/pearsontechnology/ More comingsoon…! @chriswiggy We’re hiring… http://pearson-technology.jobs/ 24

Editor's Notes

  • #2 What is an “end to end stack”? When you include people, the technology takes a back seat - I had a lot of “yup” moments listening to Jez this morning So this talk is as much about getting an initiative off the ground as it is about a showcase of cool tech
  • #3 Ex-Racker Frustrated Coder Education Disrupter Reformed Leader This… @chriswiggy Tell the story of realising that my aspirations to be an engineer lead me to being a leader… I succeed through others Expectation set - this means I may not have all the technical details some of you may crave! My mentality - why not?
  • #4 Pearson PLC was incorporated the same year Samuel Morse invented the code that inherited his name - thats over 170 years ago Its a job with high moral fibre Digital transformation to a global education platform Good place for someone who’s mentality is “why not”!!
  • #5 How we’re structure Self service, highly done automation, very approachable service teams; consult and help and optimize and support Consult vs. open heart surgery PaaS: continuous delivery pipeline; how do we give developers an 80% experience; runtimes and containers VMs -> containers is a couple lines of config changes 1 person is COO/CIO/CTO Team of SVPs who runs tech ops (enterprise IT) VP hosting/delivery; I work for him; all next generation infrastructure comes from my team 8 engineers across US and UK; we spend a lot of
  • #6 Insert large enterprise logo here right? Umbrella company: Used to buy companies: production company for Baywatch! Pay off 20-30 years of M&A debt 7 different Ops models: traditional Ops problems, but supersized into AWS (running on unreliable commodity gear: not “HA, won’t go down”): driven by a CTO, “move everything to AWS”; circa 2012: led to backlash to governance and controls; then tried to build competitor (“private cloud”): “enterprise virtualization with API”; fundamentally wasn’t fit for purpose Walked into Pearson where everyone actively hates IT; “not just passive aggressive disdain, active hate” Can’t just embed Ops into Dev teams; they’ll just go native
  • #7 Outline the chat we had that started this all. Here is how we snatched victory from the jaws of defeat…
  • #8 From day one of our pilot, we’ve tried to be different… not for the sake of trying to aggravate and upset people, but because we need to break the short circuits happening inside talented people We’re a startup inside an enterprise… Our job is to disrupt sustainably from the inside.
  • #9 Why did we get approved? containerisation: densification of hosting estate developer productivity recognition that we needed to innovate more to go digital
  • #10 This is why we call it Bitesize
  • #11 In large enterprise, every word gets one shot; if it doesn’t work, and it didn’t work; we already broke private cloud and DevOps We had turned DevOps in to a justification for another Silo We found this wasn’t about a resistance to DevOps, it was a resistance to current operations. For us, starting our transformation was about admitting mistakes and re-establishing credibility. Make the effort and earn trust/respect… you’ll have credit in the bank when you need to spend it. Example from this week - perf testing Self-preservation based on fear of failure
  • #12 If you have a product, who is your customer? How do you generate developer engagement - who are we competing with? Developers want DIY but not do everything Self-service but do it for me Don’t get me out of bed at 3am And I don’t want to wait for any of this AND I reserve the right to change this at any time…
  • #13 Water-scrum-fall Capital asset programmes PMO Funding model: traditional Pearson wants a 5 year plan, write of costs against planned benefits; but I don’t know what I’ll be doing in 5 months, let alone 5 years We’re one of a few strategic programs, with capex and opex, which other leaders must support; we capitalize as much as we can; long term, we’ll need funding from dev groups, right? Currently, no mechanism to do chargeback/chargethrough
  • #15 When you’re coming to the party late, you’d better bring something interesting We need infrastructure as code, easy to change, easy to test, easy to ship One of the few benefits of being so late to the market is we can skip stuff others tried already - Config management, state management, metadata fragmentation… Macro-scale, we’re trying to simplify and standardise Pearson: less natural mutation in containers We need to globally deploy, a container is a unit of deployment that we can consider a standard as it is reproducible as long as our platform layer is consistent
  • #16 The affinity with education and OSS around sharing knowledge is undeniable We’re embracing open source because: Its cheap We attract better engineers It sets expectations about what we need to be capable of internally The more we share, the more open we become, the more we share problems
  • #17 Simple goal - standardised delivery pipeline capable of delivering a consistent application binary to any cloud platform anywhere in the world Automatically… explain cycle time - didn't want to scare them!!!
  • #18 DevOps per page 1 of the textbook won’t scale 400+ dev teams != 400 DevOps!! Our product aims to deliver a no-ops experience to a user, when in reality it couldn’t be further from the truth What do our people do with the time? Build relationships, reinforce feedback loops with deeper human interaction
  • #20 DevOps per page 1 of the textbook won’t scale 400+ dev teams != 400 DevOps!! Our product aims to deliver a no-ops experience to a user, when in reality it couldn’t be further from the truth What do our people do with the time? Build relationships, reinforce feedback loops with deeper human interaction
  • #21 simple yaml workflows - > how do we want Pearson/app/platform to respond when X happens… Stackstorm By looking at trigger and action, we don’t care what tool we need and we can change it with minimal overhead Designing the abstraction of this is key, simple API/Provider model The future of operations is more engineering…
  • #22 Pearson’s motto is “Always Learning” - we’re applying that to our platform, how do we build a learning platform to avoid incidents and points where customers will get a less than desirable experience?