A recent presentation from Andrew.
- “The lore is not the law.”
- There’s about 30 minutes worth of Q&A!
#webinars #redhat #digitaltransformation
A recent presentation from Andrew.
Last week I did a three part series on metrics for ALL THE DIGITALZ. Metrics are like anything else: people say your metrics are terrible if they don’t like them, but they tend to like their metrics.
Ultimately, if you’re changing how a large organization works, you have to “manage by metrics.” You also need to manage by “talking to people and thinking for yourself.” I mean, if you’re transforming a large organization YOU NEED EVERY THING THAT’S HELPFUL THAT YOU CAN GET YOUR HANDS ON.
Here’s the three types of metrics I went over.
Are we achieving the non-IT goals we’re here for? How would we know?
They’re metrics like:
For an indirect tracker, some people at TD Ameritrade come up with a way to track business value progress, i.e., “are we progressing at improving things?” by using # of apps deployed on the new cloud native platform (Tanzu Application Service, but you could use “kubernetes”) in dev and then prod. Their reasoning is good:
Traditional development and ops metrics.
Metrics like:
There are mostly from the DevOps reports and little bit of SRE. There’s more SRE “golden metrics” that are interesting to contemplate. And the thinking behind “negotiating” error budgets between dev and ops (SRE) is probably a helpful way to think about SLAs (yes, yes – I know – DO NOT EMAIL ME).
How do you measure the state of your organization, the people in it and how they’re operating – “culture.”
These are much more squishy, but you can start with:
There’s some interesting metrics commentary/survey work in a recent VMware sponsored survey:
If you prefer, all of this is written up in a guest column, but in a more serious, no-jokes way and with much less of my face. They’re also written up extensively in my books The Business Bottleneck and Monolithic Transformation.
In this talk, you’ll hear about three types of metrics that organizations are using to get better at building and running software. You know, those organizations that are doing the “digital transformation” thing so that they can run their business with software that isn’t ancient and lame. BE LIKE A TECH COMPANY.
We all know development and operations metrics like lead time, error budgets, and mean time to repair. But we don’t focus on business metrics enough. And least of all, we don’t talk about internal, organization, or “culture” metrics enough. This talk gives an overview of 15 metrics across three types: technical metrics, business metrics, and culture metrics. If we look at the end-to-end process of software creation, usage, and work as an system to be programmed and refined, we need metrics across that entire system. This talk will help get you started.
This talk is based on real world case studies and is written up in my two books Monolithic Transformation and The Business Bottleneck. There’s also a summary article here.
Speaker bio and past talks: https://cote.io/speaking/
More than likely, your initial ideas for your apps will be wrong. You’re probably not even solving the most important problems. Pivotal Lab’s “Discovery and Framing” process is built around making sure you’re working on the right apps and features to meet your original goals. In today’s episode, I cover the discovery and framing idea as, er, framed up by Matt Parker in his book Radically Collaborative Patterns for Software Makers. Also, I go over a case study of this from the food services industry.
Just one topic today: once you have your value stream (or whatever you want to call it) mapped, it’s time to eliminate bottlenecks. Here are five common bottlenecks in the software lifecycle to work on.
See archives and CTA at cote.io/tanzutalk.
Pair programming might seem ridiculous at first, but it’s a proven, better way to program and do related work. In this episode, I go over six ways it makes things all better: quality, learning, team resilience, happiness, productivity, scaling change.
00:00 – I’m eating.
00:27 – Pairing
23:43 – Podcast recommendation.
21:03 – Bye, bye!
I had a great conversation with Boskey Savla (@boskey) goes over kubernetes for VI admins. We discuss what VI admins traditionally do, how that maps to kubernetes, and the new tasks and roles admins have when managing kubernetes. Also: what does “kubernetes in vSphere,” like, actually mean?
Also, check out her session from SpringOne 2020, “Crafting a New Enterprise App Platform with Cloud Foundry, Kubernetes, Istio, and More.”
00:00 – Boskey Savla
01:06 – Her two courses at kube.academy.
01:56 – What is a “VI admin”?
05:57 – How kubernetes changes the role of VI admins.
10:00 – The “API”/interface differences between traditional VMs and kubernetes.
15:20 – Getting started with kubernetes: start with what you have.
19:54 – Putting together video training.
23:57 – kubernetes is in vSphere – wut?
30:46 – Bye, bye!
When you want to change, you need to find out what the new rules are, or start following the ones you’ve been neglecting. Also, stop trying to find who’s in charge: it’s probably you!
0:00 – Agenda.
00:20 – Everyone is good at saying “no.”
01:58 – Don’t break the rules, almost break the rules.
07:20 – It’s you! There’s no one else to ask.
12:31 – Your CTA.
16:42 – Bye, bye!
Robbie Clutton joins me again to talk more agile-think. First, we discuss how you can nudge people to actually follow priorities. How do you get people to do what they’re supposed to? Then, we discuss how to think about and use cost of delay in business case thinking. Cost of delay is also a good tool for prioritizing work as well.
Getting good at leadership is always good, but make sure to mind the technocracy as well – someone’s actually gotta do the work! Also: plan for needing gadgets for your gadgets.
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.”
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.”
0:00 – The agenda.
02:51 – kube.academy.
4:00 – Remove bottlenecks to get better at software, always.
22:06 – Amsterdam art nouveau.
24:06 – Shift right to improve corporate strategy.
35:45 – Discovery workshops.
38:07 – Policy is made by humans.
43:33 – Bye, bye!
Doing something works better than doing nothing
When you put a new process, like agile, in place, you often realize there was very little process in the first place. Also, kubernetes at the edge, T-Mobile, and as architecture.
Mentioned:
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!
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.
We did a recap/favorites for talks at SpringOne Platform this week. Here’s my section.
In addition to praise for Cora and Maria’s talk on service meshes, I called out these talks:
Perhaps I had other mentions too, watch the video to see!
Source: VMwareTanzu – Twitch
BT SpringOne Talk: developer first and a willingness to learn and change as needed
A keynote given by Rajesh Premchandran, BT
BT wants to get better at how their do business, through software. Their strategies are, of course, operational excellence, but also getting software that improves the customer’s experience. This means they need to simplify how business is done, which they did by transforming the way they do software: IT underpins this corporate transformation, Rajesh says.
His approach to telling this story is to talk about how BT questioned some initial assumptions. On some of their initial plans, they pivoted (adapted) when they discovered new needs and realitis. On others, they persisted when they really needed the change. For example, at first, they thought that having a PaaS would be good enough for all development and app needs.
A pivot example: they discovered that more fine grained control was needed for some apps (esp. legacy ones), so they added in kuberntes. Here. PCF/TAS and TKG.
A persist example: security had to move from security by static IP. Because they were moving to AWS and microservices, things needed to be more dynamic. There was no way to achieve their tech-stack transformation otherwise. So, they persisted.
The third area he describes is their approach to removing ops toil from application developer’s agenda. As ever, they want apps developers to focus on…apps! And have time to explore and innovate making the apps better to deliver on customer service goals. (You see several example from Comcast on this with their new TV apps and improving customer service with ChatBots, and even in-home wifi coverage calibration, etc.) He also comments on a discovery, or validation of a predictable state, in my rewording: developers aren’t good at production ops and don’t really realize all the new tasks they’ll need to do – responisbilities they have! – in a DevOps model. So, they had pivot to training them and putting in place tech stuff to make it work better for them.
He has some fantastic framing: "instead of letting [developers] grapple with operating model choices, we adopted a more human-centric approach to educating teams."
He touches briefly on some portfolio modernization strategy. The benefits of doing, I think, were that they spent their time wisely, modernizing apps that were feasible and valuable to modernize instead of all of them. I could use more detail here, but I think the point is made – I mean it’s a five or six minute talk, so it’s fine. For a lot more, check out the ever excellent Rohit explaining this kind of portfolio app modernization analysis.
There’s another, long BT talk that I haven’t fully dissected yet.
Also, an excellent InfoWorld interview with Rajesh where he talks about several of these points, even more stridently.
Some highlights:
Charts!
Modernizers reported better outcomes across the board compared to migrators, according to IDC’s paper.
The most popular digital transformation initiatives for IBM i shops, according to IDC’s survey.
IDC questioned all four cohorts (IBM i shops that modernized, IBM i shops that migrated, System z shops that modernized, and System z shops that migrated) about their satisfaction across a range of metrics before and after their move, including: customer experience; overall performance; security, availability, and disaster recovery capabilities; agility, microservices, and DevOps; ease of finding talent; ability to incorporate AI and IoT; and API, mobile, and Web enablement.
Across all seven metrics, the IBM i and System z shops that modernized their “legacy” systems scored higher than their IBM i and System z colleagues who chose to migrate off their systems. What’s more, organizations that modernized instead of migrated reported paying less on hardware, software, and staffing, and reported higher revenues to boot.
Making software better rather than just lifting and shifting it usually works out better.
Source: Modernization Trumps Migration for IBM i and Mainframe, IDC Says e
Survey highlights:
If you’re interested in more, we’ll be talking about this next week, September 21st at 5pm Amsterdam time over on Tanzu TV.
Air France KLM modernized their payments service recently, EPASS. This is a 12 year old system that provides the backend for processing purchasing airline tickets (and other things, I guess) from numerous front-ends: the web, mobile app, and social apps as well. The system was difficult to scale, it required manually adding new servers and had a long development cycle. As more and more people want to interact with Air France KLM through software (phones, online, in WhatsApp, or whatever other “channel”), they want to be able to evolve their software quickly. They want to use software as a core innovation tool for improving customer experience and, thus, business. So, here we see one of their first experiences modernizing their backend and transforming how they do software.
Talk presented by Oya Ünlü Duygulu and Patrick Zijlstra.
-Rick in intro: transformed payments platform in 6 weeks.
– [Corporate vision] is to provide good, “our purpose as an airline group is create memorable experiences for our passengers.
– So, they want to (1.) focus on customer centricity, (2.) innovation, and, (3.) efficiencies in our processes.
– “Digital” as the primary channel is on the rise. People want to interact through apps and such. So, KLM needs to meet the customers there… “As an airline, we want to be where our passengers are” (~3:00)
– Some examples of digital features: “‘About 10 percent of the ideas actually end up on the market. A recent example of this is the hand baggage check in the KLM app. Through augmented reality travelers can see whether their hand luggage meets the set dimensions. This function went live last month. ‘ Six months ago, a 3D rendering of the business class seats was also shown when checking in online. ‘This with the idea of stimulating the sale of these chairs.”
– For example, listening and interacting with customers in social media [something I’ve done many times – it’s great to chat with someone (or a bot?) in WhatsApps, Twitter, etc. instead of a phone call]. (~3:40) Social media is now “our closest connection to passengers.” And in China: “For instance, Chinese travelers rely immensely on mobile devices. How can these personal devices be used for authentication – identity management, payment etc. to streamline the journey wherever possible? In China, the whole landscape is different, and we need to ensure we aren’t relying overtly on drawing customers only to our touch-points.”
– (~3:10) merged together KLM and Air France backends to get less complexity in the back-end and a unified experience in the front-end for customers. Social media is now “our closest connection to passengers.”
– 350 agile teams. Using Scrun, Kanban. SAFe. See SAFe case study from ~2018, and some trip notes from someone at ACM Agile.
– The use SAFe release trains (which they call “release planes”), mapped to customer value journeys, e.g., sales, paid products, or airport.
– In the digital department, they have about than 50 product teams.
– Planning every three months, come together get a roadmap from the business, and all the teams plan together. Then they start sprinting bi-weekly.
– Also shared services and practices team.
– Their /goals:
– (~5:50) “We are designing our products focused on time to market, innovation, robustness, and security.”
– Focusing on getting CI/CD in place.
– Also, reducing complexity and speeding up business value [realization], so we are moving towards a microservices architecture.
– [Business stuff:] EPASS handles payments from many places, created 12 years ago. Wanted to modernize [not sure why]. They worked with Pivotal Labs on modernization for a six wee project.
– EPASS app – made 12 years ago, handles about 37,000 payments transactions per day. Takes care of all online revenue.
– Six week engagement with Pivotal Labs. This brought expertiese from the outside, combined with their existing skills.
– “Six weeks is very ambitious for such a project, but getting this expertise from Pivotal and their dedication we made a success story at the end.”
– Modernization road-map for EPASS.
– We want to speed up with release cycles, which was then one month. [Move to single piece work-flow: whenever a user story is ready, then it can go live.]
– In six weeks, all the could focus on was transforming the app and moving it to the new platform [PCF]. But, they could also modernize their skills by adding in TDD and pair programming.
– Switches to Patrick.
– (~10:55) – they go over their way of working.
– Inception to set expectations. Outception to look back at what was achieved. Some blocker removal meetings. And the usual agile meetings.
– Two teams: one does modernization, the other delivers business features.
– Worked in one week iterations.
– Doing pair programming. “We noticed that this really increases the code quality that we deliver.”
– (~12:30) EPASS architecture. Was hosted on bare-metal Tomcat server. To scale, had to add new server and put EPASS software on it. This was becoming a hassle and fixing that was a motivation to move to VMware Tanzu.
– (~14:00) new architecture – five different components. Three in Tanzu Application Service.
– After, the majority of things were put in VMware Tanzu…
– [Picked some small things at first to test stuff out, hardcoded secrets but later fixed that – used CredHub – in long term will move to Vault.]
– (~16:00) Used Spring Boot, adding health check [this is good to highlight, that it gets instrumented/observable “for free”].
– “It was invigorating working to work with the Pivotal experts and now there’s more confidence in the team to continue.”
– Used Bamboo, added in automation stuff for deployment…
– Problems: networking problems
– Benefits: response times improved by 10%; “all the power for scaling is within the product team itself” instead of having to work with other groups, file tickets, etc. Also, time to patch is within 72 hours (3 days).
– (~21:08) “The experience was very positive. It was invigorating to work with the Pivotal experts. And, now there’s more confidence within the team to continue to improve the application.”
– The projects have been finished for a few months. No more components in bare-metal Tomcat.
– “From the organization side, there is no more fear of big changes. If such an old application as EPASS can transform, then it’s possible for any application.”
– “So more and more and more applications will be moving to TAS [Tanzu Application Service].”
The panel I put together and moderated for this year’s SpringOne. It turned out really well. Here’s the abstract:
When you’re trying to improve how your organization does software, how do you change what managers and executives do? We hear a lot about how developers and operators change, the composition of product teams, and always about Kubernetes. But there’s very little conversation about transforming management. This panel of managers will discuss what managers’ and executives’ roles new and old look like, managing managers, and how individual managers can manage their careers when their role changes.
The panelests: Neville George, Manager at Comcast; Jon Osborn, IT Executive at Bell Tracy, Ltd.; Jana Werner, Head of Transformation at Tesco Bank