Uber Mathematics 4

As I have previously noted, drawing on research by Izabella Kaminski and others, there is something seriously problematic about the current business model of rideshare platforms such as Uber and Lyft. It seems that the only route to profitability is via some disruptive event in favour of their business. Although investors have poured eye-watering amounts of cash into these companies, this only makes sense as a bet on such an event occurring before the cash (or investor patience) runs out.

How does the magic of digital allow a centralized company with international overheads (Uber or Lyft) provide a service more cheaply and cost-effectively than a distributed network of local cab companies, many of which are run by one rather harassed guy in a small booth next to the train station? Well it doesn't. Even screwing the drivers can only go so far in stemming the losses.

So what is this disruptive event, that these companies and their investors are eagerly waiting for? One theory was that the rideshare platforms could only be profitable once they had eliminated all competition, by a combination of undercutting rivals and doing deals with local authorities - for example, offering to run other elements of the local transport network. Once a monopoly had been established, then they could start to push the prices up.

Obviously this strategem only works if the consumers accept the price rises, and the guy in the booth doesn't find a way to take back his business.

Another theory was that they were just waiting for self-driving cars. This would also explain why they weren't looking after their drivers properly, because they didn't expect to need them for the longer-term. However, not everyone was convinced by this. Aaron Benanav thought that they will have to wait rather longer than they originally reckoned, while Sameepa Shetty noted that Uber's ambitions in this regard were currently focused on small favourable pockets rather than being spread across the whole operation, and quoted an analyst who worried that investors were throwing good money after bad. 

At the end of 2020, we learned that Uber itself had come to the same conclusion, selling off the driverless car division to focus on profits.

So remind me, where are these profits coming from?

---

Uber sells self-driving cars to focus on profits (BBC News, 7 December 2020)

Aaron Benanav, Why Uber's business model is doomed (Guardian, 24 August 2020)

Julia Kollewe, Uber ditches effort to develop own self-driving car (Guardian, 8 December 2020)

Elaine Moore and Dave Lee, Does Uber deserve its $91bn valuation? (FT, 17 October 2021)

Sameepa Shetty, Uber’s self-driving cars are a key to its path to profitability (CNBC, 28 January 2020)

Gwyn Topham, Peak hype: why the driverless car revolution has stalled (Guardian, 3 January 2021)

Related Posts Uber Mathematics (Nov 2016), Uber Mathematics 2 (December 2016), Uber Mathematics 3 (Dec 2016)

Process Automation and Intelligence

What kinds of automation are there, and is there a natural progression from basic to advanced? Do the terms intelligent automation and cognitive automation actually mean anything useful, or are they merely vendor hype? In this blogpost, I shall attempt an answer.


Robotic Automation

The simplest form of automation is known as robotic automation or robotic process automation (RPA). The word robot (from the Czech word for forced labour, robota) implies a pre-programmed response to a set of incoming events. The incoming events are represented as structured data, and may be held in a traditional database. The RPA tools also include the connectivity and workflow technology to receive incoming data, interrogate databases and drive action, based on a set of rules.

Cognitive Automation

People talk about cognitive technology or cognitive computing, but what exactly does this mean? In its marketing material, IBM uses these terms to describe whatever features of IBM Watson they want to draw our attention to – including adaptability, interactivity and persistence – but IBM’s usage of these terms is not universally accepted.

I understand cognition to be all about perceiving and making sense of the world, and we are now seeing man-made components that can achieve some degree of this, sometimes called Cognitive Agents.

Cognitive agents can also be used to detect patterns in vast volumes of structured and unstructured data and interpret their meaning. This is known as Cognitive Insight, which Thomas Davenport and Rajeev Ronanki refer to as “analytics on steroids”. The general form of the cognitive agent is as follows.

Cognitive agents can be wrapped as a service and presented via an API, in which case they are known as Cognitive Services. The major cloud platforms (AWS, Google Cloud, Microsoft Azure) provide a range of these services, including textual sentiment analysis.

At the current state-of-the-art, cognitive services may be of variable quality. Image recognition may be misled by shadows, and even old-fashioned OCR may struggle to generate meaningful text from poor resolution images. – but of course human cognition is also fallible.


Intelligent Automation

Meanwhile, one of the key characteristics of intelligence is adaptability – being able to respond flexibly to different conditions. Intelligence is developed and sustained by feedback loops – detecting outcomes and adjusting behaviour to achieve goals. Intelligent automation therefore includes a feedback loop, typically involving some kind of machine learning.

Complex systems and processes may require multiple feedback loops (Double-Loop or Triple-Loop Learning). 


Edge Computing

If we embed this automation into the Internet of Things, we can use sensors to perform the information gathering, and actuators to carry out the actions.

Closed-Loop Automation

Now what happens if we put all these elements together?

This fits into a more general framework of human-computer intelligence, in which intelligence is broken down into six interoperating capabilities.

I know that some people will disagree with me as to which parts of this framework are called "cognitive" and which parts "intelligent". Ultimately, this is just a matter of semantics. The real point is to understand how all the pieces of cognitive-intelligent automation work together.


The Limits of Machine Intelligence

There are clear limits to what machines can do – but this doesn’t stop us getting them to perform useful work, in collaboration with humans where necessary. (Collaborative robots are sometimes called cobots.) A well-designed collaboration between human and machine can achieve higher levels of productivity and quality than either human or machine alone. Our framework allows us to identify several areas where human abilities and artificial intelligence can usefully combine.

In the area of perception and cognition, there are big differences in the way that humans and machines view things, and therefore significant differences in the kinds of kinds of cognitive mistakes they are prone to. Machines may spot or interpret things that humans might miss, and vice versa. There is good evidence for this effect in medical diagnosis, where a collaboration between human medic and AI can often produce higher accuracy than either can achieve alone.

In the area of decision-making, robots can make simple decisions much faster, but may be unreliable with more complex or borderline decisions, so a hybrid “human-in-the-loop” solution may be appropriate. 

Decisions that affect real people are subject to particular concern – GDPR specifically regulates any automated decision-making or profiling that is made without human intervention, because of the potential impact on people’s rights and freedoms. In such cases, the “human-in-the-loop” solution reduces the perceived privacy risk. In the area of communication and collaboration, robots can help orchestrate complex interactions between multiple human experts, and allow human observations to be combined with automatic data gathering. Meanwhile, sophisticated chatbots are enabling more complex interactions between people and machines.

Finally there is the core capability of intelligence – learning. Machines learn by processing vast datasets of historical data – but that is also their limitation. So learning may involve fast corrective action by the robot (using machine learning), with a slower cycle of adjustment and recalibration by human operators (such as Data Scientists). This would be an example of Double-Loop learning.


Automation Roadmap

Some of the elements of this automation framework are already fairly well developed, with cost-effective components available from the technology vendors. So there are some modes of automation that are available for rapid deployment. Other elements are technologically immature, and may require a more cautious or experimental approach.

Your roadmap will need to align the growing maturity of your organization with the growing maturity of the technology, exploiting quick wins today while preparing the groundwork to be in a position to take advantage of emerging tools and techniques in the medium term.

---

Thomas Davenport and Rajeev Ronanki, Artificial Intelligence for the Real World (January–February 2018)

Related posts: Automation Ethics (August 2019), RPA - Real Value or Painful Experimentation? (August 2019)

Business rules are forking

Another good post from @tetradian on business rules in response to James Taylor’s recent piece reporting Gartner's view that Business rules are king.

Tom agrees with James Taylor about the importance of discipline around business rules, but objects to an interpretation of business rules that goes back to Taylor's namesake Frederick Winslow Taylor.

Tom distinguishes between decision-support (where the decision is made by a collaboration between an automated system and human judgement) and automated decision-making (where there is no space for human judgement). This distinction is not always clear-cut - if the human actants within a complex business process lack the information, intelligence, attention or confidence to overrule the computer's suggested answer, then a decision-support system becomes defacto a decision-making system.

We should also distinguish between simple rules (binary logic) and more complex rules (modal logic, probabilistic logic). As Tom points out, much of the rule industry appears to assume simple composition of simple binary rules, which are inadequate for most interesting business problems (three quarters of his context space mapping framework).

Tom makes three important points

• We should not assume that the business rules are sufficient, invariant, accurate and complete, especially if they are derived from the people who run the existing processes. Therefore the identification and codification of business-rules generally leaves something to be desired. (One way of putting this is that the Real resists symbolization.)

• There needs to be a very strong emphasis on rule-maintenance, otherwise placing all the business-rules into an automated system will lead to a fit and forget attitude. (One way of putting this is a demand for double-loop or deutero-learning.)

• The viability of using automation for decision-making is dependent on the context.

---

In his new book Obliquity, John Kay discusses the example of waiting for a bus. According to the timetable, a bus should come every ten minutes. There are two rules that should help you decide whether to wait for the bus or walk - except that these two rules contradict each other.

Rule One says the longer you wait for the bus, the more likely it is to arrive soon. So if you have waited for nine minutes, it is practically certain to arrive in the next minute.

Rule Two says that the longer you wait for the bus, the more likely it is that Rule One is incorrect. So if you have waited more than nine minutes for the bus, it is starting to look as if the bus will never come at all.

If you have waited more than half-an-hour for the bus, then common sense suggests that Rule Two is in force. But as Kay points out, many people (including those who drove banks into bankruptcy) appear incapable of shifting from Rule One to Rule Two.

In real business situations, there is always a balance between following a rule and questioning the rule. It is not just automated systems that may fail to strike this balance; many people with significant business responsibility lack common sense. This is an important aspect of the context for decision-making.

---

Update September 2020

Prompted by the current interest in RPA, I've been looking over my old blogposts on Business Rules.

I'm not sure I agree with Tom's point that humans are good at modal logic - there are whole schools of psychotherapy devoted to unpacking common misuses of modal operators, for example reframing "always" and "never" into "sometimes". But individuals may be better than machines (whether computer machines or bureaucratic machines). 

James Taylor's post quotes Jim Sinur recommending a focus on high volatility rules - which would seem to tell against the "fit and forget" attitude Tom warns us about. But jumping forward ten years, we find RPA vendors recommending a focus on using bots for the low volatility rules. Meanwhile "mutant algorithms" try to tackle probabilistic decision-making. The issues raised in his post are clearly relevant to this new technology landscape.

Supply Chain Complexity

Clive Longbottom of Quocirca has just published a survey of the adoption by medium to large organizations of supply chain automation. Here is his conclusion.

Automation of transactions has long been touted as an enabler of efficiency in the B2B supply and demand chains. The irony is, however, that the more broadly organisations attempt to apply automation, the more they fall foul of the complexity and expense of dealing with the myriad of technologies and standards that exists across their customer and supplier bases. Few have the capability to solve this problem in-house cost effectively, so outsourcing options that leverage economies of scale are key to achieving broad and inclusive automation and realising the benefits that come from this. (via Conmergence blog)

There are many sources of supply chain complexity implied in this piece, besides the complexity and continuing evolution of technical standards.

• a significant focus on ad hoc activity particularly with customers, where one off sales are common
• large numbers of partners with differing characteristics and capabilities
• high complexity in the standards
• rate of change of partners’ technical solutions
• multiple versions of standards in the value chain
• geopolitical issues e.g. local legal, native language and logistical issues
• myriad of technologies and standards

While it seems like a good idea to delegate some of these dimensions of complexity to a managed service provider, this may not be appropriate for all of them. The most obvious solution is that the service provider handles the technological complexity, leaving the company to concentrate on the business complexity. However, it is unlikely to be as simple as this in practice, because of possible interactions between the technological complexity and the business complexity.

What is needed here is to analyse the dimensions of complexity in detail (obviously this analysis won't be identical for different companies) and produce a service geometry with a clean but flexible division between core and non-core.

Technorati Tags: B2B complexity outsourcing supply chain technology adoption

Electronic Flight Bag

Some initial remarks about the concept of the Electronic Flight Bag, first posted in February 2005.

The electronic flight bag (EFB) is a concept for reducing or replacing an airline pilot’s flight bag with an electronic equivalent. ICM has implemented this concept in the form of an integrated product, for sale to commercial airlines, in cooperation with Intel, Jeppesen and IONA.
IONA marketing sheet (pdf)

I have not looked at the detail of this product, so I cannot comment on it. What I want to explore in this post are some of the more general implications of this kind of product, in an SOA context.

From the product marketing material, I extract three points about the flight bag.

1. It is a familar object in commercial aviation.
2. Commercial airlines would benefit from automating this object. ("The aviation industry has long recognized the benefits of replacing paper in the cockpit with an electronic document delivery system.")
3. However, this is a complex object that has previously resisted automation. (Reference to limitations in technology along with regulatory and standardization issues.)

In previous waves of automation we saw isolated paperwork systems being colonized by the computer, and then we saw links being built between these isolated systems. Complex and highly connected objects like the flight bag missed out on these waves of automation, for several interlinked reasons.

To automate the flight bag, we need to conceptualize it as the living centre of a highly complex system - with secure and reliable links into many other operational systems both inside the airline and within other organizations (airport? plane maintenance? air traffic control? GIS?). The electronic flight bag therefore becomes a centre within a network of centres. It is this kind of automation that this characteristic of the SOA wave.

And this kind of automation calls for a different kind of process. We may start with a familiar concept (the paperless xyz - in this case, the paperless cockpit). But we then need to model the implications of this paperlessness in terms of the multiple functions of paper in a given ecosystem. We then have to form a collaboration between several suppliers to compose a solution, that can then be composed in turn with the context of use in a given airline.

I have a mental image of something like a brain transplant - the transplanted brain will only work if you make all the right connections. Obviously there are technological advances (notably web services) that make this task a bit easier - but you have to think about the organizational implications as well, so it remains a challenge.

Although some of the marketing material describes the product as "complete", this appears to conflict with the statement that it is "designed for built-in integration and growth". From an SOA perspective, I hope the latter is true.

The electronic flight bag is a good step towards an SOA world (continuous network of services) if it satisfies four criteria:

1. It creates a new service in its own right.
2. It is composed of smaller services.
   
3. It helps to complete one or more larger-scale services.
4. It hints at future larger-scale services - it opens up future possibilities that we haven't yet fully formulated.

---

Update (June 2020)

Since I wrote this post, the Electronic Flight Bag has been developed and adopted across many parts of the aviation business. See Wikipedia: Electronic Flight Bag (article first created January 2006)