>“I think some of my best conversations came through finding ways to respectfully ask those whys and trying to learn more about the process and why we were doing certain things, and really just diving into some of those uncomfortable situations,” said Liberty Mutual’s LeBlanc about her Pivotal Labs engagement. “But respectfully pushing back and sharing my perspectives, as well, ended up helping us learn so much more because we weren’t just taking it all in. We were really trying to understand the whole process.”
00:00 – The agenda. 02:14 – Less leadership, more technocracy. 20:38 – kube.academy. 21:54 – tanzu.vmware.com/developer 23:01 – Pets for your pets. 28:34 – Geting started with your transformation strategy. 30:35 – Bye, bye!
If you’re starting your app modernization plans with the biggest, most critical app you can find, you’re probably stumbling through the drunk under the lamppost app modernization anti-pattern. Chances are, you’ll also encounter a lot of resistance and excuses to avoid changing. Also, I discuss saying “no” more as a way to think about prioritization. Bonus topic: deep-fried bread in The Netherlands.
00:00 – Agenda. 01:49 – The drunk under the lamppost anti-pattern. 15:09 – Start planning your app modernization journey. 18:07 – Saying “no.” 25:12 – “Too many salads.” 30:23 – Learn kubernetes, free! 32:07 – Gartner on IT strategy “turns.” 35:51 – Free developer education & bye, bye!
“With in-house development and acquisitions, FedEx would bolt on technologies resulting in an ‘accidental architecture,'”” Carter said. Through its renewal program, FedEx began to “build out the core services and microservices that represent the less complex, more flexible, faster-to-market capabilities that we have today.” From “How FedEx’s CIO led a decade of modernization.”
Don’t get obsessed with the lamppost of pain: focusing on the difficult, critical things and concluding you can’t transform. Use a type of Disruption: work on lesser, cheaper things to creep up to the critical. Mobile apps, store finder, etc.
Saying “no” as prioritization. All these execs saying no to things to focus on other customer and prospect engagement.
Corporate strategy could be improved by shifting right, moving closer to the week-to-week software cycle to get more familiar with customers and changes in the market. See more on corporate strategy in The Business Bottleneck.
Plus, I discuss bottleneck removal and thinking about policy and governance as human system, not static “laws.”
00:00 – Staycation.
01:32 – Doing something works better than doing nothing
04:36 – BMC case study
09:03 – ending zombie process
11:21 – lack of management tools
13:59 – example of a management tool
15:09 – three small things on kubernetes
28:31 – Your CTA!
Marc Zottner talks with Coté about large scale application modernization. Also, they discuss the value of starting small and constraining yourself to short time lines. Also: what does the American-speaking French accent sound like?
IT, let alone software development has a poor track record for success in large organizations. And yet: we’ll told software is not critical for enterprise survival. We’ve got to figure out how to de-risk software, then. That’s the topic today.
Platforms are often represented in enterprise architectures, “marchitectures,” or as I like to call them, “burgers.” Today, I walk through some past, great burgers, from CORBA, to J2EE, to Cloud Foundry, and more. In doing so, I over some advice about how to find and care for your burger, especially when it comes to keeping your burger fresh.
Planned on topics
All the great burgers.
We’re talking about distributed applications – an application and the services (“backend,” “middleware,” database, ERP-system, etc.) run as their own application, accessed over an API (usually over a network, but could be on the same box, too).
What is it in service of? Software for large organizations: enterprise architectures.
Chargebacks! People love asking about chargebacks – “recouping” costs, metering usage. How should you think about these in cloud native land? There’s plenty of unintended side effects that can harm your overall strategy and business, so make sure to put a lot of thought into how you’re doing it, if at all! That’s today’s topic.
What goals do you have? This will determine what, when, and by how much you charge.
The idea of “recouping” cost can be crude. What if costs are high for one thing, but that brings down overall cost/raises overall value and price-premium, competative advantage.
I know this all naive and wishful thinking…
Like pretty much all of my work, it’s like flossing: we all smile and knod that we should do it, and then get on with managing the slow rot of our teeth instead of changing out mindset and behavior.
Onto the slow rot strategies!
Often, early on, you don’t charge. You want to drive adoption to deliver value (ironically). You might be doing your whole formula wrong. Should you measure per BU, per app, or per overall company revenue? See TDAmeritrade case of tracking ROI.
Also, consider the benefits – retire tech debt to get more agility; removing wait time/waste; being secure and compliant (how do you chargeback for “airgaped”).
Finding the unit to charge for.
These are all fun, technical details of curl’ing APIs, using fancier tools (like VMware CloudHealth and others)…
“The value of PCF is much higher than passing along the cost of power, compute, storage, networking, and operational overhead. How do you put a price on the value of increasing speed to market? On optimizing the value stream? On improving application resiliency? These benefits are meaningful to the business. This value is baked into the cost of the PCF product. But until application teams—and platform operators—fully experience these benefits, it’s counterproductive to assign a value to the platform.”
Plenty of APIs you can curl (see also VMware CloudHeath, etc.)
Decide on goals – adoption, “recouping,” etc.
Find the unit to meter, paper recommends memory, but your unit price can vary. Networking can be a huge part of costs, but difficult to measure.
The unit to meter can get sliced by org/cluster, pod/namespace, node/container…but also service…etc.
Beware of scaring people off and killing adoption, e.g., THD, MasterCard, many others.
Wikipedia, “The purpose of chargeback includes: (1)Making departments responsible in their usage, e.g., refrain from asking for resources they are not going to use; (2) Providing visibility to the head of IT and to senior management on the reasons behind the costs of IT; (3) Allowing the IT department to respond to unexpected customer demand by saying “yes, we can do it, but you will have to pay for it” instead of saying “no, we cannot do this because it’s not in the budget.”
Listen, I know all of this is “that’s fine for a FANG,” but a least aspire to not be lame and work towards this kind of thinking.
Rohit, 2017: “First and foremost remember PCF is a PRODUCT and when you’re launching a new product whether it’s ice cream cones or a PaaS, if you don’t price it right based upon the market conditions, then no customers will come and you’ll be left with a bunch of melted ice cream or an empty PaaS. If the market is undefined i.e. the platform engineers are not already doing chargeback for other infrastructure, any attempt to price PCF now would be a shot in the dark and more likely to over/under estimate the value of the product than to be hit the mark. And over/under pricing it both come with big risks in the both the short and long term. Put in place all the facility you need to understand consumption, do market research on what people are willing to pay. Customers don’t even know the value yet until they start using it!”
Coté discusses three ways he thinks about what “digital transformation” means, and then focuses on the software related one. That whole “BE LIKE A TECH COMPANY” thing people are always PowerPointing about. Also: technology actually is hard, and pre-dread.
Planned on topics
What exactly does “digital transformation mean.”
The Orange small shop owner example (from this talk, I think).
Revision of my standard speech: gettting better at software. To include new stuff from SpringOne and whatnot.
Fried Rice Transformation – cooked flat, with a ton of garlic. This is sort of a (pained, forced) metaphor for mind-shift. I was taught to make it in a wok. Look, even cracking the egg on-top is new. I’d never thing to make it in a flat pan, with that much garlic!
Often times, the way we talk about the benefits of cloud native can kick-up fear for operations people. Coté explains how the automation and standardization that comes with kubernetes, PaaS, and other such changes can actually be very god for ops people.