Change is hard. Whether we’re talking about making personal change or organizational change, the story is pretty much the same. It’s easy to look back and point out weak points in processes or results. It’s a lot harder to choose an approach that’s likely to lead to the desired results and then identify a good place to start making those changes real.
One change organizations struggle with is transforming into a composable enterprise. Becoming composable informs virtually every aspect of not just IT, but the business as well — which is why the two must move in lockstep throughout the journey. For both, the motivations to transform are clear.
What is a composable enterprise?
Composable enterprises are ones institutionalizing business optimization through organizational culture, digital transformation, and software architecture. According to Gartner, the higher the degree of business composability, the better a business performs across the most important organizational OKRs.
After helping thousands of organizations around the world to transform into composable businesses — in which the reuse of APIs is a pillar of operational and financial performance — MuleSoft has identified the typical obstacles to reuse and detailed approaches for getting enterprise software teams moving toward a future grounded in the ethic of “Proudly Found Elsewhere”.
3 ways reuse goes wrong
Many of MuleSoft’s global customers have gone all-in to create API ecosystems and a culture of reuse. While many of our customers are well on their way to accepting a “composable business” vision, it doesn’t always work out that way for highly distributed development teams that haven’t fully adopted a Center for Enablement (C4E) model.
In the cases where organizations have experienced friction on the path to a robust network of plug and play componentry, enterprises tend to fall into one of three anti-patterns, each of which results in limited or no reuse:
If you’re looking at the scenarios above and saying “that sounds like us,” don’t get discouraged. Achieving organizational transformation isn’t easy. Obstacles along the way often signal to your organization that there are more changes (especially in the people and process lanes) that still need to be made. While this may seem daunting, remember that this is the essence of transformation — you can’t transform without making significant changes across all three lanes: people, process, and technology.
5 keys to driving organic reuse
MuleSoft has defined a holistic approach with practical next steps to help teams avoid the three anti-patterns mentioned above. After working with thousands of customers on their transformational efforts, we have identified the five essential conditions for composability and reuse to become an everyday organic occurrence, and four paths that organizations can take in their journeys to become composable.
The five keys to unlocking everyday reuse include enterprise beliefs, shared tooling, financial incentives, product mindset, and software development lifecycle (SDLC) culture. As you look at each of these factors, try to stop yourself from waterfalling them as we’ll explain how the path to applying these factors can be optimized based on the type and priorities of your organization.
Enterprise beliefs
One of the primary conditions for a shift toward a composable and agile enterprise is a change in the attitudes and beliefs of the individuals and teams that collaboratively envision, develop, manage, and govern working software architectures and solutions.
When there is consensus on the goals for enterprise speed via composability and reuse, organizations open themselves to the types of benefits referred to in the above Gartner research.
Shared tooling
To support the beliefs and processes for propelling a culture of reuse, advanced shared tooling is a quintessential condition.
For organizations to deliver high-quality API experiences to developer communities and consumers, shared tooling becomes an important factor for reuse efficiency. Giving your solution and development teams access to consumer-grade tooling experiences will improve developer experience by enabling API discoverability and API documentation. Building APIs with set tooling standards for design, search taxonomy, and documentation will improve the overall experience driving reuse adoption.
Financial incentives
Many organizations often face financial impediments in attempting to achieve reuse, which are difficult to address because financial alignment requires a systems-thinking approach. Supporting enterprise-wide reusable APIs requires a financial funding model, especially if the reuse teams operate as cost-centers. Many organizations struggle to build a framework for appropriate taxation or charge-back models to fund their reuse teams.
The accomplishment of organic reuse depends on whether API owners and developers are incentivized to build for reuse.
Product mindset
There is a common perception about APIs and their role in an enterprise. Many organizations view APIs as system integration technology. While this is partly true, APIs are much more than mere lines connecting systems. APIs not only allow the developers to continuously leverage data, functions, and applications to create new services for consumers, but also provide a way for businesses to showcase their qualities through software.
APIs enable enterprises to transform software into products and experiences when an “API-as-product” mindset is established in both business and technology teams. This mindset rests on three primary pillars: customer-centric experience fueled by an “outside-in” approach, an emphasis on improving time to market, and a culture of iterative design through constant feedback.
SDLC culture
Separate from the beliefs of teams across the organization are the rituals and processes that make up traditional SDLC culture. Recognizing the need for improved time to value and agility, new ways of working have been forming as teams shift from waterfall to agile. To extend these new ways to “plan for reuse,” the first step is for the development teams to survey the existing leverageable assets before building new projects.
4 paths to a composable future
There are five keys to organically spinning up the reuse flywheel and unlocking the benefits of composability. However, each organization is different and the problems they face are also unique. The heavier the flywheel, the harder it is to initiate rotation. Attempting to address all five of the aforementioned factors is equivalent to over-weighting and paralyzing the flywheel.
Based on our work with customers, we’ve discovered that initial attention to three of the five is enough to trigger rotation. Later, once that flywheel is spinning, the organization can address the remaining two. But which three? As it turns out, one size does not fit all, likewise, each organization needs a distinct approach to removing the obstacles they face in maximizing the reuse.
MuleSoft has modeled organizations based on the factors they fit in. Paths to change and a composable future is possible in every scenario once we identify where we are and where we need to be.
Enablement-first organizations
Not every organization arrives at alignment via top-down messaging. In many organizations, standardization comes by making compliance the path of least resistance for contributors. In this context, the lack of proper tools and governance structures combine with cultural inertia to defer activities on reuse and stifle conversations that would bring balance to specific project approaches while managing expectations from local leadership.
To create the space where new models, grounded in strategic thinking, can take hold, process and tooling need to mature to weaken or remove the objections of distributed teams. Once a reasonable baseline has been met for process and tooling enablement, the path is clear to stand up discussions on creating the right financial approach that will both incent teams towards the behaviors that drive composability along with the funding necessary to adopt a product mindset with regard to documentation and operational tooling.
Top-down organizations
While autonomous teams and agile decision-making may be the goal for many organizations, this preferred end state is still optimized with an appropriate level of leadership guideposts that act as guardrails for distributed teams. In these organizations, far-reaching, strategic decisions are made at the top and rolled down the chain of command. Without an appropriate level of executive sponsorship, your SDLC culture and tooling will be fragmented by default, ultimately making conditions difficult for composable behaviors to take root.
In this context, fostering belief in the strategy of composability and reuse are necessary to create robust executive sponsorship financial support to get change started. Once executive support is present, these types of organizations can foster the reuse culture by promoting improved SDLC governance and organizational tooling to lower any local friction on project teams.
Design-led organizations
These organizations are architect/developer-centric and tend to design each project independently. Lack of tools to discover reusable assets and lack of product mindset makes it exceedingly difficult to maximize reuse. Similar to enablement-first organizations, they usually lack executive support and financial funding.
These organizations require an approach that wins the hearts and minds of the engineering and architecture communities. Before working on an end-to-end SDLC culture change in how they design and build solutions, we advise design-led organizations to focus on shared tooling and a product mindset to appeal to teams’ desire to “get stuff done” with a future proof mentality. Jumpstart new behaviors using a new discovery and consumption model along with the tooling to make adopting the new culture and process as simple as possible.
Experimentation-led organizations
These organizations do not make abrupt changes to their beliefs and approach. They prefer a concept to be applied to smaller use cases. They want to experiment with the change, get feedback, understand broader ramifications and want to measure the impact before they roll down the changes to the masses. These organizations might build proof of concepts before swallowing any new concept.
In this model, the first priority is to introduce the concept as an experiment and build a reference architecture along with the entire SDLC process drafted. KPIs can be measured for the reference model to measure productivity improvement and other benefits that the new model brings in. Once the benefits are transparent to all parties, adoption of new financial systems and productization work can be more easily introduced to the wider organization.
[blog_post_Ads]
Many paths, one destination: the composable business
Once you’ve decided which of the above archetypes fit your organization, it’s now time to get started on helping your enterprise get aligned and on the path towards manifesting a composable business model.
As a committed partner to the success of our customers, we’ve built a robust set of assets to help you bust through each of the above obstacles in whatever order makes the most sense for your business and culture:
- Need to get your executives on board? No worries, we’ve done the math and can give you the quantitative tools you’ll need to make composability a no-brainer.
- If you’re interested in maximizing the power of your shared discovery tooling, check out our Friends of Max video library with bite-size instructional videos targeted to help you design and roll out a taxonomy that will help connect your API producers and consumers.
- If you’ve been tasked to put chargeback or show-back tooling in place to align your financial systems toward making your enterprise more composable, dive further into unlocking reuse with the right conditions; it will get you producing shared service bills in no time.
- Got an appetite for enabling an API-as-product strategy? Read about creating a robust approach that will make your API consumers love your digital products.
- Looking for detailed guidance and templates for mapping out your SDLC processes and checkpoints? Dive into KnowledgeHub and leverage the best practices we’ve gathered from working with global organizations committed to transforming their processes.
This blog is the result of a collaboration between Stephen Fishman, Hemanth Kasibhatta, David Berlind, and Mahesh Sane.
