devopsy.kinsta.cloud

Category: Continuous Delivery

Continuous delivery is a software engineering discipline that allows organizations to consistently develop and release quality software at a rapid pace. It is achieved by automating the software development lifecycle, enabling tasks such as development, testing and release to occur concurrently and continuously.

  • Netlify Makes Build Plugins Available for Jamstack Platform

    Netlify Makes Build Plugins Available for Jamstack Platform

    Netlify, at a Jamstack Conf Virtual event, announced the general availability of open source Netlify Build Plugins that provide IT teams with a set of continuous integration/continuous delivery (CI/CD) workflows for building websites and web applications using JavaScript, application programming interfaces (APIs) and static HTML files without employing web servers, otherwise known as a Jamstack.

    Designed to be launched from within a Netlify platform to enable IT teams to build a website and launch it from a Git repository to a content delivery network (CDN), the Netlify Build Plugins are intended to make it easier to employ DevOps processes using, for example, a plugin to run an end-to-end Cypress test.

    Netlify CEO Mathias Biilmann said DevOps teams also can make use of a Netlify API to create their own plugins. Ultimately, the goal is to foster the development of a wide range of open source Netlify plugins that would be built and vetted by the Jamstack community, he said.

    Other Netlify Build Plugins provide a means to enable Ghost, an open source headless content management system based on Node.js that can be deployed on any framework; launch a Sentry tool to automatically discover, triage and prioritize bugs; or enable a Gatsby tool to create incremental builds on Netlify.

    A survey of more than 3,000 Jamstack developers published today by Netlify finds one-third have worked on sites serving millions of users over the last year. Nearly two-thirds of survey respondents (62%) work outside the tech industry, including advertising and marketing (21%), media and publishing (14%), education (14%), financial services (13%) and business support and logistics (13%). Well over a third (38%) work for a technology company. About a quarter (26%) have more than 10 years of experience.

    Top Jamstack benefits cited by all types of developers are performance, uptime, speed of development, security, compliance and avoiding vendor lock-in, the survey finds.

    Biilmann said Jamstack as a philosophy enables IT teams to separate the development of front- and backend websites and applications in a way that allows organizations to embrace best DevOps processes. That approach is agnostic as far as any specific JavaScript framework is concerned, but it does define a way to automate the build process for a web application or website.

    In the wake of the economic downturn brought on by the COVID-19 pandemic, more organizations are investing time and resources in modernizing their websites and applications. With more employees and end users depending on those websites to drive digital business processes, the quality of the application experience has become a much bigger concern. At the same time, end users have now come to expect those application experiences to be updated regularly, which in many cases will necessitate the adoption of best DevOps processes.

    In fact, it’s arguable that organizations that don’t embrace best DevOps practices to build and deliver web applications at scale will soon discover they have bitten off more than they can chew.

  • CloudBees Extends SDM Service Reach

    CloudBees Extends SDM Service Reach

    CloudBees has extended the integrations embedded within its software delivery management (SDM) platform to add support for additional services provided by Google.

    Moritz Plassnig, senior vice president cloud and general manager for SDM at CloudBees, said these integrations with Google Cloud Build and Tekton pipelines are being provided as part of a long-standing alliance between the two companies to advance the adoption of best DevOps practices. The CloudBees SDM service runs on the Google Cloud Platform (GCP).

    As part of that effort, CloudBees has been making investments in an SDM platform that enables DevOps teams to pull metrics from any tool or platform. That data is then fed into an analytics cloud service through which CloudBees surfaces insights that identify, for example, how delays to a project might impact overall revenue goals.

    Interest in software delivery analytics has risen in the wake of the COVID-19 pandemic as organizations accelerate the building and deploying of digital business applications, said Plassnig. With employees and customers alike working from home to combat the pandemic, organizations are investing more in creating applications that provide digital alternatives to engaging end users, he noted, adding delays to any of those projects are likely to have a much bigger impact on business continuity strategies today than they did just a few short months ago.

    The CloudBees SDM service provides DevOps teams and business managers alike a real-time view of all product and feature development occurring across the organization, as well as a policy engine to trigger actions to better optimize the software delivery process. Organizations can also model and visualize the software delivery process while measuring overall DevOps performance.

    Rather than requiring organizations to standardize on a single platform to achieve that goal, Plassnig said CloudBees is leveraging application programming interfaces (APIs) to integrate metrics across a broad range of DevOps tools. That approach, he said, makes it possible to meet organizations wherever they are in terms of DevOps maturity.

    Support for Tekton pipelines is significant, Plassnig noted, because it’s expected that most continuous integration/continuous delivery (CI/CD) platforms in the future will be built using Tekton pipelines, which provide an open source framework for building platforms that are designed to be deployed on Kubernetes clusters. Jenkins X, originally developed by CloudBees, is one of the first CI/CD platforms to support Tekton pipelines, which were originally developed by Google. Jenkins X and Tekton pipelines are now being advanced under the auspices of the Continuous Delivery Foundation, an arm of the Linux Foundation.

    As more CI/CD platforms embrace Tekton, the platforms themselves will become less of a black box from an analytics perspective, noted Plassnig.

    In the meantime, CloudBees also expects Google to continue to gain momentum as a cloud service provider, he said. While Google trails Amazon Web Services (AWS) and Microsoft in terms of overall market share by a wide margin, Plassnig noted that with the arrival of Anthos, a cloud operating system capable of being deployed on multiple cloud and on-premises IT environments, it’s only a matter of time before services such as Google Cloud Build are employed more widely.

    Whatever the platform used, the one thing for certain is the rate at which software is being generated and deployed on various platforms will be watched much more closely.

  • Report Finds Much Room for CD Improvement

    Report Finds Much Room for CD Improvement

    A report published by Harness, a provider of continuous delivery (CD) platform accessed via the cloud, finds organizations are spending on average $109,0000 per year just to deploy per application.

    Based on a survey of more than 100 organizations, the report finds organizations are struggling with deployment frequency, lead time and meantime to recover after a failed release.

    On average, organizations are deploying code to production every four days, which takes about eight hours to complete, according to the report. An average of 11% of those deployments fail and those failures take an average of 60 minutes to manually roll back.

    Steve Burton, CMO at Harness, said that while a lot of progress has been made in recent years in terms of implementing continuous integration (CI), the continuous delivery (CD) side of the DevOps equation remains challenging. Each platform an application gets deployed on is a unique “snowflake” that requires organizations to rely on custom scripts to deploy an application. The report finds deployment pipelines are expensive to create and maintain, requiring two to three dedicated full-time employees and up to 66 hours to onboard a new application. New artifacts on average took 5.5 hours to reach production and then 10 hours per deployment.

    Harness has been making a case for a dedicated CD platform that is accessed as a software-as-a-service (SaaS) platform. That approach provides a way to automate application delivery in a way that more easily complements the variety of tools and platforms organizations rely on to build applications, he said.

    The Harness report finds 71% of respondents employ the Jenkins CI/CD platform. Other popular tools and platforms include Jira project management software (76%), Selenium for testing (63%) and Amazon Web Services (AWS) for cloud deployment (65%). While Jenkins can be employed to deliver applications, Burton said the survey results make it clear there’s not been a lot of progress when it comes to CD.

    It’s too early to say to what degree changing economic conditions brought on by the COVID-19 pandemic might encourage IT organizations to rethink their approach to DevOps. Organizations are undoubtedly going to be more sensitive to cost. Much of the cost involved in DevOps comes from first standing up and maintaining the DevOps environment and then hiring IT professionals with DevOps skills to manage it. A SaaS platform, in contrast, is maintained by the provider, comes with built-in analytics tools, enables automatic rollbacks and is paid for on a consumption basis, notes Burton.

    No one knows for sure at what rate organizations might be rolling out new applications in the months ahead. While some may choose to pull back, others are advancing various digital business initiatives as part of an effort to become more resilient. In many cases, that means replacing many legacy applications with fewer modern applications that run natively in the cloud.
    Regardless of the path forward, the one thing that is certain is the level of scrutiny being applied to DevOps efficiency is about to substantially increase.

  • How SDM’s Holistic Approach Connects Organizations and Streamlines Delivery Processes

    How SDM’s Holistic Approach Connects Organizations and Streamlines Delivery Processes

    Since Jez Humble and David Farley popularized the term in 2010, continuous delivery has revolutionized software delivery practices. 

    Creating mature continuous integration/continuous delivery (CI/CD) pipelines has helped enterprises deliver software that performs better, based on a long list of metrics. Failure rates have dropped from 50% to under 15%, and cycle times are measured in hours, not weeks. Organizations get to market faster and release products into production with fewer bugs.

    But, there’s a limit to what CI/CD can provide. CI/CD connects only the parts of the software lifecycle that happen inside DevOps. It doesn’t provide insights into where the delivery cycle is breaking down, whether the software is helping the business meet its internal key performance indicators (KPIs), how customers are responding to it or whether last week’s release is achieving the internal efficiencies the business was projecting.

    A More Holistic Approach

    This is where a more holistic approach to software delivery can help. As we discussed in a previous blog, there’s a move afoot to recognize software delivery as more of a core business process and connect all the aspects of this process in one new, interconnected discipline. 

    The new discipline, called software delivery management (SDM), changes the game by going beyond CI/CD and empowering developers and other stakeholders to best collaborate and creatively solve problems. It gives them the data, insights and best practices that allow them to truly continuously improve, keep value flowing and efficiently develop and deliver the right products and features to customers.

    To follow SDM principles, a management solution needs to rest upon four key pillars: common data, universal insights, common connected processes and having all functions collaborating.

    • Data: All information within and around software delivery activity would need to be captured and stored with a consistent domain model to enable and facilitate connected processes, shared insights and collaboration.
    • Insights: Visibility and insights would need to enable a common understanding and continuous learning from data across, up-and-down and throughout all functions in the organization.
    • Processes: Processes would need to orchestrate the entirety of the software delivery value stream and connect functions together to efficiently bring ideas to market with maximum value and adoption.
    • Collaboration: All functions and teams within and around the software delivery organization would consequently work together to amplify value creation efforts.

    This holistic approach helps organizations in a number of ways. Here are three benefits DevOps managers can net in terms of the way they work, collaborate with development teams and connect with peers throughout their organizations.

    Faster Development

    The current process can be slow and tedious. Developers use tools configured to perform one task, and getting a complete end-to-end view across the toolchain is difficult. An SDM solution stores all the artifacts and data from disparate tools that move software from idea to deployment in a unified common data layer. The information is connected and available for those who need it, when they need it and in a form they can use. Just forging these connections will save hours of time looking for data, checking statuses and tracking issues throughout the delivery process. 

    Better Software

    If stakeholders have no end-to-end view of the development and delivery process, they have no way of knowing if the software is meeting the organization’s business objectives. With SDM, the continuous feedback loop established with CI/CD and DevOps is extended to fully include all stakeholders from the ideation phase through user adoption and back to ideation. Better insights are tracked more closely and shared more widely, helping developers do a better job of delivering what the users want.

    Better Collaboration

    Developers and business leaders don’t collaborate well for a number of reasons. Developers often don’t have a good feel for how a product is going to be used, and business leaders usually don’t have insight into what’s in development or when it will be delivered. This is complicated by scattershot communications processes–where both sides have to sort through spreadsheets, connect over email threads and wait for meetings to move processes forward. With SDM, the silos between the software organization and other stakeholders are broken down, so both sides can share information, communicate more directly and drive toward solutions. 

    In an upcoming blog, we’ll explore other examples of SDM in action and dive into the business value it creates for organizations.

  • CD Foundation Serves Up Tekton Pipelines Beta

    CD Foundation Serves Up Tekton Pipelines Beta

    The team overseeing the development of the open source Tekton Pipelines under the auspices of the Continuous Delivery (CD) Foundation announced today the project is now in beta.

    Christie Wilson, Tekton Project Lead and a software engineer at Google, said Tekton Pipelines are not necessarily a tool most DevOps teams will interact with directly. Rather they provide a foundation on which DevOps platforms can be built that will make it easier for DevOps teams to construct workflows spanning multiple continuous integration/continuous delivery (CI/CD) platforms.

    As such, Tekton Pipelines should play a critical role in not just fostering interoperability but also alleviating concerns about become locked into a specific CI/CD platform.

    The beta release of Tekton Pipelines is significant because it signals that the project is now stable enough to be incorporated in DevOps platforms and from here on will follow the same deprecation policies as Kubernetes in terms of supporting previous releases. However, Wilson noted that Tekton Triggers, Tekton Dashboard, Tekton Pipelines CLI and other components are still alpha and as such may evolve from release to release in a way that is not necessarily backward-compatible just yet.

    In the meantime, the Tekton Pipeline team is encouraging all Tekton projects and users to migrate their integrations to the latest version of Custom Resource Definition (CRD), which is the application programming interface (API) supplied. The Tekton Pipeline team is also making available a migration guide.

    The Tekton Pipelines project is one of several initiatives being advanced under the guidance of the CD Foundation, which is an arm of The Linux Foundation. Other projects include Jenkins and Jenkins X, a pair of open source CI/CD projects developed originally by CloudBees and Spinnaker, a CD platform originally created by Netflix. Tekton Pipelines are a framework that runs natively on Kubernetes that traces its lineage back to Google.

    Premier members for the CD Foundation include CloudBees, Google, Circle CI, JFrog, IBM, CapitalOne, Salesforce and Netflix. Other members of the CD Foundation include GitLab, Red Hat, Harness and Rancher Labs.

    Wilson said Jenkins X already supports Tekton Pipelines, while work involving Spinnaker is ongoing. It’s not expected that Jenkins, currently the most widely used CI/CD platform, will be able to employ Tekton Pipelines, said Wilson.

    It’s not clear when Tekton Pipelines might be pervasively employed across multiple CI/CD platforms. In theory, as more applications are built on top of Kubernetes, the use of CI/CD platforms that run natively on Kubernetes should increase. However, most organizations that have already adopted a CI/CD platform such as Jenkins are continuing to use the same platform to build and deploy both monolithic and microservices-based applications. At some point, however, it’s expected those organizations will eventually migrate to a CI/CD platform that runs natively on Kubernetes. In many cases, different teams within the same organization may opt to standardize on different CI/CD platforms while still be able to share workflows, said Wilson.

    Naturally, providers of DevOps platforms are already jockeying for position now that the race to support Tekton Pipelines as specified by the CD Foundation has formally started.

    — Mike Vizard

  • GitLab Shifts 18 Features Into Core Open Source Platform

    GitLab Shifts 18 Features Into Core Open Source Platform

    GitLab this week announced it has moved 18 features that previously organizations had to pay for into the core open source version of its namesake continuous integration/continuous delivery (CI/CD) platform.

    Scott Williamson, executive vice president of product management for GitLab, said as a general rule the company makes available DevOps tools for teams across the four tiers of services that organizations can employ. Features now being migrated to the Core offering include:

    Plan: Synchronize collaboration with “related issues,” “export issues,” “issues board focus mode” and “Service Desk”

    Create: Build better code and branch with the “web terminal for WebIDE,” “file syncing to web terminal” and “design management”

    Verify: Improve code quality with reports on merge requests

    Package: Build and share more efficiently with a set of package managers in one place

    Release: Continuous delivery simplified with “canary deployments,” “incremental rollout,” “feature flags” and “deploy boards”

    Configure: Support for multiple Kubernetes clusters to ease deployment of different environments

    Defend: Bolster application security with network policies for container network security

    As the global economy falters in the wake of the COVID-19 pandemic, it’s likely reliance on open source software will increase. Most organizations would rather throw IT labor at the ongoing management of an IT environment to manage open source software versus having to lay off IT employees that would be extremely difficult to find once the economy recovers. It remains to be seen to what degree that strategy will play out in DevOps environments, but Williamson said historically most of GitLab’s customers are organizations that first adopt the open source version of its platform.

    Less clear is the degree to which the downturn might also induce many of the organizations to employ a DevOps platform delivered as a set of software-as-a-service (SaaS) applications. GitLab has been for the past several years for an integrated approach to DevOps based on a single code base that is ultimately easier to deploy and manage. Many IT organizations may decide that rather than manage DevOps infrastructure, they now prefer to allocate what limited resources they have on hand to writing code.

    The number of application development projects being launched could also decline while others are suspended. At the same time, however, there are some vertical industry segments, such as digital entertainment and education services, that might see a spike in demand for additional services now that many people are staying home to help limit the scope of the COVID-19 pandemic.

    Of course, many DevOps teams are among the legions of workers that now need to remotely access platforms. Williamson said supporting remote DevOps teams has long been a strength of the GitLab platform. GitLab also makes available a playbook that provides DevOps teams with guidance on how best to work remotely.

    Clearly, it will be a few months before the full impact of the COVID-19 pandemic is fully appreciated. Regardless, many IT organizations are clearly preparing for the worst of times while continuing to hope for the best outcome possible.

    — Mike Vizard

  • CircleCI Surfaces More DevOps Insights

    CircleCI Surfaces More DevOps Insights

    CircleCI today announced it is making it easier for DevOps teams to determine the amount of resources being consumed by its continuous integration/continuous delivery (CI/CD) platform to help make application development teams more efficient.

    Kunal Jain, senior product manager for CircleCI, said via the application programming interface (API) that CircleCI exposes DevOps teams can now determine, for example, which workflows are taking the longest to run or what tests might be creating bottlenecks into the CI/CD pipeline.

    Armed with that insight DevOps teams can also optimize how credits to employ the CircleCI platform are allocated across their DevOps teams, added Jain. That capability should make it easier for DevOps teams to predict how much they are spending per month to run their CI/CD platform, said Jain. Many more IT organizations may opt to access CI/CD platforms using a software-as-a-service (SaaS) approach that limits the need for them to invest in their own IT infrastructure or in some cases even manage the platform.

    DevOps teams have always been sensitive to efficiency but given the current economic climate, minimizing costs is becoming a higher priority for many organizations. As such, DevOps teams need more insights into, for example, how to best break up workflows to keep CI/CD platform costs to a minimum, said Jain. In fact, Jain says the total cost of operating a CI/CD platform is likely to now play a bigger role in selecting a platform as IT leaders demand more visibility into DevOps processes.

    Of course, some DevOps teams may find themselves competing for credits based on how efficient they are. Teams who are more efficient than others could also allow IT leaders to reallocate credits as they best see fit based on the progress being made. In a previous era where compute resources were largely considered to be a nominal cost, many DevOps teams may find access to IT infrastructure might no longer be taken for granted.

    CircleCI claims it runs more than 30 million independent jobs run every month. The company last year committed to exposing more API endpoints to help DevOps team better understand the languages, architectural patterns, code testing patterns, delivery success rates and team practices being employed. Like most providers of CI/CD platforms, CircleCI has made a commitment to making available a much broader range of actionable insights to DevOps teams via its API.

    At this point, it’s unclear what the impact the economic downturn brought on by the COVID-19 pandemic might have on DevOps adoption. Undoubtedly, many organizations will put a hold on some application development projects as they reassess their priorities. On the other hand, with more people working from home, digital business transformation initiatives that require new applications are likely to become a higher priority as organizations seek to reinvent how they engage their end customers. Those projects may even be accelerated as part of a larger business continuity strategy. Regardless of the number of application development projects being launched, the scrutiny of how IT resources are being allocated and consumed is about to increase substantially.

    — Mike Vizard

  • OverOps Allies With SonarQube To Improve Application Quality

    OverOps Allies With SonarQube To Improve Application Quality

    OverOps, a provider of tools for dynamically analyzing code at runtime, has partnered with SonarQube, a provider of static analysis tools for source code, to enhance application quality by unifying code analytics.

    Chen Harel, vice president of product for OverOps, said the two companies have collaborated to create a plugin through which DevOps teams can now more easily analyze source code before it gets deployed in a production environment.

    The goal is to equip DevOps teams with the tools required to assure application quality as more responsibility for maintaining applications continues to shift left on to the shoulders of developers, said Harel. In the absence of tools to analyze code, he noted, developers are not going to be able to identify, for example, potential vulnerabilities in source code and errors at run-time.

    The plugin also allows issues identified by OverOps at runtime to be fed back into the SonarQube tools for analyzing source code to identify issues that previously would not have been discovered, he added.

    Specifically, when the OverOps plugin is installed, it automatically creates an event rule for Java code based on new, critical, resurfaced and unique runtime errors. When a quality gate fails a release based on these criteria, users can view the issues directly within their SonarQube dashboard. OverOps then provides a direct link to the event analysis containing the full context behind the error, including the stack trace, variable state and system state.

    As a result, Harel said DevOps teams are going to be able to reproduce an issue much faster, which should result in much shorter times to remediation. Without such tools, DevOps teams can spend weeks reproducing an error that only takes a few minutes to actually fix.

    Harel said with both the OverOps and SonarQube tools included as part of the gates set up within a continuous integration/continuous delivery (CI/CD) platform, it becomes possible to substantially improve the overall quality of the applications being developed. That’s critical because developing applications faster often results in more errors having to be addressed, said Harel.

    There’s a lot of debate these days concerning the degree to which the adoption of DevOps might be increasing the total cost of IT. It’s a lot more expensive to fix an application after it’s deployed in a production environment than it is to address issues as they arise in the application development process. As such, there’s a lot more focus on code analytics to help ensure that DevOps processes are churning out not just more code faster but also higher quality applications.

    Of course, the level of DevOps sophistication tends to vary widely by organization. However, as more gates that address application quality assurance are erected on CI/CD platforms, the better the DevOps outcome will become. The challenge is making sure the DevOps culture being fostered prizes application quality as much as it does how much code is being written and deployed how fast.

    — Mike Vizard

  • 2nd Watch Allies With GitLab for Managed DevOps Service

    2nd Watch Allies With GitLab for Managed DevOps Service

    2nd Watch today launched a managed DevOps service based on the continuous integration/continuous deployment (CI/CD) platform from GitLab that it will operate on behalf of customers in addition to coaching them on how to adopt best DevOps practices.

    Stefana Muller, a senior product manager, said the 2nd Watch Managed DevOps service combines the managed and professional services capabilities of 2nd Watch into a single offering. That approach is required because when it comes to DevOps most organizations need as much help transitioning their culture as they will operating their CI/CD environment, she said.

    One of the major challenges organizations face when trying to embrace DevOps is they typically spend a lot of money upfront only to see those efforts flounder when changing the internal culture of the organization becomes too difficult, Muller said. As part of an effort to smooth that transition, 2nd Watch DevOps experts will assess an organization’s readiness to adopt DevOps tools and processes and then train internal teams on DevOps fundamentals such as managing infrastructure as code and Git principles. The assessment is based on a Culture, Automation, Lean Practices, Measurement and Sharing (CALMS) methodology.

    The 2nd Watch service is built around an on-premises edition of the GitLab CI/CD platform that it will host and upgrade on behalf of a customer on either an Amazon Web Services (AWS) or Microsoft public cloud platform. The DevOps service will focus on enabling organizations to build both monolithic and microservices-based applications faster because no organization today has fully transitioned to microservices. The company already provides a managed Kubernetes service for building and deploying applications based on a microservices architecture.

    2nd Watch chose to partner with GitLab because of the completeness of that CI/CD platform, which among other things includes integrated security modules that can be employed to advance DevSecOps practices as well, Muller said, noting that longer-term, 2nd Watch is planning to layer a more robust set of managed DevSecOps services on top of the GitLab platform.

    Managed DevOps offerings are starting to proliferate as the number of services providers that have attained certifications from multiple IT vendors has increased. It’s not clear to what degree organizations will prefer to rely on these services just yet. However, it’s is apparent many organizations are trying to shift as much of their limited resources to building application code versus managing IT infrastructure. It’s also possible that as the COVID-19 coronavirus pandemic becomes more widespread many organizations will need to rely on external service providers to manage their DevOps environments.

    Regardless of the motivation, organizations that are at the beginning of their DevOps journey clearly will need more help than those that are further along the DevOps maturity curve. The decision most organizations will need to make is to what degree will they rely on a managed DevOps service to accelerate their transition versus opting to rely permanently on an external IT service provider to manage one of their most critical IT environments.

    — Mike Vizard

  • Provide Continuous Value with Product-Centric Delivery

    Provide Continuous Value with Product-Centric Delivery

    Software engineering and management has borrowed many practices over the years from traditional industries such as construction, automotive and manufacturing. One such practice is the notion of managing software development and delivery based on projects.

    According to the Project Management Institute (PMI), a project is defined as “a temporary endeavor undertaken to create a unique product, service or result. A project is temporary, in that it has a defined beginning and end in time, and, therefore, defined scope and resources.”

    Many enterprises today manage software delivery via a project-centric software delivery approach. New software projects are identified based on probable business cases. Business opportunities are identified and prioritized based on potential business benefits and estimated cost. This is done with the assumption that the exact market needs, the estimated cost, start and end dates, and potential benefits are certain and known up front. Once the business case is approved by senior management, projects are initiated. In an environment where the scope, schedule and cost of projects can be defined upfront, this provides a predictable approach for software delivery management and governance. 

    But, do we live in a world of total certainty? In the volatile and uncertain world in which we live—with the very fact that software is not a physical good—accurate predictions of market needs, cost, timing and end-user benefits are far from reality. In addition, companies are competing in the marketplace by exploring innovative ways to create and deliver new products and services.

    Why is the project-centric delivery approach used by so many IT organizations if it is a challenge? Projects can no longer be the vehicle for software development and delivery if enterprises want to stay ahead of the competition. Then, what is the alternative approach?

    Introducing the Product-Centric Delivery Model

    A product-centric delivery model is a new way of organizing people, and continuously delivering valuable software to customers.

    Let’s take a look at the steps an enterprise needs to follow in order to transition from project-centric to product-centric software delivery. 

    Identify Products Instead of Projects

    What are software products? Organizations across the world provide value to their customers in the form of goods and services. These goods and services are called products and are often driven by software and IT systems. For example, to a bank that provides digital banking services to its customers, its online banking solution is a product, not a project. Similarly, for a retail company, its catalog and product search becomes a product. These kinds of products are different from the actual physical goods that these companies sell.

    Organize and Fund Stable Teams Around a Product, Not a Project

    Once your products are identified, the next step is to organize and fund your software teams around these products. These cross-functional teams include members from business development, IT development, support and operations. This team must be empowered to build and deliver the product on their own and will collaborate, decide what to build, how to develop it and how to manage the product with frequent updates. The team must be outcome-oriented, long-living and cross-functional. They can be organized as a team-of-teams or squads, resulting in better collaboration, focus and ownership from any corner of the world. This will also help in scaling the overall capacity of the product. A common shared services team, supporting multiple products might be an added advantage. 

    Define Product Vision, Define Objectives, Deliver and Measure Value

    After the products and the teams are in place, you need to define the product vision. The product vision defines the reason for its existence and the long-term goal that it is trying to achieve. This also aligns business objectives with IT delivery and provides guidance for all decisions made regarding the product development and delivery.

    The business stakeholders define the product vision and derive the near-term objectives that will guide the teams to further decide the set of initiatives they need to work on.

    The teams then identify relevant product features, plan and deliver those in short increments or time boxes, thereby delivering continuous value to end users.

    At the end of each time-box, stakeholders will measure the product outcome with the stated objectives and changes in the market needs. The findings will help the business decide on whether to continue investing in the product or not.

    Conclusion

    Product-centric delivery paves a new way of organizing people and continuously delivering software value with more emphasis on outcome rather than the output. It provides a continuous flow of work to the product teams and continuous value to the end users. It aligns the business strategy to software development and execution, while empowering the teams to decide what is best for their product.

    — Prabhu Arumugham