Coté's Commonplace Book - Issue #37
We're in Amsterdam now, all moved into our house - rented, of course. I missed last week due to packing and moving.
SpringOne platform is coming up quick - next month! - so Richard and Coté do their annual favorite talks review. There's talk on agile, pipelines, Pivotal Cloud Foundry, Spring, case studies, and so many more they don't have time to discuss. In recent news, Knative was recently announced which is wangling to be "the building blocks for running serverless workloads on kubernetes," as Google's DeWitt Clinton put it. Richard and Coté discuss knative, Istio, and how "serverless" seems to now mean just any old type of programming, but with containers and all that cloud native stuff. They also discuss container registries. Also, European toilet paper and beds.
Serverless now just means "programming" - Software Defined Talk #143 — www.softwaredefinedtalk.com After some rumination, Coté thins that the people backing “serverless” are just wangling to make it mean “doing programming with containers on clouds.” That is, just programming. At some point, it meant an event based system hosted in public clouds (AWS Lamda). Also, we discuss Cisco buying Duo, potential EBITA problems from Broadcom buying CA, and robot pizza. Of course, with Coté having just moved to Amsterdam, there’s some Amsterdam talk.
Come hear how enterprises are getting better at software
Hey, we've got our big conference coming up in September. I draw a huge amount of my work from the customer talks at these events: they're amazing detailed, more than I've ever encountered at a software vendor conference...or any conference, really. There's videos you can see afterwards (see 2017's and 2016's), but being there is of course much better for all the hallway talk. Plus, it's in Maryland, so I'm pretty sure there'll be lots of crabs. If you end up coming, email me up and we'll go have some.
Asking for money to change
This week, I've been working on finishing the "leadership" section of my digital transformation book. I've ended up swagging at "business cases," which are simple, but weird topic. I think what people mean when they say "business case" is actually (1.) help me justify spending this money, and, (2.) help me keep costs at a minimum. A business case for a startup (the culture that informs all us nerd's business think) is a lot different than a business case for an enterprise. Here's some WIP'ing:
First, let’s distinguish between two types of business cases: the product business case and the IT business case:
The product business case focuses on the overall business: if we sell motorcyle insurance in Australia, how much will it cost and how much will we make. As with any business case, it revolves around costs, income, and financial metrics like comparisons to other investment options.
The IT business case is a component of the overall product case and focuses on IT’s costs and how IT supports the overall strategy. This means you spend a lot of time focusing on savings. Saving money is fine if your business is static, but when you’re trying to innovate and grow your business simply saving money isn’t enough. Additionally, you need to focus on spending resources effectively: you want to asses the “value” of IT, not just the cost.
We’re not too interested in the product business case, fascinating as it might be. However, in order to make the IT business case, we’ll need to know the expectations and constraints of the product business case. More than likely, you won’t have much control over the product business case, at least until you can prove how critical IT is your organization’s execution.
These business cases can take on all forms with a broad range of effort and precision. When I worked in corporate strategy, successful business cases could be 6 month projects driven by teams of 10 or more people throwing off slides and spreadsheets, filling drab conference rooms with the smells of pizza and Chinese food late into many nights. Or, they could be lightly done emails with some vague slides that were never used in a meeting that had just a few minutes of languid white-boarding.
If you’ll pardon some consultant mealy-mouthedness, it’s impossible to tell you exactly what your business case should look like - it depends! Let’s look at some general guidelines for how you can start modeling your business case, though.
Productivity of developers (best output for cost).
Productivity operations people (fewer hours spent configuring servers).
Infrastructure costs (spending less, but using more).
Opportunity cost/loss counterfactuals (things could have been worse).
Product value created (we helped make money and can show causation, if not convincing correlation).
Focusing on the first three are easy enough, conceptually, and is mostly about savings/value for spend. One of the better ways to put these metrics together is to create a value stream map for putting out a typical, small batch release. As ever, if you’re doing traditional Scrum, this could be a two week sprint. Then you compare the before and after, putting in some rough estimates of hourly money spent (wages, mostly). This allows you to compare the improvements that’d be made, getting you to an ROI.
Here’s an example TK( put one in! )
Infrastructure costs are the usual: is you new stuff cheaper than the old stuff? At the very least, can you do more with what you have, thus, lowering the cost. Modernization has a lot of success here with moving out proprietary Unix, mainframes, and older application servers and middleware. The ability to pack more punch in each container can also help as well, and perhaps the elastic nature of using cloud, e.g., for retail. Of course, care has to be taken here to make sure that the savings aren’t because you’re buying cheap, but faulty, technology: saving your way into failure.
The aspirational metrics might come after time. What you’d really like to show is how much value IT created, usually revenue.
Comparisons between your traditional software and new, cloud native approach can be cast as counterfactuals to help you model faster revenue attainment. Money now being much more valuable than money later, this can be a handy calculation. For example, while the outcome wasn’t revenue, the USAF estimated that had they kept doing their traditional approach to software, they would have spent/lost $391m over 5 years using the traditional method. The value for the Air Force in this case was TK( savings? Better operations, etc. ).
Security is a common feature in these counterfactual business cases: if we hadn’t put password rotation in effect last Fall, that malware would have lost us $50m and several jobs.
TK( and then, if you can model how product choices improved the business, you can start get to the IT generating revenue calculations… like Liberty saving time in the value stream of selling insurance, getting the business started earlier, and doubling close rate ).
There are all sorts of tricks and otherwise genuine tactics to create business models. What’s key is having a conversation with management and finance to find out what matters to them and how your new, proposed capabilities can deliver on their goals TK( put in examples from ROI cases ).
Out and about
Brenon suggests that management's guidance on margins suggests they'll sell off part of the business:
The tiny margin in CA’s enterprise software business, which contrasts with its richly profitable mainframe division, won’t help Broadcom hit its projected EBITDA targets, no matter how many ‘adjustments’ are made. In fact, the division stands in the way.
Architectural and operations minimalism “Software that you install is software that you have to operate.”
Towards Progressive Delivery “Progressive Delivery” - wrapping analyst-think and a sprinkle of business operations around rolling deploys.
Forty-seven (47%) percent of them said improving performance/availability was one of the main reasons for leveraging multiple infrastructure environments.
HSBC plans to build its all-new business banking service to run on a Kubernetes-managed container infrastructure using Google’s toolset.
Banks are typically at the vanguard of technology adoption: they have lots of money. They're also good customer references because, well, they're banks: errors lead to lost money, they're regulated, in their retail business they deal with lots of users, and they have large company ("enterprise") concerns.
Anyhow, HSBC is a good reference customer for anyone, esp. public cloud.
The worldwide infrastructure as a service (IaaS) market grew 29.5 percent in 2017 to total $23.5 billion, up from $18.2 billion in 2016.
In context of all IT spend, from Gartner:
Worldwide IT spending is projected to total $3.7 trillion in 2018, an increase of 6.2 percent from 2017, according to the latest forecast.
There's a lot going on in this video. For me, it's all about reframing "serverless" as simply "software development." Towards the end, you can also see DeWitt throwing out the notion that there's a new stack model being developed here.
The software serves as a management mechanism for distributed microservices, providing capabilities like traffic management, service identity and security, policy enforcement and telemetry among apps running across multiple Kubernetes clusters and hosts.
I can see how on larger teams with meaningful applications it could add a ton of value and help streamline the deployment processes.
Lessons from Elad Gil and High Growth Handbook It’d be useful at some point to compare the “how to be a startup” advice to “how to modernize and suite of enterprise applications.” For example, an enterprise often knows its product/market fit (e.g., selling kidnapping insurance to executives). However, it may not know the best product/technology approach (it needs a mobile app that tracks when the executive leaves the country), or product/design fit (the executive’s assistant does most of the interaction with the software, so you need to add a secondary user). For enterprises, there’s much to be learned from startup think, but there’s also much that’s different.
Stopping the Noise in Your Head - while I don't suffer from the deeper anxieties this book is targeted for, it's developing an interesting theory of how to deal with anxiety and self-doubt. Like any self-help book, it's taking a long time to get there (I'm about 25% done and still don't know the tactics). So far, the thrust is to live with your discomfort and just use it as a tool - a "signal" - that you should do something to fix your situation. There's also some - I'd suspect mildly unhelpful - advise along the lines of "just (give yourself the permission) to stop worrying."
Measure What Matters - I'm lazily listening to this book. It's hard to get back into reading it seriously - I went through most it while I was packing up in Austin, as background noise. There's a lot of filler and startup stories. Buried in there are some actual OKR definitions and tactics, but you can't get to them through listening. I'll have to go back and find them and, better, finds an HBR-like article that just summarizes how OKRs work in organizations. Like most management theory and systems, I suspect the benefits come from one simple action: actually following the system. Coincidentally, there's a startup story about the robot pizza service, Zume, which looks like it might get a huge round of funding (check out the ABB logo on the pizza making robot there). I'm sure they're all like: "making pizza was just the MVP. What if we automated all food service - think of the blue oceans teaming with TAMs!" <VC brain explosion>
Amsterdam: A History of the World’s Most Liberal City - while it has a more detailed ending (cover the last 30 years) than the other Amsterdam history book, it's still a little unsatisfying. Basically, the book says, the absurdist provo movement took over political thought, and, mixed with a legacy of looking the other way, you get the Amsterdam of today. There's a tiny bit about Amsterdammers having to learn to live with immigrants and balance that out with changing the core of Dutch culture. That's one of the main things that freaks some Americans out: as new people come into the system, we loose control of culture, of the ongoing definition of America.
All the best intentions
Thankfully, Instapaper finally put this pop-up into their system - or whatever they have to do - so I went back to using that. I'm sure this is some kind of privacy hygiene that I'm lucky to have, but: ¯\_(ツ)_/¯
Closer to IRL
I don’t worry much about where maintenance occurs. Indeed, if maintenance can be done for less we ought to buy more, so less expensive can mean safer.... Rather than fearing the offshoring of airplane maintenance we ought to ask how we can expand the concept. Medical tourism, for example, is growing. If foreign airplane maintenance is good enough for Delta then foreign human maintenance is good enough for me.
Once again, I was given somebody’s gem and cut and polished it.
Spending in the $1.4 trillion business travel market, of the non-travel type:
Starbucks is clearly not just for coffee, according to corporate expense receipts. On average, employees spent $13.21 per visit to Starbucks in 2017, up nearly 40 percent since 2013. That means people are buying more than just coffee, which costs about $4, depending on your order. Certify CEO Bob Neveu credits spending on Starbucks’ increasing variety of food options, in addition to rising prices, for the increase.
Get Up, Stand Up! Changing the world with posters Those are some good looking posters.
[A] Dutch word which, depending on context, can be translated as conviviality, coziness, fun. It is often used to describe a social and relaxed situation. It can also indicate belonging, time spent with loved ones, catching up with an old friend or just the general togetherness that gives people a warm feeling.... A common trait to all descriptions of gezelligheid is a general and abstract sensation of individual well-being that one typically shares with others. All descriptions involve a positive atmosphere, flow or vibe that colours the individual personal experience in a favorable way and in one way or another corresponds to social contexts.