I was going to ritualistically complain about poorly designed software, but lately, most of the software I use has been going well, for instance:
-
The KLM Royal Dutch Airlines and American Airlines apps are some of my most-used apps since moving to Europe; they do exactly what I want—quickly—and are frequently updated;
-
The Albert Heijn app and their omni-channel features (grocery delivery and getting someone else to carry groceries up and down my Amsterdam steep and narrow stairs); and
-
My bank's app which started off as, well, kind of weird back in August has been relentlessly updating this fall and gotten much better, adding in better authentication and spending tracking.
To me, "good" software directly changes how the business operates. As one of my favorite think pieces from 2018, by Brian Sommer, points out: all the digital transformation in the world is useless if you don't actually change the business.
There's still plenty of work left. My life insurance company's software, for example, is little more than a web app that lists PDFs to print and FAX(!) to do even the simplest thing like changing your address. In aggregate, the overall direction we're headed is good. All you enterprises just need to keep it up: from CMM, to ITIL, to Agile, to DevOps, all The Great Methodologies agree that improvement never ends.
Last year I said that you should clear out all your technical debt so you're no longer paralyzed by the cost of short-term architectural decisions. This year, you should put a platform-as-a-product strategy in place. Treating your platform as a product means applying the same product management approach that your product teams are using to improve your customer-facing applications.
Beyond boring platforms
Us folks at Pivotal will whiteboard your eyes out on how a cloud platform will speed up your development cycle. You know, the whole cf push thing. Our customers have shown over and over again that with a centralized, standardized platform, developers spend less time—if any—programming infrastructure, and instead solve customer problems that directly improves their business.
Standing up a platform isn't a one-time project, just a static service to be delivered and SLAs. As with any good software, it's a never-ending series of small batches that takes in requirements from customers, prioritizes which ones to implement this week, develops and releases the software, and verifies that the customer's life was improved… trying it all over again if not. That continuous improvement is the product part of platform-as-a-product.
Thankfully, describing "how to product" is well known. If you've been improving your software by applying lean design, weekly release cycles, and actually following agile software development best practices like TDD and pair programming, you know the basics. When the product is your platform, you treat the product teams as the customers, always working to discover their problems and engineer pragmatic solutions.
A validated platform theory
Rabobank's platform journey is a great example. As Vincent Oostindië explained, they needed to replace their highly successful, but now aged platform. The champ had run their online banking application for many years but now couldn't keep up with new technologies, scale, or and the "you build it, you own it" DevOps principles the bank needed.
As with most organizations, at Rabobank, choosing a new platform, traditionally, is driven by a committee wielding spreadsheets that list endless features and requirements. Each row lists a capability, feature, or type of "requirement" that operators and developers, the committee assumes, will need. At this point, most enterprises would pick a platform using advanced column sorting strategies, vendor haruspex, and disciplined enterprise architecture futurology.
Instead, treating the developers as customers, Rabobank experimented with several different platforms by having developers actually use the platforms for small projects. Following the product approach, they then observed which platforms served the developers best. This working PoC was driven by user validation, proving out which platform worked best. More importantly, it proved that developers liked the platform. "If you guys don't like it you'll just go away," Vincent explains, "and we have a nice platform—or, technically nice platform—but, [with,] no users on it, [there's] no point.”
The time after toil
This just brings you to the start of the platform-as-a-product story, though. It's just the first, major release. Applying a product-driven approach means doing this month after month, year after year. If you're like many large organizations I talk with, you're just now at the point where you've had several initial successes and nailed down platform reliably. At the beginning, your platform engineers probably also spent a considerable amount of time consulting with each product team on the basics of platform use. As the product teams get wiser and more numerous, your platform engineers have probably lost track of what applications are running on the platform. Now, those platform engineers should have more time. Now's the time to become more product-oriented.
Forrester's Chris Gardner and Charlie Betz describe what that looks like: "Administrators must move away from treating systems as static monoliths and toward deploying fluid infrastructure the same way developers build apps: developing, encapsulating, testing, and managing infrastructure models in code repositories." They add in some balletics, "the new priority is understanding how software makes hardware dance to the tune of business."
Now, listen: of course I'm going to tell you that building your own platform from nothing is a bad idea—I work at Pivotal after all! Treating your platform as a product doesn't mean you'll build everything from scratch. From your customer's perspective—the product team’s perspective—it's just waste. Instead, your platform engineers only focus on creating differentiated services, just like your product teams.
For your developers, there's nothing differentiating about how PDFs are generated, databases, or queue. Instead of building such things, developers use existing frameworks so that they can focus on more valuable work.
Similarly, your platform team will be wasting their time (and your money) if they're building a platform from piece-parts, paying for the joyful experience of re-learning and re-coding all the things we've learned in past years. Instead, platform engineers will mine for differentiated value by extending and customizing this platform. For example, they might introduce audit automation and self-service, getting audit windows down from 10 months to less than a week like the US Air Force. Or they might accelerate a bank's global growth by providing a shared banking-as-a-service platform like Scotiabank.
For virtually every organization, time spent building your own platform from scratch is waste. "We also came to the conclusion that as a bank, we shouldn't be building a platform," Vincent explained. That work would require a lot of resources without directly adding value for the end-user: "It would mean people working on that every day, and, well that's not bringing any any business value." Instead of building your own platform, I would not too humbly suggest Pivotal Cloud Foundry®. It's what Rabobank decided on at the end of that working PoC. This strategic decision isn't unique to Rabobank, at all, numerous other enterprises have come to the same conclusion.
Start with bunnies and cats
Conceptually, the idea is simple. Putting it into place, like all transformations, takes effort and much trial and error. Recently, our customers have been sorting through this dance, to use Gardner and Betz's flourish. Our Pivotal Cloud Foundry Solutions team has boiled the moves down into a methodology that's been deployed many times. A couple of months ago Paula Kennedy gave a great overview that's a good place to start, also boiled down into a delightful cartoon with cats and bunnies (thanks Denise Yu)!
Comic from @deniseyu21.
As ever, the end-goal is removing waste and toil from your organization's software lifecycle so that first, your platform engineers can focus on helping product teams and, second, product teams can focus on writing better software for the people who use it. Hopefully, by this time next year, I won't have to fill out a PDF just to pay my life insurance premium. That's all I'm really looking for here. Like any good normal person, I don't want to pay you to configure servers, I just want to update my address, pay my bills, and get on with my life.
