One of the world’s largest online API events – APIX – was organised and hosted by connectivity and integration expert, Sensedia. Run over three days, APIX attracted some of the world’s leading tech specialists and strategists, all keen to share their perspectives.
Here, Randy Heffner, a Dallas-based software industry analyst who worked at Forrester for over 20 years, explains why opening and sharing APIs is not enough to turn an organisation into a market leader; only a change in mindset can do this.
Software has long-since moved beyond administrative number-crunching to become the muscle and connective tissue of the 21st century and central to competitiveness, adaptability and even survival. Yet many executives will miss the critical implications of this change. Even if regulators force them into software-based open business, their traditional notions about software prevent them seeing what true business leaders see: that the right software strategy can propel them beyond open business, enable an open-ended business mindset and open-ended business opportunities, and build resilience and agility for an ever-changing world.
What does it mean for an enterprise to be open? Driven by the global drive for open banking, it has roughly come to mean that the enterprise has APIs for digital communication between other firms. But this type of openness may be only skin deep, implemented by hardwiring a couple of API adapters onto closed enterprise applications. Thus, many businesses that consider themselves open may not be at all. To become truly open, an enterprise must have a much deeper shift in software strategy that intrinsically links business design with software design. More on that below.
It hasn’t always been this way. Traditionally, from the early days of software, businesses could succeed with a more closed approach; leaders discuss the concept for the business, they outline how they want processes to operate, and then deliver a set of requirements to the software team, who would embed or freeze them into the software. Business design was a separate, standalone task and software design followed, becoming a secondary translation into a different design realm based on technical abstractions. And it worked – software was not so central and critical to every aspect of the business.
But in this world of digital disruption and transformation, and even before the pandemic, the intertwining of business and software had become so thoroughly pervasive, that modern businesses can’t run without software. Suddenly businesses could only change at the same speed as their software. And this means rather than simply aim for better ways to build software, businesses must change the core structures of their software design. Business and software design are not and should never be two separate processes; they are two sides of the same process, resulting in a single digital business design.
Leaders that want their enterprises to have truly open-ended possibilities must change their mindset and view the business and software design process as one.
So what’s the profile of a closed business? Aside from a strong network firewall, the business itself seems to have a firewall, preventing anyone getting in, with applications performing required functions with maybe some light connections to separate ecosystems, facilitate EDI or transfer files etc. The fundamental design of the software is closed which means the business is closed.
The business thinking is also closed. Leaders will ask ‘what type of business are we?’ Having answered a retailer, insurer or wholesaler etc, they’ll identify the capabilities needed to run that business and hardwire them into the software.
But that’s the past – we’re in an open world now. Or are we?
Those who want to be open can just slap a few APIs on their closed systems. But if the business thinking doesn’t change, these APIs will be no more than small extensions to the current closed business profile. Perhaps the APIs allow exposure to the outside world and connections to ecosystems around the enterprise, but nothing has changed within the organisation. There are still internal cultural barriers around business creativity, and the technological barriers remain because no one can imagine what a different software strategy might allow. Only when the mindset and business itself changes can it move from this limited mode of being open to the more expansive possibilities of open-ended business.
The open-ended business vision
By interfusing business and software design, open-ended businesses create unlimited possibilities in how they can respond to changes in their competitive environment and the world around them. Central to digital business design are business APIs – a special type of API carefully designed to mirror how the enterprise conducts business through transactions and data exchanges. The firm may still have hardwired apps (which remain part of legacy systems), but they have buried them deep behind business APIs, and other software design constructs, that embody the business design and provide a fulcrum for their digital transformation lever.
The business firewall is thinner – executives realise the need for open digital flows of transactions and data in and out of the enterprise – and the network firewall is now one of many layers of security, enhanced by APIs. Within product and servicing capabilities, for example, business APIs will facilitate move money management tools (the business+software digital business design centres upon what capabilities are needed to facilitate a move money request).
Over time, the mindset change and software strategy change dramatically increase business modularity and agility, and digital business capabilities ( based on business+software designs) become business building blocks.
Once a business is modularised, using open-ended business APIs, leaders can let their creativity run wild. Rather than being locked, for example, in a view of being a retail bank, they can consider what else they might do with the capabilities their businesses now have, reconnecting and redeploying them in different combinations to add a completely new business for the future.
The bank could create entirely separate businesses, like a specialty payments provider or loan servicer, digitally partnering with independent businesses in different ecosystems. It could sanitise its flow of payments data and extract interesting market insights, giving potential for another business stream.
An open-ended bank views its business APIs as entry points into distinct business domains – each a major area of business capability – that it can reconfigure and combine with partners’ capabilities to develop need-specific business models, linking to varying ecosystems. Designing a business for rich ecosystem interconnections, whether as the centre of a broad, rapidly changing ecosystem, or merely delivering individual capabilities to others’ ecosystems, the bank builds resilience to unpredictable disruption, such as Amazon becoming a bank or another pandemic.
And the bank would have even more opportunities for innovation and partnerships, with Fintechs for example, and it’s easier to create new capabilities, offer more products, ‘white label’ services to other providers and become a banking platform. It’s a world of open-ended possibilities.
Creating an open-ended business does not happen by accident. Internal teams have to be disciplined and co-ordinated, similar to Formula One racing teams. Here, when a car takes a pit stop, the new tyres are on in a couple of seconds, and this is because the team is highly organised, governed and automated.
Running an open-ended business is similar to the F1 pit stop and APIs are a central element, fundamental to enabling an ongoing stream of business change. And as APIs expose businesses to new opportunities, governance is critical, particularly when it comes to API classification.
But not every API is of the same value and business impact. Rather than view APIs as a ‘one design fits all’ tool, it’s important to recognise the critical role of business APIs and the way they mirror the design of the business. API taxonomy and portfolios help here as they identify whether the API’s a business, utility or user experience enabler, for example, and how it fits within a given business domain’s portfolio of APIs, such as domains like treasury, cash or order management, or inventory.
Every type of API in the taxonomy requires a different type of design principle and governance. Yes there’s a shared core of API design principles, but each type has its own different focus and place within the architectural layering. By identifying the role of the API being built, developers will know how much and what type of governance needs to surround it. User experience APIs, for example, typically require less governance around their interface designs, while security and identity models around APIs may require more.
API patterns and templates provide great guidance, following best practice at implementation and design level, and automated delivery embeds governance.
So what are the milestones on the open-ended journey?
Domain orientation – Business capability domains are central to a modular, composable business so merge business/software design and build a modular business around capabilities. Key questions are – how does the business and architecture fit together?, where does the business want to go and are these requirements overshadowed by software technical aspects? Intentionality is important here.
Business architecture/ecosystem thinking – The business architecture team is integral to the business and software design process, as is a mindset to embrace multiple ecosystems. But this team and mindset does not sit in an ivory tower. Architecture and governance must have a new mindset, too. Not top-down command and control guard stations, but rather bottom-up collaborative decision-making design processes.
Multi-disciplinary teams – Designing a business around value delivery streams, not just within an organisation, but across entire ecosystems, requires multi-disciplinary teams that can merge business and technology across the physical and digital world.
Software – The API is a critical technical tool, but it’s important to ensure that all business interactions: an event, process, business stream, file transfer etc, can operate across ecosystems.
Business leaders that change their mindset — using open-ended thinking and software strategy to build future agility for the long-haul — broaden their horizons and demonstrate great governance, collaboration and discipline, will undoubtedly pass these milestones and successfully transition into open-ended market leaders.
Sensedia is a leading integration solutions provider with 150+ enterprise clients across a range of sectors. Its world-class portfolio includes an API Management Platform, Adaptive Governance, Events Hub, Service Mesh, Cloud Connectors and Strategic Professional Services’ teams.
Sensedia is winner of Wealth & Finance International’s ‘Best Open Banking Solutions Provider 2021. www.sensedia.com
About the Author
Randy has been in the software industry for 40 years – 20 of which as the main API analyst at Forrester Research. He is a specialist in integration strategy, solution architecture, and how APIs drive innovation and digital business.