Ensuring a Durable Transformation by Understanding the Risks

The following post is an excerpt from the book Unbundling the Enterprise: APIs, Optionality, and the Science of Happy Accidents by Stephen Fishman and Matt McLarty.

Thus far, we’ve been heads down on the conceptual models, economics, and financial methodologies behind the asymmetric growth that the digital pirates have exploited. In this chapter, we have one last item to add to your digital pirate supply kit (eye patch not included)—an unbundling risk management reference sheet.

To help keep your enterprise within a reasonable set of business, technology, and operational guardrails, we’ve enumerated a specific set of the riskier areas in an unbundling initiative, along with detection and mitigation strategies, for you to be aware of. The specific risks that are likely to come up over the course of an unbundling initiative include:

• increased security risk
• increased performance risk
• increased risk to quality issues
• increased operational complexity
• misapplying the MVP concept
• cannibalizing existing revenue
• technology-centered transformation
• misaligned talent model and processes
• losing discipline in times of compression
• choosing the wrong interface to control
• pervasive use of performative behaviors (aka optionality theater)
• In the following sections, we’ll go into each of these risks in more detail, including signs to look out for and mitigation strategies.

Increased Security Risk

Risk: An unavoidable consequence of standardizing your digital interfaces for machine-based consumption (i.e., utilizing APIs) is that you are making things simpler for hackers and bad actors to target and exploit. It’s just not possible to make things easier for your authorized partners and consumers to engage with without making things easier for hackers to target. Quantitative research, however, has shown that firms with APIs that are widely used in external contexts have a lower frequency of breaches by malicious insiders than enterprises that use APIs in an exclusively internalized context.¹ 

Signs to Look For: You’ll know this risk requires preventive attention or has unfortunately materialized when:

Your teams rely on security via obscurity and state that breaches are not likely to occur because you don’t publish the locations and addresses of API endpoints.

Your teams insist that your firm has no public APIs to be concerned about.

Your enterprise has a bespoke approach to security where individual teams and value streams are expected to come up with an approach that works for their unique context.

Mitigation Strategy: Ensure teams are supplied with the appropriate tools and support to treat security management as non-deferrable scope, with tactics including:

Be disciplined in your commitment to require teams that make APIs to assume that the APIs will be consumed by external parties at some point in their life span.

Institutionalize your enterprise’s commitment to establishing a layered defense where controls exist at all points of physical, data, and application infrastructure.

Commit to investments in centralized API-management tools that are not tightly coupled with specific development technology stacks.

Commit to investments in platform engineering capabilities that centralize the application of security controls on sensitive or proprietary data and content.

Invest in “shift left” technologies that scan for and identify security vulnerabilities before code is committed to repositories and deployed to production.

Commit to an absolutist approach to authentication where your enterprise never allows for scaled anonymous API access.

Increased Performance Risk

Risk: Performance and computing efficiency are both intrinsic trade-offs that come with an approach that builds value over an increased number of decoupled components. As the number of handoff points (often referred to as “hops” by technical teams) between different components increases, the inevitable downside is that each one of those handoffs will take time and computing cycles. For the purposes of this book, it’s not fully necessary for you to understand the ins and outs of performance profiling and optimization. It’s only necessary for you to understand the risk is there, why this particular risk is a “least bad option,” how to spot the risk when it is materializing, and what it takes to mitigate it.

Optimizing technical designs for speed of response and computing efficiency above all else is non-productive performance anxiety and is an over-rotation. A distinction to understand in the performance space is that risk of degraded performance and possible increases to the cost of infrastructure are often the preferred risks to have in a scaled enterprise. The performance risks are the preferred risks specifically because they are more easily mitigated than the alternatives (e.g., the time, effort, and cost to work around monolithic applications that have become too rigid for current market conditions can be astronomical when compared with the more manageable costs of incremental infrastructure).

Signs to Look For: You’ll know this risk is about to show up or has fully materialized when:

Your engineering and product teams oversimplify best practice guidance on performance management. A well-known best practice in this space is to leave performance and optimization concerns to later phases of development work to not waste time optimizing systems that may or may not be adopted by consumers. This idea is sometimes used, by less experienced teams, as a justification not to put any effort into anything that is related with optimizing performance.

Teams are consistently raising the “too many hops” concern (non-productive performance anxiety as referenced previously). 

Teams don’t have a sense of how to predict performance changes in different environmental and usage contexts.

Mitigation Strategy: Ensure teams are supplied with the guideposts and support that will help them prepare early and optimize late:

While detailed profiling and optimization can wait, enabling quick cycle times for isolating and solving performance issues cannot. Investing in observability tools and performance engineering processes will be a fundamental key to avoid non-productive performance anxiety.

Teams and leaders need to understand the benefits of optimizing for concerns that are complex to mitigate (e.g., cycle time) rather than concerns that are simpler to mitigate (e.g., network latency).

Strive for increased parity across technical environments. When the various environments used to develop and test software lack uniformity, the process for profiling and optimizing performance improvements becomes increasingly difficult (e.g., It’s hard to predict the efficacy of a driving technique in a Ferrari by testing it in a Honda Civic).

Understand how to quantify the value of performance across multiple contexts. Leaders and practitioners in online retail and media spaces are deeply versed in how milliseconds of performance improvements can improve revenue generation by millions of dollars. Outside of these industries, however, many firms lack any ability to quantify the value of improved versus degraded performance. Without a basic understanding of how performance translates to enterprise value, your teams will be left to engage in battles of dramatic speculation that often lack the grounding and sophistication necessary to make informed decisions that are optimized for the most valuable outcome.

Increased Risk to Quality Issues

Risk: More moving parts means more things to break. This is a fundamental truth of engineering, and it is not our contention that increasing the usage of decoupled modules will not have any impact on your ability to ensure quality in the delivery of your digital products.

Signs to Look For: You’ll know this risk has materialized or is looming when:

Your teams are overly reliant on manual testing practices and lack modern standards and sufficient tools for managing software quality (e.g., defect tracking software is the bare minimum and can’t be the sole tooling investment for your teams to ensure quality).

QA cycles and disciplines are segmented in a silo separated from software development and engineering.

No reliable and automated means of tracking basic QA metrics exists, including QA cycle times, defect escape rates, and mean time to recovery.

Experiments run on without end, leading to them being considered long-term solutions. This creates quality issues as POCs (proofs of concept) are not engineered for industrial use.

DevOps and CI/CD are exclusively focused on deployment automation rather than the full set of tasks to take a candidate release from one environment to the next.

Mitigation Strategy: Ensure teams are supplied with the appropriate guideposts and tools that will help them shift left in their approach to quality engineering:

Institutionalize an approach to ensuring quality that includes automated metric trend reporting, automated static-analysis and mitigation tooling, canary testing in production with controlled audiences, and treating testing automation on the same plane as infrastructure and deployment automation.

Ritualize the process of asking teams to compress the timeline, risk, and scale of experiments. Work with teams to investigate the possibilities of testing with a smaller feature set, smaller audience group, smaller target of applicability, or any other method they can think of to shrink the timeline and risk of an experiment.

Increased Operational Complexity

Risk: More moving parts, “black boxes” of opaque functionality, and greater interdependency will inevitably make your enterprise more complex to operate.

Signs to Look For: You’ll know this risk is bound to materialize when:

Documentation is scarce and automated onboarding tools for API consumers are not provisioned.

Your teams must routinely engage in unplanned work for security, performance, or quality incidents.

Your organization has not formalized an approach for managing and communicating changes to your APIs.

Mitigation Strategy: Ensure teams are familiar with and have the enterprise support to:

Be disciplined in your commitment to require teams that make APIs to assume that the APIs will be consumed by external parties at some point in their life span.

Utilize the practices from performance (“prepare early and optimize late”) and quality management (“shift left”) to enable teams with a smooth path to isolate and repair problems that arose from dependencies that are not well understood.

Establish a set of shared principles and practices for managing and communicating changes to your APIs.

Misapplying the MVP Concept

Risk: Throughout this book, we’ve spoken to the concepts of running market-facing trials and small experiments with low risk and expenditure. While many teams and organizations have adopted Lean development practices and the embedded concept of an MVP, not every team or leader fully understands the intended meaning and application of the MVP concept.

Introduced by Frank Robinson in 2001 and later popularized by Eric Ries in Lean Startup, the MVP has become a foundational concept to enterprises working on software projects around the globe. 

While most everyone understands “minimum,” not all teams are aligned on the meaning of “viable” or “product” in this context. The MVP concept was intended to be defined as the version of a new product that allows teams to gather the maximum amount of validated customer feedback with minimal effort. It is not about creating the product with the least number of features necessary for a public launch, but rather a tool for testing hypotheses and discovering what will meet customers’ needs.

Signs to Look For: You’ll know this risk has materialized when your teams exhibit any of the following behaviors:

Teams scope experiments around a product concept that has everything required for a commercial launch.

Teams look to enable the full set of capabilities and controls required for scaled usage and edge case scenarios.

Teams cannot express the basic consumer need or pain point that they’re trying to validate.

Teams fail to consider that experiments must be iterative to yield useful feedback.

When looking at the above listing of behaviors, pay close attention to the last example regarding the need for iteration. Whether your teams will need to build upon the learnings from a single trial or rework the assumptions and offering to find sufficient market fit, it will almost always be necessary for teams to perform several variations of an experiment to deliver the “maximum amount of validated customer feedback with minimal effort.”

Mitigation Strategy: Ensure teams are supplied with the guideposts and support that will help them:

When teams struggle with finding the right balance between “minimum” and “viable,” remind them of the intended goal and that the important thing is to focus on the principles of customer satisfaction, continuous improvement, and simplicity.

Remind teams up front that experiments are serial in nature and that enabling their trial concepts to be extensible via modularity is required to capture the intended learnings of the experiment.

Cannibalizing Existing Revenue

Risk: A consequence of enabling new digital channels of value consumption for your consumers is that these new channels can sometimes be competitive with existing channels of value consumption that already generate revenue for your enterprise. When considering experiments and offerings that might overlap with existing products and services, it is critical that your product teams have a nuanced understanding of financial details of the existing revenue streams (e.g., the amounts and trends of existing revenue streams, the operating margins of existing offerings, the likelihood of disruption to these existing revenue streams, etc.).

Signs to Look For: You’ll know this risk is in the process of manifesting when:

Digital product teams are experimenting with or launching offerings that have a high degree of overlap in the value that other enterprise products and services already supply.

Product development teams fail to evaluate how new digital offerings will lead to revenue growth for any existing offerings.

Product development teams fail to evaluate how new digital offerings can be positioned as extensions and add-ons to existing offerings.

Product development work in the software engineering lane is segmented from or independent of packaging and go-to-market strategy.

Mitigation Strategy: Ensure teams are supplied with the tools and techniques to understand value dynamics:

Utilize value exchange mapping techniques (detailed in Chapter 5) to understand not only the opportunities of unbundled offerings but also the possible competitive positions that your new offerings might take against your existing offerings.

Require teams to consider how an external product would generate recurring revenue via a packaging strategy before formalizing on an externalized interface design.

Technology-Centered Transformation

Risk: When technology teams charter and run business transformation initiatives, the tendency is for the objectives of those initiatives to be framed as technology-specific objectives rather than business objectives.

Signs to Look For: You’ll know this risk area needs attention when:

Initiative objectives are framed in technology-centric outcomes rather than business-centric outcomes (e.g., “Complete a shift to cloud-based infrastructure” rather than “Measurably increase speed to market of digital solutions by leveraging cloud-based infrastructure”).

Delivery teams cite low business team participation and engagement in initiatives.

Business and finance teams view the initiative as a technology-
driven program.

Teams spend inordinate amounts of time debating on low-value topics like protocol wars (e.g., GraphQL versus REST) at the expense of fully understanding how to reshape the process and operating models that undergird the mission-critical value streams.

Mitigation Strategy: Ensure teams are supplied with the tools and techniques to:

Ground objectives in measurable outcomes that are specifically relevant to business leadership inclusive of sales, finance, marketing, etc.

Offer training programs and educational reimbursement programs to build digital business skills along with basic API literacy.

Frame APIs as products regardless of any immediate plans for external consumption.

Help teams understand that products—units or vehicles of value delivery from a producer to a consumer—are not the exclusive domain of the product department or organizational unit (e.g., Is an employee portal or intranet a product? Would it be a bad thing if it were treated like one? Would it be a good thing if it was not?) and that product methods and mindsets need to be applied to give an appropriate level of stewardship and support to company assets.

Keep teams focused on the concept that group collaboration time must be heavily focused on business and operating model evolution and not on ideological wars that only concern a small segment of the teams.

Frame and ground transformation programs in the context of business and financial needs rather than technology outcomes. (Dr. Mik Kersten’s book Project to Product is an excellent resource to help people and teams approach and understand this topic.)

Misaligned Talent Model and Processes

Risk: Traditional talent recruiting and development models rightly place an emphasis on skills that are perceived as “core” to a specific role. As explained in Chapter 5, developing fluency in statistical analysis and tools will be necessary to keep the cost of experimentation low.

Signs to Look For: You’ll know this risk has materialized when:

Teams report on KPIs with an over-reliance on proxy metrics and singular numbers that don’t convey context (trends, percentages, inverse/direct correlations, averages rather than medians, etc.).

Teams habitually align behaviors to localized goals at the expense of enterprise goals.

Mitigation Strategy: Ensure teams are supplied with the tools and techniques to recruit and develop the skills needed for scaled unbundling:

Develop job descriptions that incorporate “m-shaped” profiles, where contributors are expected to have some proficiency in, and appreciation for, tasks and processes that are utilized by teams that they will be collaborating with.

Offer training programs and educational reimbursement programs to build data visualization skills along with statistical literacy.

Commit to using balanced scorecards, shared goals, and other talent management techniques that require collaboration and shared decision-making to achieve enterprise-level outcomes.

Losing Discipline in Times of Compression

Risk: In Chapter 6, we spoke at length regarding enterprise behaviors in times of disruption and compression. While “belt-tightening” mindsets are not fully avoidable given the nature of financial viability, it is advisable to arm yourself with tools and tactics to mitigate the impacts of organizational compression, especially in the areas where financial compression tactics are not aligned with preservation of value creation.

Signs to Look For: You’ll know this risk will soon materialize when:

Economic factors align to drive significant cutbacks across an industry or geographic segment.

Technology teams align to a platform model before business teams see the platform as a core component to the enterprise business model.

Teams are short-lived constructs that serve a project charter rather than a product charter.

Mitigation Strategy: Ensure teams and leaders are familiar with and aligned to:

The S-curve model of business management to allow for a measured and moderated conversation on targeted cutbacks paired with reinvestment on future horizons.

Not formalizing platform teams in advance of business understanding of the concept and acceptance of the offering as core to the enterprise business model.

Product-based finance models that include carve-outs to manage cross-cutting concerns like performance, quality, security, automation, and debt management.

Choosing the Wrong Interface to Control

Risk: A precept of how modularity and optionality work together to deliver scaled value opportunities is that you must choose where interfaces should lie along a value stream of activities, which interfaces you’ll want to tightly control access to, and which interfaces you’ll want to encourage engagement with. This concept is explained in depth in Chapter 3 and references the work of Dr. Carliss Baldwin when it explains that controlling the interfaces to value rather than just the systems that deliver value is the better strategy.

Signs to Look For: You’ll know this risk will eventually materialize when:

Your teams don’t have a process for understanding and evaluating how and when consumer value is added and harvested in your value streams.

Your enterprise has an extreme approach that either excludes all forms of partner-based delivery (a fully closed ecosystem) or has a Wild West approach to partner-based delivery (a fully open ecosystem with no methods for generating revenue via partner engagement).

Mitigation Strategy: Ensure teams have support to:

Utilize value exchange mapping techniques (detailed in Chapter 5) to understand where value is harvested by your firm, the partners you work with, and the end consumers.

Develop and evolve a rubric for both understanding your firm’s competencies (e.g., Are we qualified and able to market this unbundled offering to its likely consumers?) and judging the value at stake with a candidate offering.

Pervasive Use of Performative Behaviors (AKA: Optionality Theater)

Risk: All corporate initiatives are subject to the risks associated with performative compliance. Lean, Agile, DevOps, and API transformations are no exception to this rule. If your enterprise engages in an unbundling initiative or a digital transformation that is driven in part by APIs, at least some of your teams and leaders will engage in “optionality theater” to appear compliant with directives from enterprise leaders.

Signs to Look For: You’ll know this risk will materialize soon when:

Reward systems are indexed exclusively to shallow proxy metrics (e.g., number of APIs created, number of experiments executed, etc.) rather than business outcomes.

You hear teams defend poor judgment, lack of critical thinking, and cutting corners that impact downstream teams by referring to hard rules that don’t offer insight into applying them with a smart mindset.

Mitigation Strategy: Ensure teams are supplied with the tools and techniques to:

Commit to using balanced scorecards, shared goals, and other talent management techniques that require collaboration and shared decision-making to achieve enterprise-level outcomes.

Identify and root out processes where decision rights are granted to people and teams that don’t bear the consequences of those decisions (e.g., decision-makers must have “skin in the game” for the impacts of their choices).

To read more, get your copy of Unbundling the Enterprise: APIs, Optionality, and the Science of Happy Accidents by Stephen Fishman and Matt McLarty.

- About The Authors

Matt McLarty

Matt McLarty is the Chief Technology Officer for Boomi. He works with organizations around the world to help them digitally transform using a composable approach. He is an active member of the global API community, has led global technical teams at Salesforce, IBM, and CA Technologies, and started his career in financial technology. Matt is an internationally known expert on APIs, microservices, and integration. He is co-author of the O'Reilly books Microservice Architecture and Securing Microservice APIs, and co-host of the API Experience podcast. He lives with his wife and two sons in Vancouver, BC.

Follow Matt on Social Media

• 

Stephen Fishman

Stephen Fishman (Fish) is the NA Field CTO for Boomi. He is a practicing technologist who brings creativity, rigor, and a human-centric lens to problem-solving. Known as an expert in aligning technology and business strategy, Stephen places a premium on pushing business and technology leaders to embrace iteration and the critical need to collaborate across disciplines. Throughout his career, Stephen has consulted with organizations desiring to transform their technology-based offerings to better meet the needs of organizations and the people they serve. In addition to consulting with large organizations, Stephen is an in-demand speaker and advisor. Stephen has led multidisciplinary teams to deliver amazing results at Salesforce, MuleSoft, Cox Automotive, Sapient, Macy's, and multiple public sector institutions including the US Federal Reserve and the CDC. He lives in Atlanta with his family and when he's not working can be found biking on the many trails in Georgia.

Follow Stephen on Social Media

•