Two excellent write-ups in FT today:
Bella premunt hostilia, the 13th-century Italian monk Thomas Aquinas wrote: “our foes press from every side”. The foes of liberal democracies are indeed pressing from every side, and increasingly against business. Whether they realise it or not, companies are at the frontline of a new kind of warfare.
This poses a problem for executives, many of whom are not used to assessing corporate risks based on geopolitical tangling. When the attacker is another country’s government, all bets are off. Most insurance policies have “war clauses”, standard insurance that covers warlike actions. But when a cyber attack is attributed to a government, it may now be treated as a warlike act.
No, this is not to “suggest” that Harvard should initiate a case study (or train MBA’s on the “art of war”). However, technology assessments, especially in healthcare, leave a lot to be desired. How do you value health data? Historically, it is the “dark web” that offers the “best value”. People assess the complexity of “dumps” and then base their bids on it- to get the best value by skimming off the corporation/individuals. No underwriter would refer to that source; legally.
Hence, it is an under-researched area on ascribing a value to the healthcare data. Instead of beating the companies with the regulatory stick, time and again, we need to understand how to extract value out of it. That would need extensive plumbing and structuring, which is expensive.
“Tech debt” has nothing to do with money — though it can become expensive — and everything to do with software.In simple terms, it refers to the mounting cost of having to maintain and build on top of old, poorly written code.
Short cuts taken early on in a product’s development can cause a total breakdown years later. For a bank like mine, decades of under-investment in technology can make it almost impossible to speed up an everyday process such as issuing a new card.
The term was coined in 1992 by US programmer Ward Cunningham. “Shipping first-time code is like going into debt,” he wrote. “A little debt speeds development so long as it is paid back promptly with a rewrite.” Wait too long to repay the debt, however, and the “interest” mounts up.
If code is not refined and tidied up over the years, warned Cunningham, “entire engineering organisations can be brought to a standstill under the debt load”….Inside every development team, there is a tug of war between product managers pushing for new features to sell to customers and engineers desperate for more “housekeeping” time to maintain and refine their existing code base.
I agree with the principle but not the context. Hospitals, for example, are notorious for not “investing” in the technology but that’s not the moot point. The high costs are related to different software code, referred to as “legacy”. Part of the reason is that corporations invest in proprietary services which complicate flatlined access to various services built on the top.
The author makes a passing reference here:
This obscures the problem that, for many companies, software development is still a frustratingly unpredictable and imperfect science. “No industry has figured out how to reliably turn money into software,” says John Collison, co-founder of Stripe.
I am cynical to believe that Stripe’s founder is taking a swipe at the payments infrastructure in the legacy banks. He, of course, fails to mention that a completely frictionless payment system called Unified Payments Interface (UPI) exists in India. That is better (and more secure) than his product but offers the invisible layer in apps built on top.
Therefore, it gets me to what I want to drive forth- any product built for an organisation needs to be “secure” and “scalable”. Even if the organisations make a product, they should have a “core offering” (like a kernel) and leave out the “services” ambit in the open. One smart way is to leverage the application programming interfaces that can be left out to the third-parties. This way, the expenses are involved in updating the core and leaving out the rest.
One prime example is the Telegram chat application. They expose the various API’s but keep the bots infrastructure core to themselves. They only update it as and when necessary and the bots end up having “more features” down the line. It is a fantastic way to scale up the application (it already has millions of users) with a distributed scale of architecture. Brilliant.
There is no fool-proof way of reducing the tech-debt, but it can be minimised. And we can rest assure that the cyber hacking incidents won’t be named after the cyclonic storms. (It is naive and a fallacious assertion, anyway).
RadOncNotes 