We go to conferences & get excited about things that could revolutionize our development & change our organization! Then, we go home...and hit the wall. If you've ever asked yourself, "This stuff is cool, but HOW CAN I GET MY COMPANY TO DO IT??!", this is the session for you. Learn from an experienced software developer (who also happens to have an MBA) how to make your case to leadership.

1. This stuff is cool, but…
HOW CAN I GET MY COMPANY TO DO IT?
Businessing the S*** out of Transformative Development!
Mark Heckler
Principal Technologist/Developer Advocate
Pivotal Software, Inc.
www.thehecklers.org
mark@thehecklers.org
@MkHeck
@MkHeck

2. @MkHeck
Who am I?

3. @MkHeck
Who am I?
• Author
• Speaker
• DEVELOPER
• Seeker of a better way
• MBA

4. @MkHeck

5. @MkHeck
The Goal

6. @MkHeck
Disclaimers

7. @MkHeck
Disclaimers
• I’m human

8. @MkHeck
Disclaimers
• I’m human
• Measurements require assumptions…

9. @MkHeck
Disclaimers
• I’m human
• Measurements require assumptions…
• …but those will be clearly stated and quantified

10. @MkHeck
Disclaimers
• I’m human
• Measurements require assumptions…
• …but those will be clearly stated and quantified
• Estimate benefits conservatively, costs liberally

11. @MkHeck
Disclaimers
• I’m human
• Measurements require assumptions…
• …but those will be clearly stated and quantified
• Estimate benefits conservatively, costs liberally
• The numbers you see are EXAMPLES

12. @MkHeck
Disclaimers
• I’m human
• Measurements require assumptions…
• …but those will be clearly stated and quantified
• Estimate benefits conservatively, costs liberally
• The numbers you see are EXAMPLES
• Adjust sensibly for your circumstances

13. @MkHeck
With great power…

14. @MkHeck
What’s on the agenda?

15. @MkHeck
What’s on the agenda?

16. @MkHeck
What’s on the agenda?
• Payback

17. @MkHeck
What’s on the agenda?
• Payback
• Net Present Value (NPV)

18. @MkHeck
What’s on the agenda?
• Payback
• Net Present Value (NPV)
• Quantification

19. @MkHeck
What’s on the agenda?
• Payback
• Net Present Value (NPV)
• Quantification
• Based upon (solid, well-reasoned, calculated) assumptions

20. @MkHeck
What’s on the agenda?
• Payback
• Net Present Value (NPV)
• Quantification
• Based upon (solid, well-reasoned, calculated) assumptions
• Several steps to get there, but don’t panic!

21. @MkHeck

22. @MkHeck
Payback: Formula
Cost of Project
Annual Cash Inflow (or Savings)
= Payback Period

23. @MkHeck
Payback: Example
$500,000 (costs)
$200,000/year (new income)
= 2.5 years

24. @MkHeck
Payback: Explanation

25. @MkHeck
Payback: Explanation
• Shorter payback period generally better

26. @MkHeck
Payback: Explanation
• Shorter payback period generally better
• Longer payback means more uncertainty, greater risk

27. @MkHeck
Payback: Explanation
• Shorter payback period generally better
• Longer payback means more uncertainty, greater risk
• Prefer < 3 years payback period

28. @MkHeck
Payback: Explanation
• Shorter payback period generally better
• Longer payback means more uncertainty, greater risk
• Prefer < 3 years payback period
• Payback < 1 year == essential project

29. @MkHeck
Payback: Drawbacks

30. @MkHeck
Payback: Drawbacks
• No consideration of total value

31. @MkHeck
Payback: Drawbacks
• No consideration of total value
• 3 year payback, no further value after year 5, lifetime value: $250,000

32. @MkHeck
Payback: Drawbacks
• No consideration of total value
• 3 year payback, no further value after year 5, lifetime value: $250,000
• 5 year payback, ongoing value, lifetime value: $1,000,000

33. @MkHeck
Payback: Drawbacks
• No consideration of total value
• 3 year payback, no further value after year 5, lifetime value: $250,000
• 5 year payback, ongoing value, lifetime value: $1,000,000
• Which would you choose?

34. @MkHeck
Payback: Drawbacks
• No consideration of total value
• 3 year payback, no further value after year 5, lifetime value: $250,000
• 5 year payback, ongoing value, lifetime value: $1,000,000
• Which would you choose?
• No consideration of time value of money

35. @MkHeck
Payback: Drawbacks
• No consideration of total value
• 3 year payback, no further value after year 5, lifetime value: $250,000
• 5 year payback, ongoing value, lifetime value: $1,000,000
• Which would you choose?
• No consideration of time value of money
• Good measure, but incomplete

36. @MkHeck
Net Present Value (NPV): Formula
Net Period Cash Flow
(1+R)T
= NPV∑
where R is the Rate of Return
and T is the number of time periods

37. @MkHeck
Net Present Value (NPV): Example 1
$1,000,000
(1+0.05)5
= $783,526∑
where R is the Rate of Return
and T is the number of time periods

38. @MkHeck
Net Present Value (NPV): Example 2
= $646,206
$200,000
(1+0.04)2
$400,000
(1+0.03)3
$100,000
(1+0.05)1
++
$184,911 $366,057$95,238

39. @MkHeck
Inputs & Associated Challenges

40. @MkHeck
Inputs & Associated Challenges
• Quantifying qualitative measures

41. @MkHeck
Inputs & Associated Challenges
• Quantifying qualitative measures
• How would this initiative:
• affect your organization’s/group’s/team’s work?
• impact your tech stack?
• contribute to recruitment/retention?
• affect the business?

42. @MkHeck
Putting Numbers with It: Pros & Cons

43. @MkHeck
Putting Numbers with It: Pros & Cons
• Pros
• Critical analysis yields better understanding of inputs, impacts
• Can provide more objective and compelling justification for initiative

44. @MkHeck
Putting Numbers with It: Pros & Cons
• Pros
• Critical analysis yields better understanding of inputs, impacts
• Can provide more objective and compelling justification for initiative
• Cons
• Can be very time-consuming
• No automatic conversion between qualitative & quantitative measures

45. @MkHeck
Putting Numbers with It: Caveats

46. @MkHeck
Putting Numbers with It: Caveats
• Time is a constraint

47. @MkHeck
Putting Numbers with It: Caveats
• Time is a constraint
• Assumptions form basis of conclusions
• Bad assumptions -> Inaccurate conclusions
• Good assumptions -> (In?)accurate conclusions

48. @MkHeck
Putting Numbers with It: Caveats
• Time is a constraint
• Assumptions form basis of conclusions
• Bad assumptions -> Inaccurate conclusions
• Good assumptions -> (In?)accurate conclusions
• Document assumptions meticulously

49. @MkHeck
Putting Numbers with It: Caveats
• Time is a constraint
• Assumptions form basis of conclusions
• Bad assumptions -> Inaccurate conclusions
• Good assumptions -> (In?)accurate conclusions
• Document assumptions meticulously
• Be open to discussion, refinement

50. Let’s run through it
(Optional<Suit>)

51. Microservices
Assemble to make
“more than meets the eye”

52. @MkHeck
Notes about Microservice Architectures

53. @MkHeck
Notes about Microservice Architectures
• “Return on Investment (ROI) is driven by accelerated realization of
benefits rather than overall business transformation.”

54. @MkHeck
Notes about Microservice Architectures
• “Return on Investment (ROI) is driven by accelerated realization of
benefits rather than overall business transformation.”
• Reduced maintenance costs?

55. @MkHeck
Notes about Microservice Architectures
• “Return on Investment (ROI) is driven by accelerated realization of
benefits rather than overall business transformation.”
• Reduced maintenance costs?
• Increased business opportunities through new APIs?

56. @MkHeck
Notes about Microservice Architectures
• “Return on Investment (ROI) is driven by accelerated realization of
benefits rather than overall business transformation.”
• Reduced maintenance costs?
• Increased business opportunities through new APIs?
• Selective scaling of only high-demand microservices reduces costs

57. @MkHeck
Notes about Microservice Architectures
• “Return on Investment (ROI) is driven by accelerated realization of
benefits rather than overall business transformation.”
• Reduced maintenance costs?
• Increased business opportunities through new APIs?
• Selective scaling of only high-demand microservices reduces costs
• Investment includes upskilling/coaching/mentoring

58. @MkHeck
Expectations

59. @MkHeck
Expectations
• Small batch sizes, small teams: Microservices
• Bounded contexts
• API-based contracts for interactions
• More functionality delivered to market (or internal end-users) sooner
• Building the right product (tight dev loop == tight feedback loop)

60. @MkHeck
Expectations

61. @MkHeck
Expectations
• Microservices (continued)
• Improved quality; small mods vs. major overhauls
• Improved end-user satisfaction
• Small, frequent releases expose & help resolve process issues “in the
small”
• When releases are tiny, well-planned & -choreographed events, they
can happen at will

62. Monoliths
That’s one big app!

63. @MkHeck
Assumptions: monoliths

64. @MkHeck
Assumptions: monoliths
• Average cadence of releases of key monolithic apps: 1x/year*
• 10 months of development before “code freeze”
• 1 month of integration testing, bug fixes
• 1 month of UAT (confirmations, course corrections, logging “new”
requirements)
*optimistic in many cases

65. Microservices
Assemble to make
“more than meets the eye”

66. @MkHeck
Assumptions: microservices

67. @MkHeck
Assumptions: microservices
• Average cadence of microservices releases: 7448x/DAY*
• If your company is 1/1000th (0.1%) as effective as Amazon, that’s still
> 7 releases/day…over 2500 releases/year!
• 14 new microservices in first year
• Each of your Y1 microservices averages a release every other day
*Amazon: 1 every 11.6s in 2011 - YMMV!

68. @MkHeck
Assumptions: microservices

69. @MkHeck
Assumptions: microservices
• How much more functionality can be delivered more quickly, more
accurately?

70. @MkHeck
Assumptions: microservices
• How much more functionality can be delivered more quickly, more
accurately?
• If you can approach zero with missed requirements, missed
opportunities, missed expectations…how much is that worth?

71. @MkHeck
Assumptions: microservices
• How much more functionality can be delivered more quickly, more
accurately?
• If you can approach zero with missed requirements, missed
opportunities, missed expectations…how much is that worth?
• If users can have needed functionality MONTHS or YEARS sooner, what is
that worth to your company?

72. @MkHeck
Quantification

73. @MkHeck
Quantification
• Volatile functionality
• Sales drivers
• Product development/engineering

74. @MkHeck
Quantification
• Volatile functionality
• Sales drivers
• Product development/engineering
• Focus upon producing key abilities, define interfaces in monolith
• Average time to get interface APIs “live”: 6 months
• Average business size: $500m annual revenue
• Impact of high-demand projects implemented via microservices: $1m/microservice

75. @MkHeck
Quantification
*would increase costs and resultant cash flows
**assumes some functionality would be implemented otherwise in monolith
($1m)
($2m)
($5m)

76. @MkHeck
Quantification
• Costs
• Upskilling required for relevant tech teams
• Ramp-up - offset by avoidance of contextualization issues
• Other things that may smooth/speed path omitted*
• Platform costs and interface development
• Foregone revenue from monolith implementation**
*would increase costs and resultant cash flows
**assumes some functionality would be implemented otherwise in monolith
($1m)
($2m)
($5m)

77. @MkHeck
Totals, Year 1
New revenues, year 1 $14m
Expenses
Upskilling ($1m)
Platform costs ($1m)
Interfaces ($1m)
Opportunity costs ($5m)
Y1 NET GAIN/LOSS FROM ADOPTION $6m

78. @MkHeck
Annual Cash Inflow (or Savings)
Cost of Project
Payback: Microservices
= Payback Period

79. @MkHeck
Annual Cash Inflow (or Savings)
8,000,000
Payback: Microservices
= Payback Period

80. @MkHeck
14,000,000
8,000,000
Payback: Microservices
= Payback Period

81. @MkHeck
6.86 months
14,000,000
8,000,000
Payback: Microservices
=

82. @MkHeck
6.86 months
14,000,000
8,000,000
Payback: Microservices
=
APPROVED!

83. Not so fast…

84. @MkHeck
Totals, Year 1
New revenues, year 1 $14m
Expenses
Upskilling ($1m)
Platform costs ($1m)
Interfaces ($1m)
Opportunity costs ($5m)
Y1 NET GAIN/LOSS FROM ADOPTION $6m

85. @MkHeck
Y2 Assumptions

86. @MkHeck
Y2 Assumptions
• Double number of microservices added in Y2 vs. Y1
• 14 new in Y1 + 28 new in Y2 = 42 new microservices @EOY2

87. @MkHeck
Y2 Assumptions
• Double number of microservices added in Y2 vs. Y1
• 14 new in Y1 + 28 new in Y2 = 42 new microservices @EOY2
• Estimate slightly reduced impact, may be overly pessimistic
• 28 * $750k = $21m $14m + $21m = $35m “new” revenue

88. @MkHeck
Y2 Assumptions
• Double number of microservices added in Y2 vs. Y1
• 14 new in Y1 + 28 new in Y2 = 42 new microservices @EOY2
• Estimate slightly reduced impact, may be overly pessimistic
• 28 * $750k = $21m $14m + $21m = $35m “new” revenue
• Assume linear ability to expand monolith, may be overly optimistic
• $10m worth of functionality could be implemented in monolith

89. @MkHeck
Totals, Year 2
New revenues, year 2 $35m
Expenses
Upskilling ($1m)
Platform costs ($2m)
Interfaces ($1m)
Opportunity costs ($10m)
Y2 NET GAIN/LOSS FROM ADOPTION $21m

90. @MkHeck
Y3 Assumptions

91. @MkHeck
Y3 Assumptions
• Double number of microservices added in Y3 vs. Y2
• 42 @EOY2 + 56 new in Y3 = 98 new microservices @EOY3

92. @MkHeck
Y3 Assumptions
• Double number of microservices added in Y3 vs. Y2
• 42 @EOY2 + 56 new in Y3 = 98 new microservices @EOY3
• Estimate further reduced impact, may be overly pessimistic
• 56 * $500k = $28m $35m + $28m = $63m “new” revenue

93. @MkHeck
Y3 Assumptions
• Double number of microservices added in Y3 vs. Y2
• 42 @EOY2 + 56 new in Y3 = 98 new microservices @EOY3
• Estimate further reduced impact, may be overly pessimistic
• 56 * $500k = $28m $35m + $28m = $63m “new” revenue
• Assume linear ability to expand monolith, may be overly optimistic
• $15m worth of functionality could be implemented in monolith

94. @MkHeck
Totals, Year 3
New revenues, year 3 $63m
Costs
Upskilling ($1m)
Platform costs ($6m)
Interfaces ($1m)
Opportunity costs ($15m)
Y3 NET GAIN/LOSS FROM ADOPTION $40m

95. @MkHeck
NPV: Microservices
= $61,086,277
$21m
(1+0.05)2
$40m
(1+0.05)3
$6m
(1+0.05)1
++
$19,954,649 $35,417,342$5,714,286

96. @MkHeck
NPV: Microservices
= $61,086,277
$21m
(1+0.05)2
$40m
(1+0.05)3
$6m
(1+0.05)1
++
$19,954,649 $35,417,342$5,714,286
APPROVED!

97. @MkHeck
Factors Revisited

98. @MkHeck
Factors Revisited
• Quantifying qualitative measures

99. @MkHeck
Factors Revisited
• Quantifying qualitative measures
• How would this initiative:
• affect your organization’s/group’s/team’s work?
• impact your tech stack?
• contribute to recruitment/retention?
• affect the business?

100. @MkHeck
In summary…

101. @MkHeck
In summary…
• Critical analysis yields better understanding of inputs, impacts
• Can provide more objective and compelling justification for initiative
• Be honest
• Document & communicate assumptions clearly
• Be open to course corrections

102. @MkHeck
This is Not the Enemy!

103. @MkHeck
This is Not the Enemy!They are your Allies

104. @MkHeck
Thank You for Participating!
Keep the conversation going:
• @MkHeck
• mark@thehecklers.org