By James Wilt, Distinguished Architect
When you sit in your vehicle, you have the perception of unlimited comfort, entertainment, configuration, and safety. Some systems are active, others passive. You may choose to not use the seatbelt and while your vehicle will allow it, you will be constantly reminded your decision is discouraged.
You will never be able to run your engine beyond its redlined RPMs nor accelerate beyond its governed speed. All the components of your vehicle work in harmony within imposed limits (e.g., tires supplied match your governed top speed). If you neglect your vehicle, it will do its best to alert you of issues that may result in serious harm.
There is even consistency when moving between vehicles from different manufacturers. Knowing how to drive one manufacturer’s vehicle pretty much means another’s is quite similar.
This is the goal for any and every technology platform!
A Couple Real-World Examples
Carnets on iPadOS and Pydroid 3 on Android are Python/Jupyter Notebook environments that evoke the illusion of developing on a high-powered workstation from what some might describe as “lessor” hardware platforms. Their offline sandbox environments provide a secure means of developing basic to advanced skills at a very low investment. If you can use Carnets, you can equally use Pydroid 3 and visa versa. While they will never replace true development platforms, they are useful to evolve and master skills through experiments and learned concepts.
How do Highly Governed Platforms Provide this Illusion of Freedom?
Architectures can be specifically designed and leveraged to create platforms that deliver desired experiences by following some simple yet specific outcome guidelines:
- Governing limits should provide the illusion there are no limits
- Offer slightly more features/capabilities than your consuming audience will typically use
- Ensure all features/capabilities offered work seamlessly with each other (all components work in harmony)
- Consuming & leveraging platform capabilities is an enjoyable and liberating experience
- Be consistent and operate similar to other “like” platforms
- When governance & alerts are necessary, the consumer response should evoke gratitude
To Build or To Build-Upon – that is the Question!
Leverage before you replicate. What value can you bring by creating a platform vs. building upon a base platform that already exists? AWS, Azure, and GCP cloud platforms all provide quality components. They all have similar consoles, CLIs, and serverless management options. Yet, many organizations continue to fully staff & fund Container Platform Teams that attempt to replicate these commodity environments only to fall short of delivering to their agility and capabilities.
Similarly, while pre-made edge platforms may work for most situations, custom-built configurations are often necessary to optimize performance.
So, is it better to build or to build-upon?
“Fish or cut bait” trade-off decisions abound! These should always be dealt with on a case by case basis. Consider these questions:
- What will be the required staff & budget to operate & support build build-upon investments? What thresholds (capability, cost, timeliness, features, performance, agility, maintenance, etc.) will trigger a need to change?
- What will be the consumer learning-curve and spin-up time for each approach? How well many outcome guidelines be fulfilled?
- Which approach best aligns with your business model? Will your platform be an accelerator? Will you generate income/revenue from it?
Stand on the Shoulders of Giants – as often as you can!
Many base platforms, such as those for Cloud mentioned above, offer various approaches to leverage their many services and offerings. Those can range from access to everything to limiting via exclusions to explicitly selecting components & configurations. Leverage these as much as possible. Remember your goals and ensure your delivery meets your experience objectives:
- Have you considered all component dependencies to ensure all components work in harmony?
- Are you providing slightly more features than anticipated?
- Is the experience going to be consistent and enjoyable?
- Will alerts invoke gratitude?
Consider exploring open-source base platforms to extend capabilities beyond expectations. For example, one might build their zero-trust strategy around proactive perimeters and tokenization in all APIs. While this might meet expectations, a capability to continuously challenge every component running against necessary policy adherence (actively look for blind spots – outside-in) will exceed. Paladin Cloud’s open-source base platform accomplishes this and it does so in a way that invokes gratitude: it can be fine tuned to shut production breaches down immediately and then allow dev & test to run for a short period (e.g., 10-min) before taking action so engineers can vet & test ideas while being made aware of security concerns, eventually. Gratitude.
Cruise Ship Captains Don’t Fly Airliners (and visa versa) for Good Reason
While they both pilot large vessels and are responsible for the lives of many passengers, Captains do not command outside their domains. This is a good thing!
The same should hold true with technology team assignments. When you choose to create a new platform, pick your teams wisely:
- Avoid assigning experts in similar legacy platforms to new platform paradigms. For example, your best in-house infrastructure engineers do not necessarily (and most probably won’t) make the best cloud engineers as identified in this 2021 McKinsey study, “While most organizations will need to adopt a hybrid-cloud approach for the foreseeable future, it will be hard to capture much of cloud’s value without reimagining the IT infrastructure that is ground zero of the cloud operating model.”
- Seek unicorns who openly promote the new paradigm – have they posted revelations in blogs and open sourced their examples? Just look at all the Generative AI Prompt Engineers popping up everywhere. This is the type of “drive & excitement” to seek!
- If you decide to infuse outside talent as a catalyst, consider leveraging their involvement as coaches. Their compensation should be based on your engineers delivering, not them, otherwise, any momentum you gain will be lost and erode after they leave.
Once Up & Running, Don’t Get Greedy
Once you’ve established your platform and start benefitting from its success, you might find reason to disrupt the illusion of freedom you created for perceived good reason. Think twice before you act. Some automakers basking in the successful adoption of their infotainment systems are now planning monthly or yearly subscription fees for certain features already installed on their vehicles (your heated seats subscription is due?). Big. Mistake.
Never rely on your platform teams’ self-evaluations and realize early adopters will skew a false positive. The best measure of success will be well beyond consumer adoption. Measure their excitement to use the platform. If it’s not part of their regular vocabulary, find out why and adjust.
Now is the time to hit the open road and create technological platforms that provide a sense of liberation and exploration!