peshkova - Fotolia
Engineer, entrepreneur and inventor Bob Metcalfe once described how the value of a network grew as the number of Ethernet cards increased. The concept also works for applications.
By submitting your personal information, you agree that TechTarget and its partners may contact you regarding relevant content, products and special offers.
While the cost of a network grows linearly based on the number of connections, the network effect, hypothesised by Ethernet inventor Metcalfe, describes how its value is proportional to the square of the number of users.
The network effect has now arrived in the application development space with the emergence of the application network, at least according to application programming interface (API) management specialist MuleSoft.
At the company’s London Summit earlier in May 2016, Ross Mason, CEO at MuleSoft, warned delegates that their organisations need to get used to change.
“The world is changing and getting good at adapting to change, and ingesting new tech, is essential,” he said. However, if change is the new normal, the way IT has evolved to support new technological breakthroughs in the areas of social, mobile, cloud and big data is too slow.
Mason warned that all industry sectors face serious disruption. “You have to change quickly because you don’t know where the competition will be,” he said.
And according to Mason, making IT more efficient is not necessarily the answer: “You can go 30% faster, but how do you drive a much faster clock speed in IT?”
His answer is that CIOs needs to think differently and this is why IT should apply Metcalfe’s network effect to applications. “We almost always extend IT architectures too far. They break,” said Mason.
Creating building blocks
Previously, the recommended best practices in IT were that organisations invest in developing an all-encompassing platform, such as a service-oriented architecture (SOA).
Instead, Mason said: “Look at API-led connectivity.” Rather than build a large-scale reusable services infrastructure, Mason urged delegates to consider developing connections to applications as and when they are needed. These connections create building blocks.
These building blocks form the basis of the application network, and can be made available to other parts of the business, which can use them to build their own applications.
If new connections to application functionality are needed, new APIs can be created as and when the request is made. The APIs are then developed with re-use in mind and become part of the application network, where they can be redeployed over and over again.
APIs for fast food
An example of where such a network could immediately add value is at fast food chain McDonalds.
MuleSoft customer, McDonalds, operates a franchise model. Given the nature of the fast food industry, it can be hard for the company to understand its customers, or its customers’ needs.
One example of a successful franchise business that does appear to understand its customers is Uber, which recently extended its services to a parallel business opportunity in a way that meets customers’ needs in certain geographies.
Mason said: “Uber shows us how a digital franchise can work and in New York it lets customers order food.”
Read more about application networks
- To avoid internal conflict and drive revenue gains, organisations need to properly manage, secure and authenticate their APIs.
- Technology has always been a differentiator for Addison Lee and API management is the next stage in its roadmap.
This ability to enable Uber drivers to offer takeaway deliveries on top of the core taxi booking service is something that McDonalds wants to adapt within its business.
Just as New York Uber drivers, who are effectively franchisees, offer takeaways, Mason said McDonalds is beginning to look at how its franchisees can develop additional value on top of core technology building blocks provided by the company.
Adaptive business integration
Another MuleSoft customer, Unilever, has taken the principles of an application network to transform IT from being a service provider to becoming a business enabler.
At the beginning of 2014, the consumer packaged goods company realised its technology platform could not achieve the speed and agility demanded by the business. Nor could it support business requirements for integrating a growing number of cloud services and mobile apps.
Despite its IT being assessed by analyst Gartner as world class, Unilever realised it needed to put in place an adaptive business integration capability to support the pace at which the company was driving digital business initiatives.
“The only way was to make a step change and decentralise ownership of certain IT components and give business entities a level of autonomy,” said Frank Brandes, director of global enterprise business at Unilever.
Brandes said the team was able to show the business how quickly adaptive integration could be delivered. “We set up an adaptive integration capability with an in-house DevOps team which could start developing applications from day one.”
The adaptive integration team reports to the head of enterprise business integration. Working with Unilever’s enterprise architecture department, the team used MuleSoft Anypoint integration platform as a service (iPaaS) to provide the cloud-service integration and API management required for its self-service API connectivity strategy.
A strategy for re-use
Large-scale IT architectures hark back to an era of command and control IT. A centralised IT function can no longer work effectively by providing an overarching middleware architecture for developers in the business to use.
Such architectures take far too long to build, and fail to keep up with the pace of change needed to support digital business initiatives.
What is interesting about Unilever is that IT did not have to open up every conceivable API the business might need. As Unilever’s Brandes found, self-service drives API development and for “every requirement we check if there is an API, and if there isn’t one we look at whether we should create one”.
This creates re-deployable API access, according to Brandes.
McDonalds is also looking to move beyond a centralised IT infrastructure. Giving franchises the ability to create value on top of a core set of APIs promises to make the business more adaptable.
Both McDonalds and Unilever are applying the principles of the network effect to make APIs more valuable to the business. In the so-called application network, the more APIs that exist, the greater potential value the business can derive. Surely, this is Metcalfe’s network effect in practice.