Transcription
A platform ecosystem as acatalyst for transformationDereck Vanlandingham, Open Transformation Principal, Red Hat
PrefaceFor quick and specific takeaways, refer to the following sections on: Common myths of IT transformation—see Why transformation efforts fail. Why organizations should use a platform—see The goals for a digital platform.An enterprise mighthave a digital platform,platform team, and acommunity, but organizations rarely explorea holistic relationshipbetween these threeentities—one that takesinto account the transformative benefits ofovercoming organizational challenges. Common missteps—see Common mistakes limiting platform adoption. Roles and responsibilities—see Functions of the platform team. Creating the ability to differentiate at scale—see A digital platform as an interface between development and operations. Ready to move forward—see Recommendations for implementation.IntroductionEnterprises today are exploring ways in which they can adapt quickly to constant and rapid changesin the business environment. The pandemic made it abundantly clear that the ability to adapt oftendetermines which businesses survive. As a result, organizations are seeking strategic agility—theability to sense changes in market conditions and implement new strategies quickly and decisivelywhen necessary.1To transform slow-moving technology organizations, IT leaders want to implement IT industry movements, purchase popular tools, and explore different operating models. Often, these strategies onlymake a small impact. Focusing too much on technology—and not enough on people and processes—isa common theme, and change is often met with resistance. Transforming an organization requires acontinuous process of adopting new ways of working and a culture of experimentation in addition tonew technologies.2 A culture that fosters rapid experimentation has the ability to arrive at better outcomes. Encouraging this dynamic leads to continuous improvement through continuous learning.This e-book describes a holistic approach to using a platform ecosystem as a central tool of transformation. The ecosystem consists of a digital platform, a platform team that creates and managesthe platform as a product, and a platform community that helps the platform ecosystem thrive andfulfill a sustainable purpose. The digital platform is emerging as a focal point for transformation as itcan reduce the cognitive load on technical staff who are overburdened with delivery pressures andmounting technical debt, two of the many impediments to transformation. 3 Enterprises can increasethe effectiveness of their platform community by applying lessons from the way communities areorganized around successful open source projects.Some enterprises might fail to reap the benefits of their existing digital platform because they havenot carefully considered the makeup of the platform team and the role of a community in platformadoption. When enterprises understand how the entire platform ecosystem can work together, thethree platform entities can form a symbiotic relationship. Used pragmatically, the platform ecosystem provides a common ground that promotes sharing and learning across teams. This commonground can be used to alleviate some of the inherent tensions between different teams that pany/red-hatredhat.com1 SAFe, Scaled Agile. “Organizational Agility,” 27 Sept. 2021.2 Haff, Gordon. “IT modernization: 5 truths now.” The Enterprisers Project, 3 Aug. 2021.3 Team Topologies. “Core ideas in Team Topologies,” accessed 21 Oct. 2021.E-book A platform ecosystem as a catalyst for transformation2
conflicts. It is also important to promote learning to address the growing IT skills deficit. Overall, theimprovements to IT processes from this symbiotic relationship help the organization develop itsstrategic agility.Red Hat has a unique, 360-degree view on how platforms can catalyze digital transformation. Thecore of Red Hat’s business is technology platforms, initially with Red Hat Enterprise Linux and laterwith Red Hat OpenShift and Red Hat Ansible Automation Platform. The related open source communities that Red Hat contributes to are integral to the success of those platforms. The communitiescontribute innovation and adaptation that make the subsequent enterprise products attractive andkeep them relevant. Additionally, the community model provides a rapid pace of research and development in these open source projects. Red Hat gains valuable insights while helping enterprises usethese platforms to solve technology challenges. Red Hat Services engages with customers to helpthem apply Red Hat’s experience to their transformation efforts and implement a platform ecosystem that helps them achieve their digital transformation goals.Why transformation efforts fail: Three common mythsIT leaders and decision makers are often led to believe that industry shifts or movements, tools, andindividuals will help transform their organizations. There is a tendency to believe those factors willmagically deliver success despite the challenges of technical debt, inadequate skills, a less thancommitted leadership team, and internal organizational conflicts. These challenges prevent manyorganizations from addressing the true causes of their stress—like traditionally segmented organizational structures that separate skills into specific groups; unevolved governance, risk, and compliance(GRC) methods; and a lack of space to learn and make meaningful improvements.Myth one: “The next IT industry movement will transform us”Looking back at the last two decades, there have been many industry movements touted as the nextbig catalyst for transformation. Some movements have been used successfully by some organizations. Notably, initiatives like agile methodology, DevOps, and site-reliability engineering (SRE) weredesigned to optimize specific phases of the software development life cycle (SDLC), not to transform an organization. Even when these initiatives were adopted successfully, the changes exposedand exacerbated existing weaknesses or capacity issues within the organization. In other words,these changes often simply shifted the source of friction within the enterprise, rather than solvingthe root cause.Agile practices, for example, helped instill a more nimble mindset at the group level, improving thespeed at which ideas flowed to working software. The downside to agile ways of working occurredwhen distinct groups needed to interact. When software was released more frequently, frictionbetween development and operations increased. With automated testing, agile development teamshad faster delivery cycles—when they worked with other groups (who still relied on waterfall andmanual testing), they were unlikely to address key operational concerns, such as whether the software was production ready or required further validation. Additionally, these agile teams often failedto monetize the impact of their work, making it more difficult to secure executive buy-in, an essentialingredient to realizing the ambition of enterprise agility at pace and scale.redhat.comE-book A platform ecosystem as a catalyst for transformation3
The DevOps movement looked to address the next challenge, specifically increasing collaboration between development and operations groups and removing developers’ tendency to “throwcode over the wall”—completing their contributions to the DevOps life cycle and then handing offtheir work—without considering production concerns. Unfortunately, in recent years, the industrylost sight of why organizations adopted DevOps practices in the first place. The intended collaborative effort was reduced to describing a tool set (e.g., the DevOps pipeline), a team function (e.g., theDevOps team), or a specific role (e.g., DevOps engineer). These changes fail to address the underlying problem, which is the lack of understanding and empathy between developers and operatorsthat lead to the creation of the wall of confusion. This DevOps concept “Refers to the phenomenathat occur when one group in a value stream approaches their job as complete when they’ve passedit onto the next group.”4 And that approach hardly fosters the collaboration and accountability thatdigital transformation requires.The SRE movement, in recent years, further defined the accountability needed between development and operations groups explicitly in the implementation of service-level indicators (SLIs),service-level objectives (SLOs), and error budgets. Many enterprises are in the process of evaluatingSRE methods. However, some organizations are not making the core changes needed to implementthe SRE methodology effectively. Trying to turn existing operations groups into SRE teams does notaddress the existing skills deficit. SRE practices require software development skills to implementautomation and observability to reduce the manual effort required and improve reliability.Other industry movements, like API first, advocate for a holistic mindset. API first spawned froma Jeff Bezos mandate at Amazon requiring that all capabilities would first have to be designed andexposed as application programming interfaces (APIs). 5 If done right, an API-first strategy can helpbridge groups and capabilities. For Amazon, integrating everything they were building as an APIhelped create a platform that became the foundation of an enormous platform ecosystem. However,organizations that try to copy this approach often do so without thinking through the needs of theirconsumers, or worse yet, lack the cultural muscle that always puts customers’ needs at the center ofdevelopment, so they wind up with a proliferation of APIs that are not fit for their intended purpose.While some organizations have had success from participating in these movements, there are manythat have not. One primary cause is focusing on the technical aspects without considering the organization aspects. For example, enterprise leaders should consider: If software releases become morefrequent, how does that impact other parts of the organization? Additionally, trying to oversimplifyand superficially implement the guidance prescribed by a movement can result in failure. In some ofthe worst cases, partially applying the advice of the movement basically amounts to a rebrandingexercise in which existing teams are given new names and increased responsibilities.Myth two: “Adding digital customer experiences can help us transform faster”Another common myth of transformation is the belief that creating a digital group that focuses onthe customer experience will help you transform faster. These teams are responsible for emergingtechnology channels, like mobile and web, while also incorporating the use of new tools, techniques,and development languages to speed delivery. These teams’ goals prioritize business differentiationat the expense of organizational efficiency. Often, many of these newer technologies would not bepermitted in other parts of the organizations because they do not meet existing technology standards for those groups.4 Kawaguchi, Stephen. “The wall of confusion.” Git Connected, 28 Feb. 2020.5 Wilde, Erik. “Jeff Bezos’ API mandate: What the five rules mean and do.” Axway, 25 May, 2021.redhat.comE-book A platform ecosystem as a catalyst for transformation4
Leaders often think that a digital team will provide examples that the rest of the organization willlearn from and use to transform. Digital teams tend to have initial success at delivering rapid innovation when their efforts are contained within the digital team’s domain and functionality, like presentation and search. However, the digital team can also create organizational turbulence, especiallywhen the stream of work is dependent on the broader and slower moving parts of the organization. Creating meaningful digital customer engagement requires interactions with core enterprisesystems that are the domain of other teams. Differing delivery timelines, reliability concerns, technology platforms, and development and testing methodologies can all contribute to this turbulence.For example, a financial services company exploring new lines of business had its digital team createthe interfaces for customers to rapidly apply for loans through an affiliate. As many of the backend capabilities had yet to be modernized, the credit scoring systems for those loans only existedwithin the bounds of the legacy system. The potential impact of adding this new service was not wellthought out or communicated to the team managing the legacy system, in particular those responsible for capacity planning. End-to-end testing was inadequate. Nor did they consider or implementkey management functions for monitoring, observing, and throttling the new load.The result was that core business operations on the back-end systems were put at risk as the backend systems quickly became overloaded. The teams involved did not have good avenues to collaborate. The digital team, while well versed in newer technologies, lacked the operational experience torealize that even changes that seemed relatively minor could have unintended consequences.Yet another financial services firm that aspired to differentiate the customer experience for theirhigh-net-worth customers struggled to do so because their legacy systems organized customers byproduct instead of total value to the institution. If a high-net-worth customer called the bank about acredit card problem, then the customer service representatives would not have the system capabilityto see that this individual had many millions of dollars across numerous products. As a result, the firmwould not be able to offer differentiated customer experiences based on that information.Myth three: “We can hire around our IT skills deficit”There is a shortage of people with the desired skills available to fill technology roles. Industrydemand for skilled workers is constantly increasing, while the number of people in the technologylabor market is not growing at anywhere near the same rate.Additionally, there is a skills gap where existing staff and even recent graduates are missing critical skills that are necessary to be effective in the current landscape. Existing staff are frequentlyexpected to quickly learn new skills for working with modern technologies. Recent graduates likelylack practical skills that were not taught as part of their computer science curriculum.Learning has not been a priority for many organizations, so staff is not given the time, opportunity,and encouragement to develop their skills, which can lead to anxiety as they realize that they arefalling behind the technological curve. Isolated IT organizational structures that group people byskills exacerbate the problem. This approach encourages overspecialization for current experts andlimits learning opportunities for those without expertise. This segmentation by skill leads to a lack ofunderstanding of what the other roles do in an IT organization and prevents cross-functional training that could improve collaboration and reduce reliance on key stakeholders, specialists, or experts,also known as skills liquidity.redhat.comE-book A platform ecosystem as a catalyst for transformation5
A platform ecosystem as a catalyst for strategic agilityGenerally, strategic agility is about coordinated action at speed and scale inservice of becoming or remaining competitive. Strategically agile organizationsare able to seize opportunities (with these windows of opportunity closing fasterand faster) and mitigate potential threats faster than the competition.Strategic agility is not only about faster strategic decision-making, but the fluiddeployment of people against whatever priorities matter most to an organization. A critical first step on the path towards becoming more strategically agileis for an organization to define what strategic agility means in their terms. Fewenterprises pause long enough to think through it and determine what metrics(quantitative and qualitative) will they move the needle on if they become moreagile. The unfortunate truth is that most companies merely default to “I’ ll knowit when I see it.”Dr. John KotterChairman, Kotter InternationalA platform ecosystem can act as a catalyst for change. The ecosystem consists of the digital platform at its core, a team to build the platform as a product, and a community of platform consumersand contributors. The platform team and the community are the key to increasing platform adoptionand satisfaction. The symbiotic relationship of these three entities can be used to reduce organizational barriers to change and build adaptive capacity within an organization. Figure 1 shows the relationship between the three entities in the platform ecosystem.Support and influenceBacklog directionand contributionThe platform teamThe communityDecision makingand productmanagementA compellingfocal pointThe digital platformA tool fortransformationReusable artifactsand shared servicesFigure 1. How the three parts of the platform ecosystem contribute to decision making using shared resourcesand toolsredhat.comE-book A platform ecosystem as a catalyst for transformation6
In most organizations, the role of a platform and platform ecosystem in catalyzing digital transformation is not always recognized up front. Some enterprises invest in a digital platform but fail to put thenecessary staff or programs in place to support long-term adoption.An enterprise might have a digital platform, platform team, and a community,but organizations rarely explore a holistic relationship between these threeentities—one that takes into account the transformative benefits of overcoming organizational challenges.In many cases, the planning and the vision only go as far as an initial pilot project. Early thinking aboutbuilding a sustainable platform ecosystem helps avoid two common pitfalls where transformationprojects fall short: lost momentum and an overemphasis on technology. By the time the pilot projectis completed successfully and the next round of planning begins, momentum is lost and interestwanes. Worse, this cycle can be repeated when the people involved in the pilot project start to lookfor the next hot new project to work on. Another benefit of concentrating on the platform ecosystemis that there is an emphasis on people, processes, and culture rather than just technology.The true value of the platform ecosystem can be experienced when organizations use this modelto focus teams’ energy and develop organizational learning based on measurable and monetizableimprovements. Then, all those involved can work in a common direction instead of pursuing different,possibly competing, directions.A digital platform as a focal point of transformationIn many organizations, internal platforms have a bad name. Historically, internalplatforms meant slow, cumbersome, ticket-based access to a bewildering arrayof difficult-to-use services and systems with little consideration for the effecton teams using the platform.In contrast, successful internal platforms of the future will explicitly provide acurated experience for teams using the platform, reducing team cognitive loadand enabling a fast flow of change within teams using the platform. In fact, suchplatforms already exist and organizations following these principles from TeamTopologies find this approach provides huge benefits across the organization.Matthew SkeltonHead of Consulting, Conflux; co-author of Team TopologiesThe digital platform is emerging as a focal point for transformation as it can reduce the cognitive loadon the IT staff who are overburdened with delivery pressures and mounting technical debt, two of themany impediments to transformation.66 Team Topologies. “Core ideas in Team Topologies,” accessed 21 Oct. 2021.redhat.comE-book A platform ecosystem as a catalyst for transformation7
For many organizations, the core of the digital platform is a piece of off-the-shelf software. This buyversus-build decision avoids creating functionality that is already available on the market and allowsdevelopers to focus on the needs of the organization. The organization can then depend on the platform vendor to support the software and provide updates.The software product used as the platform core should represent the basic operating system of thedigital platform, not the digital platform as seen by the organization. The true platform, however, iswhat the organization builds on top of that core.A digital platform is a foundation that consists of self-service APIs, tools, services, knowledge,and support that are arranged as a compelling internal product. Autonomous development anddelivery teams can make use of the platform to deliver business functionality at a higher pace, withreduced coordination.7An enterprise’s digital platform can be used as an interface between different teams to improvecommunication and collaboration while reducing the need for lock-step coordination. This functionality can include work among various development teams or between development and operationsteams. This approach can be particularly useful when the teams have vastly different delivery timeframes and management objectives.The goals for a digital platformWhen using a digital platform as a focal point for transformation, an organization’s goals can include: Making the process and experience of developing software within the enterprise easier. Manyorganizations prioritize improving the developer experience. Fostering and encouraging reuse by making sharing, contributing, and using existing solutionseasier than looking for a solution externally or just reimplementing one. Acting as a broker to self-service offerings. The services offered are an opinionated set of choices,tailored to the enterprise’s specific needs. Streamlining operations by eliminating unnecessary variety in the way technology projects aredelivered. The operational landscape should be simplified, favoring capabilities that are deliveredthrough the platform. Providing a home to host shared services and data that become part of the digital platformand increase the platform’s scope. These shared services should ideally reduce the effortdevelopment teams need to spend on functionality that does not deliver business valueand differentiation. Creating SLIs and SLOs that focus on reliability and accountability. Both development and operations need to be part of this process. This should replace the SLAs that typically exist betweenoperations and development that do not go far enough to consider the ultimate end user’sexperience.When used effectively, a digital platform should encourage learning and new behaviors. To dothis, the digital platform needs to evolve beyond the software components, ultimately treated as aproduct in a new group within the organization.7 Bottcher, Evan. “What I talk about when I talk about platforms.” martinfowler.com, 5 March, 2018.redhat.comE-book A platform ecosystem as a catalyst for transformation8
A platform team to build a platform ecosystemTo attract and retain platform consumers, the platform team must create a compelling platformproduct. Whether the platform is compelling will have more to do with how the platform functions asan ecosystem within the organization than just technical excellence. Creating a platform ecosystemis a journey. It can take some organizations 18 months to three years to realize the true potential. Thisdelay is often due to short-sighted approaches that make the process take longer.Common mistakes limiting platform adoption can include: Lack of vision for how the platform can be used. Many organizations will buy a platform and focuson that purchase decision, rather than developing a vision for how the platform will be used. Not devoting resources to finding, engaging, and educating potential platform consumers. A keymistake is focusing on meeting the needs of a single initial consumer group or not involving consumer groups at all and just anticipating that if we build it, they will come. Not using feedback cycles to clearly understand the platform consumer experience—in particularthe developer experience—and the needs of groups using the platform. Putting the platform and platform team under IT operations leadership. This approach can be detrimental. Existing operational practices might not be conducive for developing and growing theplatform and can include: Forcing the use of a ticketing system. Using this kind of system for communicating obscuresunderstanding of gaps in the current platform and the roadmap of new functionally needed. Making it too cumbersome to contribute to the platform. Failing to look at a platform beyond service-level agreements (SLAs). Not using the platform in a way that promotes accountability across groups. Using possibly outdated IT governance, risk management, and compliance processes that mightimpede progress instead of taking the opportunity to explore modern techniques and negotiatetheir use. Not enhancing the platform quickly enough to meet the needs of groups with short deliverycycles. This might force them to look for other ways of bypassing the platform to achieve theirdelivery goals. Failing to develop a financial thesis that underpins the platform. Lacking this planning fails toaddress questions like: how will business results be different? How will the customer experiencebe altered? By when? Instead, prioritizing alignment on these types of critical questions willhelp business and technology leaders better understand how the platform will support betterbusiness results. Undercommunicating small wins along the way. Failing to acknowledge these milestones undermines the importance of measuring and communicating early successes connected to the platform, thereby missing opportunities to win over the cynics and skeptics.redhat.comE-book A platform ecosystem as a catalyst for transformation9
Developing the platform as a productA platform must be treated as a product from Day 1. A product takes the experience of the consumers into consideration. It is guided by measurements and data. Like any other product, the platformwill have a roadmap of desired functionality that has to be managed by a product manager. Theroadmap has to be managed in a way that will maintain satisfaction with existing platform consumers,while simultaneously attracting new consumers.A number of the common missteps described above come from not recognizing the need for theplatform to be viewed as a product. Figure 2 shows some of the stages an enterprise can go throughbefore realizing the need to treat the platform as a product.A typical 18 months to three-year platform journeyBuy andoperateMake smallcustomizationsStart viewing theplatform as a productFigure 2. Typical stages in the journey to discovering the platform as a productThe platform must have a long-lived and sustainable funding model, similar to the way a productmust have a revenue stream to remain viable to produce. The rate at which the platform roadmap canbe addressed is intimately coupled to the platform funding.Product managers carefully consider competition. The competition for an internal digital platformoften includes Platform-as-a-Service (PaaS) offerings from hyperscale technology companies aswell as competing internal platforms.Functions of the platform teamThe most basic function of the platform team is operating the platform and ensuring reliability. No matter how compelling the platform is, if it is not reliable, consumers will leave the platform.Accountability between the platform team and the consumers of the platform—as well as the internalgroups providing networking, systems, and storage support to the platform team—is a cornerstone ofmeeting the true spirit of SLOs.However, the role of the platform team must go beyond platform operation. The focus on the platform consumers is an integral part of treating the platform as a product and defines the platformteam’s activities. The overarching goal of the platform team is to create a sustained purpose forthe platform while fostering a symbiotic relationship with the community at large. Connecting thatpurpose to specific business opportunities is essential to sustainability and traceability back to theplatform’s central purpose.redhat.comE-book A platform ecosystem as a catalyst for transformation10
The concerns of the platform team include: Product and feature development, especially as it relates to the developer experience.The product team should prioritize development of assets meant to streamline the path to production for projects on the platform, as well as striving to make development groups productiveas soon as possible. Additionally, the operational experience should be standardized across projects on the platform to reduce the burden on both operations and development. The platformteam needs to prioritize the product roadmap of the platform, balancing the needs of existingconsumers alongside gaps in functionality that might be preventing new teams from moving tothe platform.Measured by: Net promoter score (NPS) and return on investments Outreach, onboarding, mentoring, and facilitation. Often overlooked, providing outreachto consuming teams is a critical function for attracting new groups to the platform. The insightgleaned when helping new teams move their projects to the platform is extremely valuable.Understanding what new consumers want to accomplish and what they experience can help theplatform team build a better product. Working alongside consumers allows the platform team tonot only obtain first-hand knowledge but also builds trust that might have been lacking across historical development and operational groups.Measured by: Team adoption by business segment, organizational group, and type of team Community building. Building a community of platform
Transforming an organization requires a continuous process of adopting new ways of working and a culture of experimentation in addition to new technologies. 2 A culture that fosters rapid experimentation has the ability to arrive at better out-comes. Encouraging this dynamic leads to continuous
