The Black Liszt

How to Integrate AI and ML with Production Software

Most enterprises that build software are proudly flying the flag of AI/ML. "We're technology leaders!" their leaders crow in annual reports and at conferences. At the same time, any objective observer usually sees a lack of common sense in the operation of the company's systems. It often appears that, far from needing beyond-human artificial intelligence, they could use some insect-level functioning instincts that get things done. What's going on? Can it be fixed?

The Industry-standard way to fix the problem

The usual fix to the problem is to completely ignore the fact that there's a problem in public, while following something like these proven strategies:

• Brag, loudly and often, about you and your organization's commitment to AI/ML. The commitment is serious; it's deep and it's broad!
• Talk about the initiatives you've funded and the top experts you've hired.
• Talk about the promising things you've got in the works.
• Use extra phrases to demonstrate your seriousness, things like "1-to-1 personalization" and "adaptive processes" and "digital-first transformation."
• Put your top executives with fancy titles out there to follow the same strategy, using their own words.

I've given a detailed example of how a top healthcare insurance company follows this strategy while operating at a sophistication level that is best described as "hey, this electronic mail stuff sounds neat, let's give it a try."

Sometimes one of these organizations puts something in practice that works. It typically takes a great deal of time and effort to find and modify the relevant production systems. The efforts that are mostly likely to make it into production are those that can be done with the least amount of modification. For example, minimal-effort success can sometimes be achieved by extracting data from production systems, subjecting it to AI/ML magic and then either feeding a new system or making it effective with just a couple of insertion points.

The Obstacles to AI/ML Success

The obstacles to AI/ML success have two major aspects:

• The typical practice of leap-frogging all the predecessors to AI/ML to maximum sophistication.
• The extensive, incompatible existing production systems into which AI/ML power has to somehow be inserted.

A good way to understand these obstacles is to imagine that you're in a world in which boats are by far the most important means of bulk transportation. In other words, the world in which we all lived at the start of the 1800's. Suppose by some miracle a small group has invented nuclear power and has decided it would be a great way to provide locomotion to large boats instead of the sails and wind power then in use. What prevents the amazing new technology from being used?

Easy: the boats were designed for sails (with masts and all that) and have no good place to put a nuclear engine, and no way to harness its power to make the boat move.  The strong steel and other materials required to make a turbine and propellers doesn't exist. You can demonstrate the potential of your engine in isolation, but making it work in the boats available at the time won't happen. You can spend as much time as you like blaming the boats, but what's the point?

The solution is clear by studying boat locomotion: there were incremental advances in boat materials and design, and the systems used for powering them. Paddle wheelers have been around for over a thousand years. Here's a medieval representation of a Roman ox-powered paddle wheel boat.

For serious ocean travel, the choice became the large sail boat, as in this painting of boats near a Dutch fortified town:

Suppose you had a nuclear engine of some kind and were somehow able to make it with materials that were generally not available in the 1600's. How would you use it to power the sail boat? The very thought is ridiculous. The problem is that the boats have no way to accept or utilize the nuclear engine.

How to overcome the obstacles to AI/ML

What would a sensible person do? Exactly what real-life people did in history: incrementally make boats suitable for more powerful means of locomotion, and make more powerful means of locomotion that would make boats go more quickly. Practically. You know, in real life.

That means, among other things, once steam power was created, gradually make it suitable for powering ships with sails -- using the sails to conserve coal when the wind was strong, and using coal to power paddles when the wind wasn't blowing. Then, after materials advanced, invent the screw propeller -- which didn't happen until the late 1800's -- to make things even better. Eventually, the engine and the ship would converge and be suitable for the introduction of nuclear power.

This is an excellent model for understanding how to overcome the obstacles to powering existing enterprise applications with AI/ML:

• The AI/ML can only be jammed into existing systems with great effort and by making serious compromises.
  • With a few exceptions, simpler methods that can make real-life improvements should be devised and introduced first, with the portion of AI/ML gradually increasing.
• The existing enterprise applications are like wooden sailing ships, into which generation-skipping advanced locomotion simply can't be jammed.
  • Evolve the applications with automated decision-making in mind, first putting in simple methods that will produce quick returns.
  • The key to AI-friendly evolution is to center the application architecture on metadata in general, and in particular with metadata for workflow.

The important thing is this: increase the "intelligence" of your applications step by step, concentrating on simple changes for big returns. Who cares whether and to what extent AI/ML is used to make improvements? All that matters is that you make frequent changes to improve the effectiveness, appropriateness and personalization of your applications. Experience shows that relatively simple changes tend to make the greatest impact. See this series of posts for more detail.

 

The Facts are Clear: Hypertension is not a Disease

The medical community, organizations and government agencies couldn't be clearer: hypertension (high blood pressure) is a silent killer. You may not feel anything wrong, but if you've got it, your risk of strokes and heart failure goes way up. Therefore it's essential to monitor and treat this deadly condition.

They're all wrong. Hypertension is not a disease that needs to be cured. It may be a symptom of a problem, but not a problem itself, just like fever is a symptom, not the underlying problem. By treating it as a disease and giving drugs to lower blood pressure, the medical establishment makes patients less healthy and raises costs substantially. With a few exceptions, we would all be better off ignoring blood pressure and most of the associated advice.

Drugs for "Curing" Hypertension

The single most prescribed drug in the US is for lowering cholesterol. But most prescriptions for a disease are to reduce blood pressure.

Here's the story with blood pressure pills.

In fact, a majority of the most prescribed drugs in the U.S. are used to treat high blood pressure or symptoms of it. That’s because 108 million or nearly half of adults in the U.S. have hypertension or high blood pressure.

Is Hypertension a Disease?

There is no doubt that blood pressure can be measured and that it varies greatly. What is hypertension? As I describe here, currently it's a systolic pressure reading above 120 (until 2017 it was above 140). There are lots of things you can measure about people. What makes this measurement bad?

There's a clue buried deep in Doctor-language, a clue that is nearly always missed -- but it's one that doctors with a basic education should know. The official name for high blood pressure is essential hypertension. What's that? Let's ask Dr. Malcolm Kendrick, a long-experienced cardiologist:

At medical school we were always taught – and this has not changed as far as I know – that an underlying cause for high blood pressure will not be found in ninety per cent of patients.

Ninety per cent… In truth, I think it is more than this. I have come across a patient with an absolute, clearly defined cause for their high blood pressure about five times, in total, and I must have seen ten thousand people with high blood pressure. I must admit I am guessing at both figures and may be exaggerating for dramatic effect.

Whatever the exact figures, it is very rare to find a clear, specific cause. The medical profession solved this problem by calling high blood pressure, with no identified cause, “essential hypertension”. The exact definition of essential hypertension is ‘raised blood pressure of no known cause.’ I must admit that essential hypertension certainly sounds more professional than announcing, ‘oh my God, your blood pressure is high, and we do not have the faintest idea why.’ But it means the same thing.

Hypertension = your blood pressure number is high. Kind of like having a high temperature, which we call a "fever," right? Wrong. When you get a fever, doctors first make an effort to determine the cause of the fever! What an idea! The fever is a clue that something is wrong, not the problem itself! Here's the real, bottom-line clue: When you treat fever you treat the underlying cause e.g. bacterial infection, NOT the fever itself! If we treated fever the way we treat hypertension, we would give drugs whose sole purpose was to lower the body temperature, ignoring the underlying bacterial infection that caused the fever. Wouldn't do any good! Maybe we'd sweat less, but the bacteria would rage away inside our bodies. But high blood pressure? Doctors ignore the cause and "treat" the symptom, which can often do more harm than good -- except of course for the drug makers, who make out just fine.

Makes me sick.

Causes of hypertension

From Kendrick:

So, why does the blood pressure rise in some people, and not in others. It is an interesting question. You would think that, by now, someone would have an answer, but they don’t. Or at least no answer that explains anything much.

Just as fever is caused by an infection (or something else), could it be possible that hypertension results from some underlying problem? Kendrick again:

Looking at this from the other direction, could it be that cardiovascular disease causes high blood pressure. Well, this would still explain why the two things are clearly associated, although the causal pathway may not be a → b. It could well be b → a.

I must admit that I like this idea better, because it makes some sense. If we think of cardiovascular disease as the development of atherosclerotic plaques, leading to thickening and narrowing of the arteries then we can see CVD is going to reduce blood flow to vital organs, such as the brain, the kidneys, the liver, the heart itself.

These organs would then protest, leading to the heart pumping harder to increase the blood flow and keep the oxygen supply up. The only way to increase blood flow through a narrower pipe, is to increase the pressure. Which is what then happens.

Over time, as the heart is forced to pump harder, and harder, the muscle in the left ventricle will get bigger and bigger, causing hypertrophy. Hypertrophy means ‘enlargement.’ So, in people with long term, raised blood pressure, we would expect to see left ventricular hypertrophy (LVH). Which is exactly what we do see.

He goes on to give lots of detail about how this takes place, if you're interested.

Correlation and Causation

There's a little problem that everyone who knows about science and statistics is supposed to know. It's the difference between correlation and causation. Two things seem to happen at the same time. They are correlated. No problem. But does one of the cause the other? That's a whole other thing, and it's super-important. At McDonald's, burgers and fries are often seen together. They're correlated. Did the burger cause the fries? Fries cause the burgers? Nope. They're just listed together on the menu and lots of people like them together.

How about knife cuts and bleeding? Definitely correlated. Causation? By looking at repeated cases of knives making cuts, you can determine that putting a knife into someone's skin nearly always causes bleeding.

This is the problem at the heart of hypertension -- except perhaps in extreme cases, hypertension can be correlated with heart attacks and strokes -- but it can't be shown to cause them in the vast majority of cases.

The range of blood pressure

The authorities don't like to talk about this, but blood pressure varies HUGELY not just from person to person, but also by age and for a single person during the day!

Here's something to give you the idea from a scientific paper:

The range of pressure for a single person can be rather larger. I just took my pressure this morning. The systolic was 126. In the previous days the readings were 159 and 139.I have taken my pressure with different devices over a year, and that variation is not unusual. It can vary that much in a couple hours, depending on my activity level.

It is well-known in the medical community that blood pressure varies naturally with age, generally rising as you get older. Has anyone documented this statistically? If they have, I can't find it. Generally, what is normal is roughly 100 plus your age, so a 50 year old man would have 150, roughly 10 less for women. Here is an interesting description of the age factor from a former NASA astronaut and doctor.

The assumed causation fails to hold

A surprising amount of modern medical misinformation goes back to the diet-heart hypothesis put forward by Ancel Keys and supported by the seven countries study. It's what led to the obesity-causing fat-is-bad diet recommendations and the ongoing harm of reducing blood cholesterol using statins. Out of the same witch's brew came the notion that high blood pressure causes heart disease.This notion was supposedly locked down by the famous Framingham study, which continues to this day.

In the year 2000, the edifice crashed when a careful review was published in the journal of the European Society of Cardiology, "There is a non-linear relationship between mortality and blood pressure." It includes references to the original Keys study and many following journal articles.

The article is prefaced by a quote that is so appropriate, I can't help but share it with you:

"For every complicated problem there is a solution that is simple, direct, understandable, and wrong." H. L. Mencken

The authors start by explaining the current paradigm:

"the relation of SBP (systolic blood pressure) to risk of death is continuous, graded and strong..." The formulation of this "lower is better" principle ... forms the foundation for the current guidelines for hypertension.

They point out that Ancel Keys himself concluded that "the relationship of overall and coronary heart disease death to blood pressure was unjustified."

They went on to examine the detailed Framingham study data.

Shockingly, we have found that the Framingham data in no way supported the current paradigm to which they gave birth.

...

Systolic blood pressure increases at a constant rate with age. In sharp contrast to the current paradigm, we find that this increase does not incur additional risk. More specifically, all persons in the lower 70% of pressures for their age and sex have equivalent risk.

Cardiologist Kendrick in his recent book Doctoring Data points out

Has this paper ever been refuted? No, it has not. Sadly, it was given the worst possible treatment that can be dished out by the medical establishment. It was completely ignored.

...

The benefits of blood-pressure lowering, whatever the level, became so widely accepted years ago that it has not been possible, ethically,[viii] to do a placebo-controlled study for a long time. I am not aware of any placebo-controlled trials that have been done in the last twenty years, or so.

A bit of sanity

The same year (2017) the AHA and cardiologists were lowering the target blood pressure for everyone from 140 to 120, a group representing family physicians published an official guideline for treating hypertension in adults age 60 and over. Their method was rigorous, taking into account all available studies. Here is their core recommendation:

ACP and AAFP recommend that clinicians initiate treatment in adults aged 60 years or older with systolic blood pressure persistently at or above 150 mm Hg to achieve a target systolic blood pressure of less than 150 mm Hg to reduce the risk for mortality, stroke, and cardiac events. (Grade: strong recommendation, high-quality evidence).

What a breath of fresh air! And completely in line with this data-driven review that showed that a large number of people taking anti-hypertensive drugs just 1 in 125 were helped (prevented death), while 1 in 10 were harmed by side effects. Also in line with this careful study of people with elevated blood pressure in the range of 140-160; the study showed that none were helped by drugs, while 1 in 12 were harmed.

BTW, if you're not familiar with the concept of NNT, you should learn about it. It's crucial.

Hypertension Drugs can hurt you

Doctors dish out hypertension drugs like candy. It's often the case that two different kinds of drugs will be required to get your blood pressure to "safe" levels. For reasons that don't seem to be studied, it's rare indeed for doctors to mention side effects; yet in repeated studies, the generally data-suppressing researchers can help but mention that the side effects are so bad that roughly 10% of study participants drop out of the study! (See above for references.)

There are good lists of side effects at Drugs.com. Here's some information about Amlodipine:

Side effects requiring immediate medical attention

Along with its needed effects, amlodipine may cause some unwanted effects. Although not all of these side effects may occur, if they do occur they may need medical attention.

Check with your doctor immediately if any of the following side effects occur while taking amlodipine:

More common

• Swelling of the ankles or feet

Less common

• Chest tightness
• difficult or labored breathing
• dizziness
• fast, irregular, pounding, or racing heartbeat or pulse
• feeling of warmth
• redness of the face, neck, arms, and occasionally, upper chest

Rare

• Black, tarry stools
• bleeding gums
• blistering, peeling, or loosening of the skin
• blood in the urine or stools
• blurred vision
• burning, crawling, itching, numbness, prickling, "pins and needles", or tingling feelings
• chest pain or discomfort
• chills
• cold and clammy skin
• cold sweats
• confusion
• cough
• dark yellow urine
• diarrhea
• dilated neck veins
• dizziness or lightheadedness when getting up from a lying or sitting position
• extra heartbeats
• fainting
• fever
• itching of the skin
• joint or muscle pain
• large, hive-like swelling on the face, eyelids, lips, tongue, throat, hands, legs, feet, or sex organs
• numbness and tingling of the face, fingers, or toes
• pain in the arms, legs, or lower back, especially pain in the calves or heels upon exertion
• painful or difficult urination
• pale, bluish-colored, or cold hands or feet
• pinpoint red or purple spots on the skin
• red, irritated eyes
• redness of the face, neck, arms, and occasionally, upper chest
• redness, soreness or itching skin
• shakiness in the legs, arms, hands, or feet
• slow or irregular heartbeat
• sore throat
• sores, ulcers, or white spots on the lips or in the mouth
• sores, welting, or blisters
• sudden sweating
• sweating
• swelling of the face, fingers, feet, or lower legs
• swollen glands
• trembling or shaking of the hands or feet
• unsteadiness or awkwardness
• unusual bleeding or bruising
• unusual tiredness or weakness
• weak or absent pulses in the legs
• weakness in the arms, hands, legs, or feet
• weight gain
• yellow eyes or skin

Then there are the ones judged to be less severe:

Side effects not requiring immediate medical attention

Some side effects of amlodipine may occur that usually do not need medical attention. These side effects may go away during treatment as your body adjusts to the medicine. Also, your health care professional may be able to tell you about ways to prevent or reduce some of these side effects.

Check with your health care professional if any of the following side effects continue or are bothersome or if you have any questions about them:

Less common

• Acid or sour stomach
• belching
• feeling of warmth
• heartburn
• indigestion
• lack or loss of strength
• muscle cramps
• redness of the face, neck, arms, and occasionally, upper chest
• sleepiness or unusual drowsiness
• stomach discomfort, upset, or pain

Those are the issues with just one of the many hypertension drugs, one of the most widely prescribed!

Conclusion

Blood pressure varies greatly, reflecting the human body's amazing self-regulation systems. In the vast majority of cases, blood pressure goes up with age. Lowering it by drugs does more harm than good. Except perhaps in extreme cases, high blood pressure does not cause disease. When pressure is extremely high, a search for the cause should be made. The ongoing focus on hypertension as a disease reflects nothing but the stubborn refusal of the medical establishment to admit that they were wrong, and of the pharma companies to give up a lucrative market.

Flowcharts and Workflow in Software

The concept of workflow has been around in software from the beginning. It is the core of a great deal of what software does, including business process automation. Workflow is implicitly implemented in most bodies of software, usually in a hard-coded, ad-hoc way that makes it laborious and error-prone to implement, understand, modify and optimize. Expressing it instead as editable declarative metadata that is executed by a small body of generic, application-independent code yields a huge increase in productivity and responsiveness. It also enables painless integration of ML and AI. There are organizations that have done exactly this; they benefit from massive competitive advantage as a result.

Let’s start with some basics about flowcharts and workflow.

Flowcharts

Flowcharts pre-date computers. The concept is simple enough, as shown by this example from Wikipedia:

The very earliest computer programs were designed using flowcharts, illustrated for example in a document written by John von Neumann in 1947. The symbols and methods became standardized. By the 1960’s software designers used templates like this from IBM

to produce clean flowcharts in standardized ways.

Flowcharts and Workflow

Flowcharts as a way to express workflows have been around for at least a century. Workflows are all about repeatable processes, for example in a manufacturing plant. People would systematize a process in terms of workflow in order to understand and analyze it. They would create variations to test to see if the process could be improved. The starting motivation would often be consistency and quality. Then it would often shift to process optimization – reducing the time and cost and improving the quality of the results. Some of the early work in Operations Research was done to optimize processes.

Workflow is a natural way to express and help understand nearly any repeatable process, from manufacturing products to taking and delivering orders in a restaurant. What else is a repeatable process? A computer program is by definition a repeatable process. Bingo! Writing the program may take considerable time and effort, just like designing and building a manufacturing plant. But once written, a computer program is a repeatable process. That’s why it made sense for the very earliest computer people like John von Neumann to create flowcharts to define the process they wanted the computer to perform repeatedly.

What’s in a Flowchart?

There are different representations, but the basic work steps are common sense:

• Get data from somewhere (another program, storage, a user)
• Do something to the data
• Test the data, and branch to different steps depending on the results of the test
• Put the data somewhere (another program, storage, a user)
• Lots of these work steps are connected in a flow of control

This sounds like a regular computer software program, right? It is! When charted at the right level of detail, the translation from a flowchart to a body of code is largely mechanical. But humans perform this largely mechanical task, and get all wrapped up in the fine details of writing the code – just like pre-industrial craftsmen did.

Hey, that's not just a metaphor -- it is literally true! The vast, vast majority of software programming is done in a way that appears from the outside to be highly structured, but in fact is designing and crafting yet another fine wood/upholstery chair (each one unique!) or, for advanced programmers, goblets and plates made out of silver for rich customers.

Workflow

In the software world, workflow in general has been a subject of varying interest from the beginning. It can be applied to any level of detail. It has led to all sorts of names and even what amount to fashion trends. There is business process management. Business process engineering. And re-engineering. And business process automation. A specialized version of workflow is simulation software, which led early programmers to invent what came to be called "object-oriented programming." To see more about this on-going disaster that proved to be no better for simulating systems than it has been for software in general, see this.

When document image processing became practical in the 1980’s, the related term workflow emerged to describe the business process an organization took to process a document from its arrival through various departments and finally to resolution and archiving of the document. The company that popularized this kind of software, Filenet, was bought by IBM. I personally wrote the workflow software for a small vendor of document image processing software at that time.

Workflow in practice

There has been lots of noise about what amounts to workflow over the years, with books, movements and trends. A management professor in the 1980's talked about how business processes could be automated and improved using business process re-engineering. He said that each process should be re-thought from scratch -- otherwise you would just be "paving the cow paths," instead of creating an optimal process. As usual, lots of talk and little action. Here's the story of my personal involvement in such a project in which the people in charge insisted they were doing great things, while in fact they were spending lots of money helping the cows move a bit faster than they had been.

The Potential of Workflow

The potential of workflow can be understood in terms of maps and driving from one place to another. I've explained the general idea here.

Most software design starts with the equivalent of figuring out a map that shows where you are and where you want to get to. Then the craftsmanship begins. You end up with a hard-coded set of voluminous, low-level "directions" for driving two blocks, getting in the left lane, turning left, etc.

When the hard-coded directions fail to work well and the complaints are loud enough, the code is "enhanced," i.e., made even more complex, voluminous and hard to figure out by adding conditions and potential directional alternations.

Making the leap to an online, real time navigation system is way beyond the vast majority of software organizations. You know, one that takes account of changes, construction, feedback from other drivers on similar routes about congestion, whether your vehicle has a fee payment device installed, whether your vehicle is a truck, etc. Enhancements are regularly made to the metadata map and the ML/AI direction algorithms, which are independent of map details.

When software stays at the level of craftsmanship, you're looking at a nightmare of spaghetti code. Your cow paths aren't just paved -- they have foundations with top-grade rebar, concrete and curbs crafted of marble.

Conclusion

Metadata-driven workflow is the next step beyond schema enhancement for building automated systems to perform almost any job. It's a proven approach that many organizations have deployed -- literally for decades. But all the leaders of computing, including Computer Science departments at leading universities, remain obsessed with subjects that are irrelevant to the realities of building software that works; instead they stay focused on the wonders of craftsman-level low-level software languages. It's a self-contained universe where prestige is clearly defined and has nothing to do with the eternal truths of how optimal software is built.