 |
| It briefs problems, solutions and provides a case study. |
This deck comes as pdf. Due to limitations of blogger. Link to the full deck (LinkedIn post).
See also
Strategy of change, 2026
This deck comes as pdf. Due to limitations of blogger. Link to the full deck (LinkedIn post).
Invariant of an artisan
 |
| Signature is still by an artisan, a person who still needs to keep up |
Invariant is bulletproof, and full of parallels.
Even if AI could do 90% of code creation (10x), and even 99% in 2-5 years (100x) there is still remaining 1-10% which require understanding by a human. By a person who need to make adjustments coaligned with first 90-99%*. Artisan who needs to put their signature still needs to get trained how to operate technology and support underlying business.
Engineering-wise cycle is somewhat similar to adjusting IC productivity when it was on the way from assembler to C, from C++ to Java/Go/Python etc., from JS to React or similar.
One thing this cycle brings - high pressure to maintain operational IP as code. To have it blueprinted into operations. This creates sound opportunity to prioritize platform, DevOps and infrastructure.
* - these are optimistic, but possible stretch goals.
Operational IP - the ninety target
 |
| The ninety target |
Applications are the code. There is no other way to compile/interpret them. It is a must. The way how they operate – operational IP – historically not.
That’s Jon who deploys, and Susan who knows when to reboot it, and Joan who designs upgrades, and Jim who does security patches, and Ingrid who is on systems, and Matt who updated configuration yesterday, and Dana who keeps the database up, and Ravi who keeps firewalls protected, and James who makes sure systems keep up with the load, and Kaya who know how orchestrate all these together.
Does your SaaS work 24/7 (most do)? – that’s 5-6 times more people per application group. To handle three shifts and 21 shift x days with time to teach, learn, replenish and stay human.
How far your cloud strategy from protecting >90% of your operational IP?
That’s Jon who deploys, and Susan who knows when to reboot it, and Joan who designs upgrades, and Jim who does security patches, and Ingrid who is on systems, and Matt who updated configuration yesterday, and Dana who keeps the database up, and Ravi who keeps firewalls protected, and James who makes sure systems keep up with the load, and Kaya who know how orchestrate all these together.
Does your SaaS work 24/7 (most do)? – that’s 5-6 times more people per application group. To handle three shifts and 21 shift x days with time to teach, learn, replenish and stay human.
How far your cloud strategy from protecting >90% of your operational IP?
Gap analysis
 |
| Countdown to legacy. Source images credit: nano banana |
Most companies don't have a countdown clock which toward the end switches to hieroglyphics, sounds alarm and gradually causes earth tremors. Legacy software process just gets obsolete one day.
Modern software technology operations go beyond code itself. Operational IP is a complex system: including SDLC decisions, data, configuration management and pipelines.AI/LLM-tools application may vary for some time, but as always - you can't automate what was not written down. Which is easier to say than to get to the mark.
[1] - Ask about your “five nines” gap analysis for your service (SaaS)
[2] - Own your SaaS: 12 angles to improve your velocity with blueprints
[2] - Own your SaaS: 12 angles to improve your velocity with blueprints
Uptime Dashboard
 |
| Uptime Dashboard |
Excited to announce a closed beta for our new product - AnyIntelli Up - up.ai1.co - website monitoring tool which allows technical teams to monitor uptime of their systems.
The goal is to go beyond technical and deliver to business customers as well ability to offload routine change follow ups with automation and quality control.
Please, get in touch [1] if you want access the early beta, or if you have a web-monitoring case you need to have running.
See details: https://up.ai1.co
Network plasticity and full picture
 |
| Transform dilemma between resilience and agility to solution |
These are much harder cases to bypass than today’s (2025/11/18) Cloudflare’s outage.
Resiliency is quite challenging. When executed as an addon it is often a dilemma between slowing down technology operations and product development in favor of adding plasticity. Or episodically adding a resiliency in one place to discover how partial it is: like building a biometrics-protected gate with 24/7 video surveillance without fully securing adjacent perimeter with the fence.
For Cloudflare’s redundancy you can add bypass to another CDN, or as a short fallback option – to load balancer directly. But what if second exception happens (at DNS management, or internal controls) and you can’t activate this bypass.
Dynamics are reverted when growing new services relies on platform which puts into foundation and relies on resilience to make things more agile. [2]
In the era of focused specialties and responsibilities, overall picture matters.
[1] - Ask about your “five nines” gap analysis for your service (SaaS)
[2] - Own your SaaS: 12 angles to improve your velocity with blueprints
Consider before going multi-cloud
Going multi-cloud has obvious goals - increased resilience, and redundancy. Though, it can hurt when it comes to the health of a particular company.
There are 12 other typical project themes, which
magically cover active-active multi-region in the result, but does not include network plasticity (redundant multi-region) itself [1]. The multi-region itself happens to be 13th
topic, a cherry on top.
"Keeping menu short" [2] is a direct and yet again rationale avoiding multi-cloud.
Specific roots. Preventing downtime here is linked mostly to
calculations as majority of the companies would not have that drastic loss from
a system-wide failure in the cloud or will have issues predicting it.
Think about a logical mistake during development (SDLC)
which makes your object storage return empty files marking responses as valid (code
200, empty body). In this case, canonical persistence system misleads and needs
adjustment. Redundancy here is helpful only to a point of segmentation. For
example, us-east-1 outages are most visible, but because of that, risk
management suggests AWS would prioritize updates going first to less populated
regions as well.
The direction reverses when plasticity needed to implement
dynamic strategy of change gets closer to all 12 angles. This as “unintended” result
raises tolerance and hence operational savings for cases beyond 12.
Let’s come back to multi-cloud. At least when planned and executed as full redundancy for computing resources. Think about it: network, processing, databases, other persistence layers double both design and maintenance at infrastructure, and platform layers. Hence, changes to overall system will:
- require deeper analysis and planning due to added “universalization” activities
- be more complex
- 1 & 2 are increasing cost of immediate execution and support, but also quadruple likelihood of a mistake related to own SDLC operations
When rationale is to predict and prevent system-wide failure
which is probabilistic, 1-3 as mix of certain and expected outages outweighs the
benefit.
All this though leaves good niches for short-term multi-cloud
executions when it comes to:
- consolidation of business branches which are already in this parallel state
- when new cloud offers can significantly benefit cost-wise after the switch
As well as strong opening for specific services:
- when they are added in non-redundant manner with “10x” edge. High quality, white gloves and turnkey software as a service model. Preferably, backed by multi-region active-active blueprints.
The 3rd theme, quality, is what will make providers
create unique propositions simplifying visible complexity of the tech business and
reliability of available technologies.
[1] Own your SaaS: 12 angles to improve your velocitywith blueprints
Subscribe to:
Comments (Atom)