3. “Our application is
unreliable, and we
spend too much time on
things our users will
never see”
“License, and hardware
costs are too high and
we need to save
money”
“Change takes too long
to make it’s way into
production”
Why transform applications?
4. DEFINE THE VALUE STREAM AND IDENTIFY
PORTFOLIO LEVEL METRICS
USE OKRs AT AN EXECUTION AND
PROJECT LEVEL TO INFORM
PORTFOLIO ROI
REPLATFORM > MODERNIZE > OPTIMIZE
ESTABLISH, MEASURE AND UPDATE
KEY OBJECTIVES AND RESULTS (OKRs)
SPEED & AGILITY STABILITY
SCALABILITY SAVINGS
$SECURITY
40-60%*
More Projects With
Same Staff
Millions
Annual Savings on
HW, SW and
Support
25-50%*
Fewer Support
Incidents
400%*
Faster Patching
Delivery @ Zero
Downtime
-90%*
Time to Scale
$
$
%
* Some examples based on customer feedback
How we think about return on investment
5. The 12 Factor Application
I. Codebase One codebase tracked in revision control, many deploys
II. Dependencies Explicitly declare and isolate dependencies
III. Config Store config in the environment
IV. Backing services Treat backing services as attached resources
V. Build, release, run Strictly separate build and run stages
VI. Processes Execute the app as one or more stateless processes
VII. Port binding Export services via port binding
VIII. Concurrency Scale out via the process model
IX. Disposability Maximize robustness with fast startup and graceful shutdown
X. Dev/prod parity Keep development, staging, and production as similar as possible
XI. Logs Treat logs as event streams
XII. Admin processes Run admin/management tasks as one-off processes
https://12factor.net/
6. Value stream mapping
https://www.safaribooksonline.com/library/view/lean-enterprise/9781491946527/part03ch02.html
Step name Name of the discrete activity
Actor Name of the team or function that performs the
step
Lead time (LT) Time from the point a process accepts a piece of
work to the point it hands that work off to the next
downstream process
Process time (PT) Time it would take to complete a single item of
work if the person performing it had all the
necessary information and resources to complete
it and could work uninterrupted
Optional: Percent
complete and
accurate (%C/A)
Proportion of times a process receives
something from an upstream process that it can
use without requiring rework
Optional:
Throughput (TP)
The concurrency / queue depth between Steps
7. 4. CLOUD NATIVE
3. CLOUD RESILIENT
2. CLOUD FRIENDLY
1. CLOUD READY
Distributed, API and microservice architectures
running on time-tested technology like PCF,
Spring Boot and Spring Cloud Services.
A 12-factor app with full metrics and
monitoring, running on PCF that includes
backing data services, automated failure
testing & elastic scale.
A Cloud aware app built using 12-factor
principals that takes advantage of Cloud for
scale and resiliency
Generally an app 0 to 7 years old that uses
tech supported by the CF ecosystem and built
in a modern, service-oriented manner
All new apps
built Cloud
Native
Replatform
existing apps to
run on PCF
Incrementally
modernize and
gain additional
benefits
Cloud-Native maturity model
8. Understanding your application portfolioTECHNICALCONDITION
BUSINESS VALUEWORSE BETTER
WORSEBETTER
Tolerate Invest
MigrateEliminate
Focus here and start with the most
impactful custom apps built 0 to 7
years ago with supported tech
Understand:
â—Ź Technical condition (Y-Axis), e.g.
â—‹ Scalability
â—‹ Performance
â—Ź Business value, (X-Axis)e.g.
â—‹ Criticality
â—‹ Competitive advantage
â—Ź Operational cost (Size), e.g.
â—‹ License
â—‹ Hardware
â—Ź Risk (Colour), e.g.
â—‹ Compliance
â—‹ Skill set
9. The incremental applications journey
RUNS ON
EXISTING IT
RUNS ON
PIVOTAL CLOUD
FOUNDRY
RUNS WELL ON
PIVOTAL CLOUD
FOUNDRY
RUNS GREAT ON
PIVOTAL CLOUD
FOUNDRY
GREENFIELD,
CLOUD NATIVE
APP DEVELOPMENT
Your Existing Apps
Running on Current-Era
Stacks Supported by
Time-Tested People and
Process
APPS REPLATFORMING
Suitable Apps Moved to
PCF with Minimal Code
Change; Better Ops
Thanks to Platform
Automation
OPS & ORG TRANSFORMATION
PIVOTAL LABS ENGAGEMENT
Legacy Apps Refactored
Using 12-Factor Principles
and Modern Software
Process (TDD, CI/CD),
Optimized for PCF
Cross-Functional Teams
Delivering Continuous
Software Updates Into
PCF End-to-End Through
Modern Principles
Your People Paired With Us in
Our Lab Building Modern
Software from the Ground Up
APPS MODERNIZATION
10. USUALLY EASY MODERATE EFFORT MORE EFFORT
V. Build, Release, Run*
XI. Logs*
X. Environmental Parity*
VII. Port Binding*
I. One Codebase, One App*
II. Dependency Management*
IX. Disposability
XII. Administrative Process
VIII. Concurrency
III. Configuration*
IV. Backing Services
VI. Process
IN OUR EXPERIENCE YOU’LL NEED 5-7 OF THE
12-FACTORS TO GET AN APP BUILT IN THE LAST
0-7 YEARS RUNNING ON PCF
Importance and effort of the “12-Factors”
11. Key techniques to transition your portfolio
APP
APP
APP
µService
µService
µService
APP
APP
APP
APPLICATION REPLATFORMING APPLICATION MODERNIZATION
The “Push” Approach The “Pull” Approach
1. Push the app
2. See what fails
3. Write a test
4. Get the tests to pass
5. Write down your recipes
1. Find the seams
2. Carve out features into microservices
3. Build interop code around seams
4. Write tests
5. Get your tests to pass
APP
APP
12. Start the journey here
APP
APP
APP
APP
1
Identify 5-10 apps / domains
confirmed as suitable to run
on PCF
2
Push a few apps all the way to prod while
enabling the team and delivering a
cookbookSampleToolChain
Gitlab ArtifactoryConcourse
(API Driven)
Getting apps to run on PCF is easy. Policy, regulation, manual process, organization and politics is hard. Tackling
these things can take time so let’s start right away. Let’s really dig into the path to prod and define the value stream.
Identify the manual process and bottlenecks. Figure out how we measure near-term success. Do it with working code.