Some things in life cannot be pursued directly. Success and happiness, as noted in Viktor Frankl’s Man’s Search for Meaning, come to mind. Enterprise software reuse is another outcome that cannot be directly pursued. Reuse, like happiness or success, happens when the conditions are right. This concept is specifically important if your enterprise is looking to drive software reuse, and ultimately aiming to create an application network. This is because it’s instructive in telling you what to aim for; the right conditions.
Reuse emerges from the right conditions
When envisioning and creating cultural change within an organization, one can look to current events, history, film, art, works of fiction, and other sources for inspiration. For transformational efforts, I often look to the Tron Legacy and how Flynn and his son, Sam, discuss the emergence of the Isos. “You created them?” Sam asks. Flynn laughs in reply, “No, no. They manifested, like a flame. They really weren’t from anywhere. The conditions were right and they came into being.”
A critical component left out of this scene is the effort that went into creating the “right” conditions. This is the core impediment in shops where reuse is not a natural occurrence. There isn’t a focused effort to create a set of conditions than call forth a culture of reuse. In my experience leading and working with application development teams in transformational efforts, leaders and organizations develop initiatives to drive reuse, but often neglect to address each of the five critical conditions that would allow reuse to become the default behavior:
- Ethics and ideals: What are the values and beliefs of the organization and the individuals who drive and influence decisions around the reuse of software assets?
- SDLC process and culture: What standard systems development life cycle (SDLC) processes and rituals exist to drive teams to look for reusable assets rather than developing new assets from scratch?
- Tools: What systems and tools are in place that aid in the discovery of existing assets and on-boarding of new users for those assets?
- Measurement and financial implications: How will reuse be measured across an enterprise? How will effort in making/leveraging reusable assets be treated financially in project costs, cost of compute, etc.?
- Product orientation: Do your technology delivery teams take a product orientation in relation to the assets they produce? Are design and product disciplines included in the process for envisioning and evolving API products
When enterprises make focused effort in each of these areas, the climate and conditions within development teams will begin to shift. Once the new incentives and affordances set in, teams will begin to follow the path of least resistance to depart from the land of “not invented here” (NIH) and arrive in the new world of “proudly found elsewhere” (PFE).
From “Not invented here” to “Proudly found elsewhere”
If your technology and development teams show a strong bias to rolling their own solution for commoditized capabilities that are readily available and integratible into your value streams (AKA – “undifferentiated heavy lifting”), that’s a sign that you currently reside in the township of NIH. If on the other hand, your organization ritualistically beams with pride when they leverage the managed capabilities of others (AKA – “composition over coding”) to drive speed-to-market and allow employees to focus on widening differentiation at the edge, then you’ve arrived in the cityscape of PFE.
The journey between these two lands is not always a smooth one. The obstacles and challenges you’ll face in the effort to manufacture the right conditions will vary from enterprise to enterprise and team to team. These will fall into one of the five categories listed below:
Challenge #1 – Changing the beliefs
When shifting from NIH to PFE, the first set of challenges will arise in the need to change the attitudes and beliefs of the individuals and teams that collaboratively envision, develop, manage, and govern working software solutions:
- NIH teams inhabit the world as if their requirements and context are unique snowflakes. Helping these teams move beyond the black and white dichotomy of “buy vs. build” into a new way of thinking along the lines of “compose and enhance” is easier when you remind them that the most successful enterprises have built their businesses on top of frameworks and APIs that were built and operated by different groups of people than those who use them.
- PFE teams understand that “standing on the shoulders of giants” rather than aiming for “self-sufficiency” is not only the quickest path to market, but is also the only path that allows for scaled growth in today’s marketplace that has evolved from “big beats small” through “fast beats slow” to “big and fast wins every time.”
- Many architecture advocates eschew dependencies under the banner of controlling your own destiny. Local control is a good thing. There is, however, a higher ground out there; not having to care about your dependencies because their resiliency and simplicity approaches “appliance” status (e.g., are cloud-based platforms like Twilio, Salesforce, AWS, MuleSoft, and New Relic brittle dependencies or highly available levers?)
Challenge #2 – Changing the culture
Separate from the attitudes and beliefs of the team are the rituals and processes that make up the SDLC culture. Making culture change in the “ways of working” will create challenges for individuals and teams that participate in and manage the software development and operations factory.
- New ways of working have been forming as teams shift from waterfall to agile, but these new ways haven’t fully extended to “planning for reuse” or “surveying existing assets.” To help your teams make this shift, start a shift of your own, and shift the burden of proof. Instead of having to prove that reuse is possible, require your developer and architecture teams to make explicit efforts and to document them.
- It may not be possible to prove a negative, but it is possible to prove that you put effort in your search for available assets (e.g., APIs, design artifacts, automated tests, pipeline configurations, fragments, onboarding documentation, etc.).
- Taking this practice to the next level, you could require teams to confirm via peer review that all proposed new componentry has no existing asset that could be leveraged and enhanced.
- The last step in this change would be to formalize a “reuse report” where sprint teams must articulate a digest of what assets they are reusing in a sprint. Having to articulate and validate a zero in the standups and retrospectives will create social pressure to put real effort into the survey processes.
Challenge #3 – Changing tools
Expecting changes in beliefs and practices without investing in advanced tooling to support the changes is not a winning strategy. For whatever reason, many enterprises fall into one of two camps 1) Jump right to tools with the idea that “tools solve problems” or 2) Completely overlook tools with the idea that “process solves problems.” However, neither of these approaches work and the path to creating the “right conditions” includes making multiple complementary investments across people, process, and technology:
- Discoverability of APIs within shared catalogs is table stakes here. Using MuleSoft’s Anypoint Exchange or Anypoint Community Manager are good examples of shared catalogs with rich feature functionality.
- Remember that catalogs are only as good as their contents, meaning that you’ll have to jump back to challenge sets one and two to help people understand two key concepts:
- They have a responsibility to create and publish reusable assets in ways that are easy to find and understand.
- SDLC processes must give room to create and publish content just as they must account for time to search for content.
Challenge #4 – Changing financial models
Financial model changes are the final frontier and for many teams can be the most difficult set of challenges because it is these types of changes that require a systems-thinking approach. Keep in mind that there are likely other recent examples of financial reframing that you might be able to reference when attempting to institute this change (e.g., agile, DevOps, etc.):
- Just like CI/CD (Continuous Integration / Continuous Delivery) and other automation projects, initiatives to create the conditions that allow for a culture of reuse to emerge require investment, but this does not mean that it’s accurate to talk about them as “cost drivers.” Reuse, like automation, only costs money when your time window is small. Providing a wider time range to your model saves money rather than costing money.
- NIH teams may think they have the upper hand when looking at the cost to use pre-built, pre-tested software compared to the “no-cost” software they wish to build, but this approach belies the TCO truth. All “roll your own” components have a carrying cost beyond development (i.e., maintenance and upkeep). In an ecosystem of reuse, your suppliers manage releases, patches, and maintenance for you. These changes may cause intermittent costs for you as well, but these costs are small when compared to self-driven maintenance and operations and they are mitigatible if you’ve been wise enough to invest in automated testing (another great source of money and time-saving reuse).
- In shared application infrastructure, a sticking point may emerge regarding the cost of computation where the team that creates the reusable thing may have to pay every time the reusable thing is called. Helping teams understand and adopt new models (e.g., chargeback, true-ups/downs, reuse credits/incentives on capacity for teams that make highly reusable assets, etc.) are a necessary effort to make reuse the “path of least resistance.”
- Leadership must “bootstrap new models via carve-outs” to transcend the current zero-sum-game that is scope/feature management. For example:
- Release train teams could be given a base level expectation to architect their systems to create reusable components, leverage reusable components, or in the best case scenario do both.
- Project success metrics could move beyond standard “on time, on budget, on target” criteria and into the world where being “on time, on budget, on target” is necessary to pass (i.e., you get a “C”) but is insufficient for praise. Getting an A could include “improving the conditions for those who come after you” and “adding to the ecosystem of reporting metrics” that are necessary to successfully scale and manage a software factory.
Challenge #5 – Changes in product orientation
While finance is on the internal end of the continuum for organizational change, product is at the other end. Traditionally, technical components like APIs are seen as the domain of engineers and architects, but this ownership model doesn’t account for the needs of diverse audiences and the fit and finish work that is best handled by qualified designers. Creating the scalable patterns for interactions, standards, and vocabulary can be handled by IT staff but most IT staff lack the training necessary to remove themselves from their own experience to account for aspects that remove friction from the adoption process:
- NIH teams may hear “design” and think in terms of “technical design” and push back on the need for collaboration. Handing over the reins on decisions for vocabulary, and interaction patterns can be tough for engineers and architects who have only known the world where their decisions on items like naming and compositional strategy went unquestioned. Working with your SDLC teams to adopt an “outside-in” product mindset along with the roles and responsibilities in development teams is a critical first step to give teams the right skills to optimize your API products for adoption.
- Technology and product leaders must come together to map the discovery and onboarding experience for consumers and ultimately create a process and plan to measure the high -friction points in the journey to adoption and optimize for them.
Generating the winds of change
While the sources of friction and required changes above may seem daunting, there is one leverage point that will make the journey more manageable: social pressure. Just like agile or DevOps transformations, once team X sees the value that is being generated and captured by team Y, social pressure to align with the new model starts to kick in.
Taken all together, what this means for API platform and product leaders attempting to create a culture of reuse:
- Focus on the willing: Identify the teams who are willing and motivated to lean into the changes required to change the operating environment of how software work gets done.
- Measure and capture value: Ensure teams establish baselines and start to measure the benefits received from reuse.
- Complement bottoms-up with top-down: Establish a partnership between teams that are leaning into change and executive sponsors to understand and evangelize the benefits of the new model.
When your organization can systematically manufacture the new set of conditions, while simultaneously creating a transparent view into the benefits that are being received, the fly-wheel effect takes over. The conditions you’ve created will allow for the pivot between the uphill climb (which involves pushing) and the downhill descent (which is more about governance and ownership) and you’ll end up like Tron’s Flynn admiring the new world you’ve created.
If you’d like to learn more about systems of reuse and the benefits of the API-led methodology, check out the three-part series on reuse.
