Beyond mobility and modern apps

The problem with “mobility” and actually all applications is this. We need to move away from monolithic applications that are rules-based and very rigidly architected and towards applications that are more fluid, agile, and even evolutionary.

If you consider the classic example of an order management system, the rigid structure is plain. There are orders. Each order has properties associated with it like date, time, sales agent.  Order details have information about the individual items ordered, their status regarding availability, price, cost, quantity, and the like. Order headers usually summarize this information into totals. The desktop app usually allows a subset of orders to be chosen according to security access, and then allows the user to select an individual order to see its header information and totals, and then allows the user to drill down into the header to see the details for the individual items on the order.  And then, the user can sometimes do things with the individual items or even the whole order like cancel it, approve it for release from inventory, send it to shipping, or back-order certain items.  The so-called modern app, which is device-centric, can implement this functionality easily. SAP Fiori , for example, targets this particular app squarely.  Both modern apps and desktop apps can do this the same way, and it will work.

But, one of the problems that either platform has is the ability to pare down the work and get the user quickly to the right order or set of orders.  The way both solutions implement this is with filters.  The user needs to know in advance what filter to use to get the ones she wants to work with. The developer or IT department can help by pre-configuring some common filters like “open orders with a ship date within 5 days”, “orders with at least one item on back-order older that is 1 week past the original ship date” and the like.  The problem has always been that if there are not very many orders, the app works easily and delightfully. But then again, if there are not many orders then a pen and paper can run the business.  However, if there are many orders, the user might spend most of their time just trying to filter for the right orders or scroll through a large list looking for the right orders, so that they can finally enjoy the experience of “swipe-right-tap-once-and-you’re-done” that is so “delightful”.   We need to move away from all this.  What we need is for the apps to be allowed to learn and evolve so that they automatically surface to us what we care about and what we need to decide.

I’m not sure if this goes firmly under the category of Artificial Intelligence (AI) or not.  If you think about the way humans learn from an early age, it might help.  A child learns that some things are bad and others good.  Bad things could be inherently bad or artificially bad.  I touched the stove and burned my hand. That was bad (inherently).  I hit my sister and got sent to timeout. That was bad (artificially). I swam in the cool pool on a hot day. That was good (inherently). I ate all my meat and so I got pudding. That was good (artificially).  One of the differences between computers and humans is in the way we decide. Computers can iterate through enormous sets of data and analyze each one in a very tedious, monotonous way to come up with a definitive selection. Humans cheat. We use intuition, hunch, prior experience, elimination of nonsense, and the like, to arrive at answers quicker.  We process a lot of information but not in the same way computers do. I believe the answer to getting the most out of modern apps is to teach them the concept of good and bad, and empower them to use their iteration skills to arrive at the same place as humans so that we work together, so that the device is an extension of the human.

For example, if the computer (browser, phone, tablet, whatever) is allowed to know that back-orders are bad.  Back-orders that are older than a week past the original ship date are worse. Back-orders for our most important customers are worse.  Back orders where there is a comment on the order about someone canceling our contract and giving all their business to our competitor is bad, even if it’s not a week past due.  And it’s also bad if that comment is on the customer master record or another order from the same customer, or on another customer in the system who is really the same as this customer even though they have a different customer number.

In monolithic systems the software doesn’t evolve. The developers evolve.  What I mean is that the software gets released.  If it’s modern software it gets continually released by making agile updates every week or so.  As the app is field tested new conditions are learned, more complexity is modeled, and richer functionality is included.  Things like bad back-order situations.  But, bad back order situations being discovered and hard-coded into the apps by humans is inefficient. It’s not what humans are inherently good at doing, which is why it takes so long in the field to achieve this level of app maturity.  What we need is to teach the computer things that are bad (have negative consequences or are unpleasant), and unleash them to find those and surface them to us so that together we can avert them.  What we need is to teach the computer things that are good (reward us or please us), and unleash them to find those and surface them to us so that we can “swipe-right-one-tap” them together.  This won’t be simple, but this is what needs to happen.

First, the computer is going to have to know some basics about what business is.  These are customers. We want to make them happy.  When we have a customer we put them into the database and assign them a number.  But a customer could have lots of numbers because sometimes we have a sell-to customer, and ship-to customers, and sometimes customers are just addresses or people that have special meanings depending on what app is using them.  They all work together to help us serve our customer well, which is GOOD.

Next, the computer needs to be free to traverse all the data in the system and surface things to us like, “Hey Jane, are these customers related? They’re not linked on the customer master screen, but they have very similar names. They are? Ok, them I’m going to add that to my black book of customer relationships for future reference.”  There are many implications of this type of interaction. For example, another app could come and look at that discovered information in the black book and suggest merging and restating all the history, and then retiring the customer that was erroneously added when someone couldn’t find the correct customer (because the human couldn’t spell the original customer’s name).  Or, once these discoveries are made, the app might come along be allowed to realize that there are several large orders, related to a customer, that are all back-ordered, or that are all set to arrive at the same time, and suggest, “Hey John, you might want to call this customer and let them know what they’re about to deal with.”

Compare this paradigm to something like “Boom Beach”, an app available for iOS.  There are good things and bad things that can happen to your civilization. Good: “Commander, your troops are ready.”  Bad: “Home base raided.”  Good: “Home base defended.”  Bad: “Village lost.”  In this case the computer knows what things are considered good or bad, and surfaces them.  It’s fairly simple to do because there are a limited set of conditions that are good or bad due to the limitations of the game.

For business, there could be many more, and much more complex conditions that are good and bad, but when the conditions are found they can be surfaced in much the same way.  Check these orders.  Call these customers.  Review these mishaps and take action.   Again, this problem can be solved in two ways.  Solve it monolithically by field testing the app and updating the top-down code to be more and more complicated to handle the newly discovered conditions.  Solve it modernly by allowing the computer to evolve.  It goes without saying that trusting the computer with concepts of good and bad, and asking it to surface actionable conditions only will have problems: some conditions will be missed and some conditions will be non-issues that clutter the app and waste time.  But, this is the next frontier, and once we get this to work fairly well there will be an acceleration of app innovations possible.  Until then all we're doing is working bloodshot developers around the clock to create the illusion of apps that are delightful, and under-utilizing computing power.