Disintermediation, business modularity and marketplaces

Four out of the five last business executives I’ve spoken with as a Microsoft Digital Advisor, one way or another, care about the topics in the title of this post. They’re in different industries, from agribusiness, logistics, and of course, banking; they might have used different terms, but they all do have these concepts in mind, although not necessarily all the dots are clearly connected. Here I’m covering a personal viewpoint on how these concepts are interconnected.

Let’s start with disintermediation. Disintermediation is the elimination of intermediaries in a value chain. Netflix having it’s own production studios for exclusive series like House of Cards, and many others, it’s an example of disintermediation, because they don’t depend on Hollywood studios and films distributors in order to get prime time content.

Going back to the industries mentioned in the introduction, an example in agribusiness might be an organic farmer selling their fruits and vegetables direct to people like you and me, instead to a contract farmer, who sells it to an agricultural corporation, that sells it to the groceries stores where you and I usually buy them. Although disintermediation in this example is far from being widespread, it challenges the core businesses of the contract farmers, the agricultural corporations, and the groceries stores, because they’re no longer needed for us to get fruits and vegetables at least; and it’s good for providers, because they can probably sell their products for a better price, and is good for us because we know the exact sourcing of what we’re eating and probably paying less that in the groceries stores for the same products.

Another example, this time in the banking industry, might be peer to peer lending, where people and enterprises who has money uses an online service to lend directly to borrowers. Lenders in peer to peer lending have less infrastructure and lower compliance costs than traditional banks, so they can lend money at lower interest rates than traditional banks, which is good for the ones who borrow money; but is also good for the lenders, because often they earn higher returns compared with similar products offered by traditional banks.

The agribusiness example is complete disintermediation -there’s nothing between the provider and the consumer- while the later is partial disintermediation -there’s an online service between providers and consumers-. More on that later.

Although disintermediation becomes more common in more industries, and in more products and services inside industries as times goes by, it doesn’t happen in every aspect of every business at the same time; but the trend is irreversible. Then while some industries and companies with vertically integrated business models -one-stop shops for the variety of touch points along the value chain- are being seriously disrupted by disintermediation and fight against it, others are instead embracing disintermediation already, leveraging what this article from Oliver Wyman calls business modularity. While the article covers the financial services industry, business modularity is applicable to many, if not all, industries. The next couple of definitions are taken from there.

In one hand, modular demand is when “product or service providers no longer own the direct customer relationship”. It’s business as usual for most producers in the agribusiness industry, but isn’t as common at all in the banking industry, yet. Another example of modular demand is the hotel industry: even before the emergence of travel reservation sites like Expedia.com, TripAdvisor.com, and others, you used to book your hotel stays through a travel agency, it was rare to directly call to a hotel to make a reservation.

On the other hand, modular supply occurs when “the supply chain is not delivered in-house, when parts of production are performed by different firms”. Once again, it’s business as usual for most producers in the agribusiness industry, but isn’t common in the banking industry. Restaurants are a good example in a different industry: they don’t produce the raw materials they use for the menu they offer, nor the species and other ingredients; they don’t make the dinning tables, nor the tableware, not table clothes, and so on.

Both modular demand and supply comes in degrees, modularity goes from low to high and everything in between. When demand and supply modularity is low, you have the vertical integration we mentioned before. The interesting combination for this post comes when both demand and supply are highly modular. Why? That’s where the concept of marketplace comes into place.

A marketplace, also known as business platform in Platform Revolution by Geoffrey G. Parker et all, or digital  business technology platform accordingly to Gartner, it’s an enabler for interactions between consumers or users in the demand side and product or service providers in the supply side.

The marketplace is used to exchange “value units”, i.e. the products or services offered by the providers and consumed by the consumers or users. The market place has at least one “intelligent” component that matches the needs and interests of the consumers with the products or services offered by providers, in a way that satisfies those needs or matches those interests. The key in these marketplaces is that all transactions happen through and thanks to the marketplace. There is one way to monetize the interactions in the marketplace, as a per-transaction fee or as a percentage on the value units being exchanged, charged to providers, consumers, or both, but isn’t the only one. Producers can be charged an entry fee or on an ongoing basis as long as they are part of the marketplace; and the same is true for consumers or users.

Imagine you’re about to buy, let say, a car. A cars’ marketplace can offer you brand new or second-hand cars from multiple dealers and car manufacturers. The market place knows you well enough to propose appealing loans or leasing options, either from banks or peer-to-peer lending companies, as well as insurance from different insurers. The insurance policy can be calculated based on you driving habits, mileage, etc. by using a device offered by a third party that is connected to the car bus to gather telemetry data that’s sent to the insurer, and eventually to the marketplace too, lowering down the policy price if you drive carefully and defensively or don’t use your car too much, or raising it up if you drive imprudently. The marketplace can also offer you car maintenance or car washing services; those can be regular services, or the service provider can pick your car up and drop it back few hours later, so you so you don’t need to move from your house or your office, because the marketplace knows you’re very busy. And what’s even more interesting, if the marketplace knows you well enough and it’s “smart” enough, it can recommend you to don’t by a car at all, and instead suggests you to use a shared car service, a carpooling service, or simply rent a car whenever you need it. This cars’ marketplace can be used by individuals like you and me, but also by fleet owners, etc.

Once the marketplace has enough data about transactions, it knows a lot about both providers and consumers, and can answer questions like who, when, what, how much, etc. Here’s where the second “intelligent” component of the marketplace comes into place, because this data isn’t only useful to the marketplace itself, but can be very valuable to third parties that are willing to pay for it. Addressing privacy and compliance issues and regulations, e.g. by segmenting and anonymizing data, a whole new business model appears.

The marketplace can be viewed from three different, but complementary, points of view:

• The business aspects, i.e. how to define and monetize the platform. Part of this blog post tries to address that particular aspect.
• The technology aspects, i.e. the cloud services, API strategy and architecture, mobile platform and development tools, IoT and big data, containers, and so on. More on the technology aspects on my previous blog post.
• The ecosystem aspects, i.e. how to run hackathons and discover and incubate startups to expand the services or products offered, how to engage with research and the academia, how to connect with government and non-government agencies, and so on.

Any serious attempt to build a new marketplace or participate in an existing one should consider all the aspects aforementioned at the same time, as well as the relationship of marketplaces with business modularity and disintermediation.

Digital Transformation Foundation: “Software Defined Everything” and “Everybody Codes”

There seems to be an agreement on digital transformation being less about technology and more about business design and a customer centric culture. Obviously it’s not about digital technology: DVDs, as its own name implies, are digital movie containers as opposed to analog videotapes or photochemical films, but wasn’t until Netflix added video on demand via the Internet to the DVDs physical delivery business, that they became a reference on digital transformation.

As George Westerman et al. put clearly in this book -or in this article summary-, it’s the transformational management intensity, i.e. how much top managers are betting on digital transformation, what separates digiratis -digital literates- from the crowds. Nevertheless, companies still need to think on the foundation for their digital transformation, and precisely there is where digital platforms come into place; of the other way around, a digital platform won’t make your company to digitally transform, but can’t transform without one.

What’s that platform? It’s whatever makes frictionless to combine incumbents and partners into your business and for you to participate in others businesses “to execute [your organization’s] digital business strategy”, accordingly to Gartner.

A while ago hardware machines were a physical thing; now we have hardware virtualization by software and then we have virtual machines. Also a while ago we had physical arrays of spinning hard disk drives, and now we have software defined storage; we had physically connected cables, routers, switches, firewalls, etc. and now we have software defined networks; and the list goes on up to big things like software defined datacenters or down to small things like software defined chips, or more precisely field-programmable gate arrays.

Even the IoT devices very common in many digitally transforming businesses can change their behaviors based on the software they run; the dumbest the device, the longer their battery life, less their capability of running sophisticated software or even to run software at all; but put for example a field gateway behind it, connect it to the cloud, and then you have your software defined IoT too.

These platforms have another interesting characteristic: in order to achieve the agility and easiness of adaptation, they embrace change and make changing easier. The [business] rules that control the behavior of the applications running on these platforms can be changed in a declarative way -as opposed to imperative or algorithmic-, eventually through a graphical use interface managed by some business user, not a programmer. It’s declarative, but it’s still giving orders to a computer to do thing, so it’s still programming or coding.

The end user who does acceptance testing doesn’t necessarily use the application itself anymore to see if it works as expected. They won’t do that fast enough and won’t do it as much times as it takes to deliver changes on a daily basis -or even more frequently-. Then the only way is to ask them to declaratively specify how to do the tests instead of doing the testing by themselves. Once again, it’s declarative, but it’s still coding.

So we have end users coding, either by adapting applications running on platforms to do new or different things or by make sure the applications work as they want, we have also more people coding: operators.

Operators now do write scripts to do repetitive tasks. It’s faster, and most importantly, it’s less error pone: once scripts works, they don’t forget steps or make mistakes as human operators sometimes do if they’re tired or in a hurry, stressed by a deadline.

And programmers have always coded; so now everybody codes.

So that’s my personal viewpoint on what a platform implies for digital transformation: “software defined everything” and “everybody codes”. And again, this won’t make your organization to digitally transform, but it’s very unlikely that you can transform without one. I’m fortunate enough to have a computer science and software development background; it’s easier for me to understand and to explain to my customers as Microsoft Digital Advisor this foundation for digital transformation.

Learning Digital Business Transformation through example… from my kids

Yesterday I had a deep conversation with my eldest son about League of Legends. I must admit I am not fully comfortable with him spending countless hours playing this online game. What I did not understood until yesterday was the profound undergoing digital transformation that the entertainment industry is experiencing as we speak.

If you think League of Legends is just an online game and its creator Riot Games are just a game publishing company, you are as wrong as I was. Let me try to explain what wonder me most by doing an analogy with football (i.e. soccer for those few reading in the U.S.)

More than hundred years ago, all around the world there were the football players playing football matches in the football field, and there were also the supporters in the stadium’s bleachers attending the matches. Local leagues of football teams organized local championships, regional federations organized regional cups and, then less than hundred years ago, the worldwide federation, also known as FIFA, organized the worldwide cup in my home town. Bribery and scandals aside, football is a multibillion dollars business, isn’t it?

About seven years ago, Riot Games developed and published League of Legends, a multiplayer online battle arena, real-time strategy video game, very popular among teenagers from 12 to 19 years old. There were teams of five online gamers teams playing games against other teams eventually in opposites sides of the world in real time. These gamers are actually gamethletes, a skill-based ranked community of people all around the world, who love to play this online game. There are local championships, regional championships, and there is the worldwide championship. The topmost ranked gametheletes are actually professional players who get paid for playing. Amazing, uh? Well, not really. The Messis, the Suarezes, and the Neymars of the football are paid, and very well I must say, for playing the sport they love to play, aren’t them?

Who pays the League of Legend’s gametheltes? Riot Games does for most of them and teams participating in the Worldwide Championship are even sponsored by brands like Samsung or SK Telecom. How Riot Games makes money to pay them? Well, you can get almost everything, and go almost everywhere in the game without a penny, but money can make things go faster. Just by playing games you earn points, and then you use those points for stuff like costumes for creatures in the game. But you can also buy points. And before you ask, yes, my credit card number is somewhere inside Riot Games’ datacenters; somewhere deep inside, hopefully.

But here’s where things become even more interesting. The 2014 League of Legends Worldwide Championship final was played at the Sangam Stadium, also known as the Seoul World Cup Stadium, built for the FIFA’s World Cup in Korea in 2002. About 40 thousand people attended the 2014 League of Legends finals live and companies paid for advertising spaces on the stadium, yet another 27 million watched them live online via streaming served by 40 broadcasters who also paid for the content. I don’t know how much they paid, but winning teams raised about 2.13 million dollars in prizes, so there should be good business case, shouldn’t?

The game’s user interface layout used for broadcasting is similar but different to the game layout used to play against other teams: it needs to show the full battlefield, not just the portion your team controls, and needs to show both teams’ actions. But it also allows space for advertising, so that’s how the broadcasters makes money.

My analogy with football isn’t about the sport, it’s about the entertainment industry. And there’s this multi-million dollars business of online multiplayer gaming, of which League of Legends is just one of them, mainly for teenagers who don’t have money, run by relatively few people, that enables a huge ecosystem for others to make money too, including those content generator teenagers who record their games and publish them online on YouTube or broadcast them on Twitch and get paid for it because other teenager consumers do watch them.

Putting it simply, that’s pretty similar to the business model behind the entertainment industry, isn’t it? And it’s fully digital. And it took just seven years to get there.

Every company is a software company, and every software company might to be a service provider

Software is pervasive. Except perhaps for the one-man (or women) burrito-like shops in the streets, every business runs on software. And they are an exception if and only if they do not accept credit card payments or use online grocery delivery services to refill their raw materials stock. Every company is a software company at the end of the day, either a software-consumer only or a software-development-and-consumer combo.

For those enterprises that do in-house software development and then use that software to run their business, even if it is just a portion of the total software being used, the traditional software development lifecycle might not be appropriate in some circumstances, as we will see in a minute.

An for those enterprises who’s business is to develop software for other enterprises or individuals to consume, the traditional software development lifecycle might not be appropriate either.

By traditional software development lifecycle I do mean the process that creates a software product at the end. I do not care if it is waterfall or is agile, the only thing that matters me is that a software product is created as a result of that process. It has the following characteristics:

• Many features. Differentiation of the product is based on having as many features as possible for as wide an audience as possible. Products are rarely targeted to specific roles or customer needs.
• Mean time to failure. As with traditional manufactured products, its main focus is mean-time-to-failure: products are better if they have few failures.
• Slow update peace. Software product updates are relatively uncommon; it may be through patches for fixing bugs, through service packs to add new functionality, or through entire new versions. And development time for software products is usually large, followed by a maintenance warranty, and then a rest period before starting over.
• Unknown consumption habits. Once products are released, is hard to know how they’re consumed by users, and take decisions based on usage patterns.
• On time, on budget. Most important priority is to release products on time and on budget.

In addition, as with traditional manufactured products, reliability is perceived from the perspective of each individual unit. Providing reliability requires controlling quality within the production process. When users experience product problems, they are usually willing to wait until office hours for their problem to be addressed. A problem rarely impacts more than one person at a time. And usually it’s clear for users when problems are due to issues in the software product, as opposed to issues in the environment in which the software runs.

But any of these businesses might be affected by today’s transformation on software demands:

• Your company develops an mobile software application, it can be a line-of-business application in the enterprises world, or it can be another specific-purpose software application in the marketplace for the consumers world. In the second case, most of these applications at least do store some data or do some kind of processing in a remote back-end, which puts them in the same group as those in the first case: mobile applications that consumes remote services.
• Your company does electronic business with other companies, it can be exposing internal processes through software where others can participate, or use software applications to exchange information in order to complete a transaction. One way or another you are either providing software based services, or consuming them; probably both.

Did you notice the word software at the beginning of the two previous sentences and the word service at the end? It is not casual –I wrote it that way- but that is what we are and will be seeing in the foreseeable future: mobile software applications that consumes some kind of remote service and software based services exposed for others to consume.

If you feel that any of the two before mentioned categories do apply to your company, either if you are creating software for your own business consumption or in the business of developing software for others to use, and you are still developing software as products, guest what? You are not developing software, you are providing services. I do call these software-based service providers. And that is a completely different beast, want to know why? Let us see:

• Reliability and agility over features. Differentiation of the service is based on highly reliable capabilities that fit a specific set of market needs. Effective services emphasizes reliability and agility over features.
• Mean time to resolution. As with traditional utility services, its focus is mean-time-to-recovery: failures will happen, so services are better because of its fast recovery.
• Continuous updates, continuous development. Software updates are continuous; they might release new features or entire new versions very frequently, and fix bugs on a daily basis. Software development for services is usually continuous; they might have release cycles, but usually those cycles are very short.
• Detailed usage patterns. Usually it’s possible to collect very accurate and huge amounts of usage data, driving more meaningful decisions.
• Up and running at appropriate costs. Most important priority is to have the service up and running, keeping the appropriate operating cost.

Furthermore, as with traditional utility services, reliability is a function of the entire system. Providing reliability requires real time, proactive monitoring of the behavior of every system component. When users suffer service outages, the impact is much wider, with one problem impacting a wide array of customers. Response cannot wait for office hours. Product support has to be ready 24x7x365. Users don’t care where the issues are when service outages occur. They might be in the software the service is based on, or in the datacenter, or in the network, or in any of the dependent components

You cannot keep pace with change requests and do not have enough agility to accompany businesses transformations? You have conflicting requirements from different business units or different users groups? You cannot find a good way to organize your software development and software operations teams? Guess what, your software factory is probably not organized as a service provider needs to be organized.

Software factories are organized around software products while service providers are organized around services. And you still wonder why it did not work?

Organizing teams around products means two things. One: you have a team by product, some members can be shared among teams, but teams do work for a product. And two: you very probably have segregation of tasks inside teams: business analyst, architects, designers, developers, testers, and operators if you do run your own software. Does one product use others? Of course, except if you have monolithic giant piece of software, in which case you are way worst that the rest of us, and have more urgent and important problems to solve. Each of the roles of a product team I mentioned before, does work for their own product. They really do not care about products using theirs products and certainly they do not control the other products they consume. And the transition from development to operations looks like developers throwing something over a fence to operators to catch… who cares what happens in the other side? There is always a revenge, operators can always fill bug fix request to developers.

Organizing teams around services, means that a service team has everything it needs to deliver the service and fulfill the service level agreement. There is no fence. Service owner, business analysts, developers, testers and operators sits together upfront to define how the service itself, and the service development process, will look like, end-to-end. Radical, isn’t it? Yes, but that is what you need: An operator telling a software developer what kind of automated deployment, monitoring and telemetry capacities he will need in order to operate the service. These are non-functional requirements and architects and software developers are used to deal with them. A tester telling a software development the way he or she should design the software for him or her to being able to effective and efficiently testing it. These are non-functional requirements too. A software architect or developer telling the service owner what can or cannot be built given time and budget restrictions. Sounds crazy, but these examples are just business requirements, the service owner should be used to deal with them during service definition.

If you think that services are just on the outer layer in contact with the outside world, you are plain wrong. The very same concept can be used in inner layers, in what I love to call the service-oriented enterprise architecture. It is not the same as the plain old service oriented architecture, where application services was the cornerstone. I am talking about business services, application services, and infrastructure services, all organized in the same way, relying one on each other via well defined operation level agreements from the service consumer side, and service level agreements as part of clear service definition from the service provider side.

Biggest software companies (well, it depends on your definition of big) are in fact software-based service providers (Microsoft, Google, Amazon, Facebook, Twitter, Whatsup, Apple, and so on). Your company might not be as big as those, but if it is a software-based service provider, you might have more things in common with them that you think. Someway or another all of them do organize behind the services they do provide. Why you do not?

.NET UY Conf, October 3rd & 4th