Making the enterprise composable
We speak to industry experts about how to develop composable IT that can quickly adapt to business change
It was about a decade ago that Red Hat CEO Jim Whitehurst (now president at IBM) used the term “composability” as a hook for his keynote. “I want to talk to you about the era of composable technology and how you [as developers] are all going to help build it,” said Whitehurst.
From an applications perspective, developing software in a way that is composable, using software components, is far more flexible and easier than building applications as vertically integrated monolithic applications.
“If you’re able to write code in small sections that can be tested and deployed independently, make it simpler to integrate new components of the application and deliver these updates much more quickly, that can be a significant competitive advantage,” says Antony Bourne, senior vice-president for industries at IFS.
In practice, this means it is much easier to leverage and apply tools such as robotic process automation, artificial intelligence or the plethora of hyperautomation capabilities available today, aimed at simplifying workflows and optimising business processes.
Ariel Assaraf, CEO at stateful streaming analytics platform Coralogix, believes composable thinking is the first building block of a composable business. “Our way of thinking influences everything we do – it guides us in deciding not only what to compose, but also when and how,” he says. “Building on a mindset of composability, we can begin to implement it across the organisation or, more specifically, in the business architecture and tech stacks.
“How can we modularise the company and the product in such a way that every part can function more or less independently from the others?”
Abstraction has a key role. In Assaraf’s vision of a composable business, each modular component, from the organisation’s technology stack to the business architecture, is given a certain level of abstraction to allow for more agility.
But he adds: “There’s a point of diminishing returns on abstraction. If we take it too far and break everything down to the ‘atomic’ level, everything slows down because it’s being done from the ground up.”
For Assaraf, each part requires full autonomy, but getting the parts to work together is the bigger challenge. “We need to strike a balance between autonomy and abstraction,” he says.
Reusing off-the-shelf code
Rod Cope, CTO of Perforce, believes that instead of working at the widget level, software developers are talking about reusable databases, clouds and virtual machines. Also, open source – the adoption of which is growing quickly in organisations of all kinds – is in itself a form of composable development.
In an ideal world, nothing has to be built from scratch. But for the time being, the demand to develop faster and at scale means that pulling together ephemeral components to deliver projects quickly is forcing the pace of change.
As Cope points out, some security-hardened, vetted infrastructure components, such as Ansible, Chef and Puppet, can help software development teams to speed up application development simply by grabbing an off-the-shelf component and customising it for their particular needs, using an automated infrastructure-as-a-code approach.
The net result, he says, is that developers get to compose well-tested pieces into an existing DevOps workflow, providing better agility and quality, at speed and at scale. “The good news for developers is that they spend less time creating basic building blocks, can deliver more code more quickly, hopefully freeing up some time to spend on more out-of-the-box innovative thinking, or at the very least, adding to an app whatever their unique contribution might be,” he says.
APIs for composability
In the world of the composable business, product teams must be able to deliver custom-built software quickly to respond to new market opportunities that emerge, says Guy Sayar, CTO for the EMEA region at HashiCorp. “Applications and infrastructure will invariably evolve in unpredictable ways,” he says. “This fluidity can only be obtained in a system defined by an API [application programming interface].”
Sayar recommends that APIs should be used not only to deliver the software infrastructure driving digital innovation, but they should also be used within the build and maintenance processes for this infrastructure. This is an API-centric model, which is being driven forward by a growing maturity among decision-makers and users of cloud.
“IT and business teams are increasingly willing to make trusted third parties part of their new and expanded infrastructures – to run their apps atop innovative runtimes and plumb in valuable services through those APIs,” he says.
While APIs help internal teams and external partners to connect to back-end applications, Kelly Goetsch, chief product officer at Commercetools, says that from an end-user’s perspective, people may have dramatically different needs in terms of the data they require, processing power and internet connectivity.
For instance, look at the number of API calls required to build a user’s Facebook timeline, says Goetsch. “Now, imagine performing all of those queries from an old Apple Watch over a poor internet connection.”
Facebook built a specification for how to query for data called GraphQL. The GraphQL Foundation, the home of GraphQL, defines GraphQL as “a query language for your APIs”.
Facebook has been using it internally since 2012 and publicly released the specification in 2015. Since then, it has quickly caught on and is now used by Twitter, Microsoft, Amazon, Google and the New York Times, among many others.
Goetsch says: “With GraphQL, you just make a single query, specifying exactly what data you want to retrieve. The GraphQL layer then makes requests to the individual APIs (from the server side) to fulfil the request. As a developer, you get a single response containing everything you need to render your new product detail page. Think of GraphQL like SQL, where you can retrieve data from multiple database tables using one query.”
According to Goetsch, GraphQL solves over-fetching, under-fetching, discoverability, authorisation/authentication and more. He says it is built explicitly for client-side developers to retrieve data from APIs easily and has emerged as the standard and the “glue” for composability.
API sprawl
HashiCorp’s Sayar says composable infrastructure requires an API culture that is independent. But he warns: “There is a fine line between independent and chaotic. In large DevOps practices, teams build and run thousands of APIs. The default outcome will be ‘API sprawl’. Technical debt will hinder long-term success.”
In his experience, another challenge is the diversity of development frameworks used in an organisation, such as Java, .Net, Node and Python. “The challenge here is to translate composability across all these disparate technologies,” says Sayer.
Simplifying API sprawl and managing multiple frameworks is possible using a platform offering common architecture patterns, a service catalogue of add-on capabilities and a series of technology contracts between development and operations teams, he adds.
The bigger picture
While there are clear benefits for software developers to have libraries of pre-built software components that can be pulled in to create new functionality with very little effort, composability has ramifications throughout business.
In a recent article, Ram Chandel, digital commerce market offering lead principal at Deloitte Consulting, and Paul do Forno, digital commerce eminence lead, managing director at Deloitte Consulting, discussed trends in digital commerce. In the article, the pair looked at why a modular, composable e-commerce platform enables businesses to stretch their investment by buying or replacing only the features or functions that they need to create exactly the experience their brand wants to deliver.
“This gives you access to ‘best-in-breed’ capabilities from an array of technology vendors, rather than looking to a single vendor for everything,” they wrote. “An industrial equipment manufacturer may need sophisticated search and recommendation tools to highlight technical details or specifications. A home goods company, on the other hand, needs ways to show sofas or tables in cool ways, including in 3D.”
The key thing is that these “customised” features are plug-and-play, helping the company to achieve its business objectives.
In the context of the wider business landscape, market shifts are ephemeral and, as the last few decades have shown, new offerings that successfully exploit a market niche can quickly supplant long-established business processes.
Although not every business is likely to become a software business, the more competitive enterprises are bound to use software strategically in a way that makes them agile and allows them to address new market opportunities quickly. An overall enterprise IT architecture built on a foundation of composability will be essential to the successful delivery of a software-powered business development strategy.
