A critical role in successful Agile development is that of the product owner, who describes and prioritizes requirements, and adds them via user stories in the product backlog. The product backlog is then consumed by the development team during sprints.
A common misconception is that application rationalization, as well as architecture, are not required as the product continuously evolves with the DevOps team. The problem is that DevOps teams are at risk of developing applications that are poorly architected, which simultaneously causes an increase in technical debt from one sprint to another.
A big difference exists between born digital companies and large traditional companies. Born digital companies have native agility because of their short existence, and in most cases developers work within the same platform in the cloud. On the other hand, large traditional companies have to deal with redundant applications stemming from previous mergers & acquisitions and/or unmanaged growth that results in additional complexity and a lack of flexibility of their IT landscape. These companies are swamped with thousands of applications used throughout different business units, and in all of their products and services - and these applications rely on a massive number of technologies. For large traditional companies, it is a much bigger challenge to implement successful DevOps programs and get everyone on the same page.
To embrace Agile development methods, it is recommended that you combine an application portfolio management (APM) practice that helps IT departments map, streamline and transform their application portfolio, while providing them with a better visibility into their IT landscape.
To get started with APM, take an inventory of the IT landscape by crowdsourcing information that uses criteria relevant to the organization - and pay particular attention to each application’s functionality, as well as how each application supports business activities (including business processes and business capabilities). To get even more value, you can list all the technologies supporting your applications to better anticipate and monitor obsolescence.
Next, assess applications from different perspectives, such as cost, business value and risk, to help streamline the application landscape. This evaluation enables you to decide which assets to invest in, tolerate, migrate, or phase out. Understanding application lifecycles also helps plan changes to the application portfolio. For example, if an application is planned to be retired, you can identify dependencies and the impact on the business, and coordinate its replacement.
Defining transformation scenarios based on a mix of projects/initiatives is the last step. By comparing these scenarios through various criteria such as risk on quality, risk of feasibility, and costs, you ensure the right decisions are made based on your company’s appetite for change, and then implement the best transformation scenario based on desired business outcomes.
If DevOps and Agile development help companies to reduce their time-to-market, it should not be at the expense of software development quality. By adopting an APM approach, you can architect DevOps projects to improve overall quality and reliability. You can also realign IT transformation projects with business goals by connecting company strategy directly to application portfolio planning using business capability maps. Finally, by rationalizing the application portfolio, companies also significantly reduce costs while getting rid of redundant and obsolete applications.
To learn more about how to plan IT transformation in the digital age, check out our ebook :"Plan IT Transformation in the Digital Age".