“But guess what: consumers spend more money each year on AirPods than healthcare spends each year on EMR! And because of IT, consumers have been gaining new capabilities much more rapidly than the healthcare system.” This is some fun thinking on innovation in large organizations and systems. First, are you actually spending the resources (time, money, and attention) to change things. Second, are you solving simple problems that have big productivity/improvement gains.
“According to the report, only 7% of surveyed government leaders said their organization achieved its digital transformation objectives. " Original source: Most Government Orgs Fail to Meet Digital Transformation Objectives, Report Finds
The charitable guidance on what “shift left” means is: operations and security people working closer with developers, being friendly with them, and vice-versa. More or less it’s that lean idea of “move the decisions closer to where the work is actually done.” The phrase has gotten blown up to mean more than the original DevOps think (have developers put in work to make their apps run better in production, and have ops people work with developers to do so) to mean any activity that’s working closer with “developers” rather than in some waterfall-like, impersonal process before or after developers.
[embed]https://www.youtube.com/watch?v=6VrpE992O68&list=PLAdzTan_eSPRNuA52_34wh5VTBC-0Rz7U&index=9[/embed] Transcript One of the things executives often forget when they’re transforming, how the organization does software is to transform how they do their job. What I’ve found is they tend to sometimes have the same sort of meetings and they don’t really change the way that they think about how they’re empowering their staff to be more mindful of being involved and having responsibility with their products. The other thing to pay attention to is making sure you’re actually transforming the way your organization is formed.
I frequently give a talk on “what’s the deal with VMware and software development?” Here’s my script/storyboard for one I’m going to give next week. Sometimes I’m told “don’t make this a vendor talk,” which, as you may recall, dear reader, actually means “don’t be boring.” In this one, I was asked to talk directly to what VMware does for software developers, so you’ll see that. If you like it, you should come check out the discussion next week, be won’t be just me and I’m looking to forward to learning from my co-talker.
You can start to sound too much like an out of touch old person if you start saying things like “oh, we already did that back in my day.” Once people flip your bozo bit, then most anything you say get dismissed. “PaaS” is in this category now: you can’t go around saying that the focus on and conversation about “developer experience” is, like, PaaS. If you’re working on building an integrated stack of frameworks, middleware, tools, and even developer tooling on-top of cloud/kubernetes, you can’t call this PaaS.
Here’s what I’ve learned in doing 30 (maybe more like 40?) executive events in person and online over the past four or so years. Over my career, I’ve done these on and off, but it’s become a core part of my job since moving to EMEA to support Pivotal and now VMware Tanzu with executives. At these events, I learn a lot about “digital transformation,” you know, how people at large organizations are changing how they build software.
Here’s a write-up from myself and JT of a new trend in the kubernetes/DevOps/app dev world: developer portals. With people building out the appdev layer on kubernetes (or “DevX”), many organizations are looking at how they support all the tools and internal community for developers. What’s interesting, and new, about projects like Backstage (now in the CNCF, so pretty closely tied to “we’re running our apps in kubernetes” strategies) is that backstage is looking to add tools right along side the usual “knowledge base” and project management stuff you get for internal dev portals, sites, “Confluence” stuff.
I like this point from a recent write-up of the US Army’s software development transformation: He added that the technology being developed is often secondary. "A lot of times, people get really caught up on what type of software you're developing, and we look at it as the software that we're developing is the intermediate step," he said. Instead, the desired result is having a slew of technology-savvy professionals or "
When we standardized and enforced controls in the CI/CD pipeline the quality improved dramatically. Everyone knew the standards they were held to. “Global Bank” Here is an April 2020 McKinsey report that tries to show a relationship between being good at software and making money. I don’t know math enough to judge these kinds of models (as with the DevOps reports too), but, sure! Here’s their relative ranking of how various developer tools and practices help: