Over the last few years, one theme has been universal regardless of industry, company size, or geography: every organization is trying to accelerate innovation while maintaining safety and stability.
How will enterprises balance the need for accelerated innovation at the edge while simultaneously addressing the need for increased governance over the work of distributed teams with different chains of command?
With mass democratization technology becoming mainstream and stream-aligned delivery teams (i.e. fusion teams) becoming the norm, this question has now become a top-of-mind concern for CIOs and CTOs around the world.
One area that’s compounding these concerns is the rise of automation technologies. Automation technologies are a great example of democratized tech that business teams are excited about. IT teams are skeptical based on the limitations of previous generations of low-code technology combined with cautionary tales of shadow IT efforts leaving IT teams responsible for maintaining solutions they had no hand in designing. As citizen developers from across the enterprise are now empowered to build low/no-code algorithms, will IT once again be left holding the bag?
Enterprise IT leaders are vexed with the set of unenviable choices in front of them; Are we comfortable with the risk of running full-speed into distributed development and releasing low/no-code automation to the masses for accelerated innovation purposes? Would we be better off focusing on governance and control to make sure that we don’t “run with scissors” and stab ourselves with componentry that could violate data governance rules or potentially cause an outage?
Before you send your architects and strategists into a detailed cost–benefit analysis to choose between the two paths of speed or governance, perhaps a new way has emerged that can let enterprises have their cake (unleashed innovation) and eat it, too (with reasonable governance controls).
IT process automation is business automation
Like many things in the lives of people and teams, it’s not what you do, it’s how you do it. In the case of democratizing automation technologies throughout an organization, the secret to unleashing innovation without sacrificing safety and quality lies in leveraging a platform strategy that includes governance by design capabilities out of the box.
A generic issue with enabling governance within enterprises is the amount of labor and coordination required to do it effectively. Anyone who has worked through the governance processes centered around board meetings can tell you there has to be a better way.
The good news here is that not only is there a better way, but that better way is a fully paved path courtesy of the DevOps movement. For the uninitiated, DevOps is a conceptual methodology similar to Agile. The biggest difference here is that where Agile is intended to accelerate decision-making and speed to market by bringing business and IT teams together in new ways-of-working, DevOps aims for a lot of the same outcomes by bringing together development and operations teams.
A truth laid bare by the DevOps movement is that “IT problems ARE business problems”. This linear and provable connection between IT performance and business performance was perhaps best laid out by the book Accelerate where the authors collect and comb through troves of performance data from global organizations to identify and prove the correlative and causal relationships between DevOps practices and business performance.
While many DevOps veterans recognize that SDLC automation extends way beyond CICD, not everyone realizes that to truly optimize for fast flow, end-to-end process automation within IT must be a fundamental part of transformation initiatives. This includes quality, performance, security, and governance activities. When stream-aligned/fusion teams align to sufficiently automate the process of value production, a new conceptual model for the enterprise emerges: the business-as-a-platform.
The term “platform” in business and technical conversations has grown significantly in the last decade and like many jargon terms, the meaning and application of the term has grown a bit confusing. In the business-as-a-platform context, we’re speaking to the state that arises when two internal practices are operationalized and scaled:
- Mass automation of processes and algorithms that companies use to run their business (e.g., onboarding, programmatic marketing, order fulfillment, financial operations, governance, and security, etc)
- The creation of internal technology platforms that allow for decoupled activities and operations between centralized teams that supply value (IT) and distributed teams that consume that value (marketing, product, finance)
The business-as-a-platform concept is separate and distinct from a platform business where enterprises create and connect networks of external third-party suppliers and consumers.
Before enterprises send their IT teams into massive automation and platform initiatives seeking optimized delivery of new capabilities, it is important to step back and understand how platform strategies work in the context of software delivery.
Platforms as the foundation for automated governance
A fundamental challenge for IT leaders in scaled enterprises is how to put appropriate and effective guardrails for a polyglot enterprise. The times when a CIO or CTO can mandate a single tech stack or development methodology are gone and enterprises must not only accept that teams will be building software with a variety of tools, they must go further and embrace it with a technology strategy that encourages teams to use contextually appropriate tool sets for the jobs they have at hand.
This context is where shared platforms come into play. A key distinction here is that “shared platforms don’t necessarily mean that all teams must use one technology stack”. In order for enterprises to solve the conundrum of innovation vs governance, the platforms that they leverage must account for the concept of universality. While the term “universality” may be unfamiliar to you, it’s worth noting that you’re experiencing its benefits right now given that you’re using a web browser to read this article.
Tim Berners Lee (inventor of the WWW) specifically leveraged the concept of universality to make the web the most robust and impactful tool of our age. Universality is the most critical concept that’s allowed for the global adoption of not only web browsers but also almost any technology that uses the web, including mobile devices and cloud computing in general.
Universality as an organizing principle can act like rocket fuel to enhance the value of platforms as universality allows a platform to meet enterprise creators where they’re at while also allowing for “by design” capabilities to be leveraged across the full spectrum of applications and capabilities that the platform provides access to.
To achieve this effect, universality must be applied in multiple dimensions:
- Protocol independence: Supporting a wide range of communication paradigms, rather than a singular protocol, is a fundamental tenet of universality. In an integration and automation context, RESTful APIs are one of many protocols that a platform can apply governance rulesets to. From AsyncAPI to GraphQL, a platform that allows developers to utilize the protocol that makes the most sense for their use case will set the stage for a robust repository of reusable componentry that developers and solution architects can trust because table-stakes governance rules have been applied by design.
- Tech stack independence: Universality requires a bias towards openness and not just at the communications layer. In order to enable enterprises to apply governance across the full canvas of APIs within an enterprise’s infrastructure regardless of whether these components were built on the shared platform or not, the platform must be able to support the components built with the developer’s tech stack of choice, thus the applicability of the term UAPIM (Universal API Management).
- Component type independence: For a solution to be considered “universal” in nature, it must not only be open in its approach to technology, it must also be accessible to different audiences. For an integration and automation platform to take universality and democratization to the next level, contributing to the platform can’t be restricted to IT teams only. Distributed teams must be able to leverage the platform to connect and operate diverse componentry with little to no friction. This is the essence of composability.
In this model, the power of the platform is not only visible when new APIs are added to the platform, but that very same power is also visible when:
- New protocols for specific integration needs are necessary to enable complex use cases.
- New technologies are added to the mix through mergers and acquisitions or innovative employees utilizing the dev tools they’re most comfortable with.
- Distributed teams are using no/low-code technology to automate the administrivia out of repetitive business processes.
Automation, platforms, and universality have paved the way for unifying speed and safety
Before approaches and technologies for automation and platforms had matured, organizations around the world had to choose between speed and safety, flexibility and usability, innovation and governance. It is only in the last decade that these dichotomies have begun to erode, allowing enterprises to achieve multiple goals that were once considered mutually exclusive.
The most recent advance in the evolution of platforms is in how they can embrace universality as a core principle. The unification of design-for-reuse and fit-for-purpose lies in this principal as universality builds upon the advances in platforms and automation to allow for the rapid creation of polyglot solutions while still allowing teams to preserve the desired simplicity and speed that “fit-for-purpose” is intended to deliver.
When your API, integration and automation components are leveraged within a platform that understands and surfaces each of the different asset types and how to weave them together your delivery teams no longer have to care about the ancillary details of solution development.
This platform-centric approach is the lever that enables the BaaP/composability lens. All the time-saving and governance-supporting features are leveraged via a combination of automation and platform-wide conventions as components – regardless of protocol, tech stack, or type – are dropped onto the fabric of the platform. In other words, all the value chain events from discovery to operational management are fully integrated into the platform, ultimately relieving your delivery teams from the burden of administrivia and mode/context switching.
For more information on how to select and implement a universal platform that can launch your enterprise beyond the false dichotomies of yesterday, take a look at the latest advances from the MuleSoft team.
