Application Lifecycle Management and Information Governance - the convenience of cohabitation or until death do us part?

Bryn Bowen, Principal, Greenheart Consulting Partners LLC
424
695
148

Bryn Bowen, Principal, Greenheart Consulting Partners LLC

It’s a standard notion that governance should be the framework of the software development lifecycle (“SDLC”), yet there are challenges in maintaining the required discipline to make this happen effectively. We will take a look at some of the common precepts of the Application Development Lifecycle (“ALM”) and data governance principles and demonstrate how their enduring relationship can be used to build better applications.

Technology leaders are caught in the infinite loop of trying to effectively manage the desired functionality of the application under development while ensuring that business policy and risk management considerations are well integrated. In addition, the evolving compliance landscape must be considered, depending on the industry and type of organization, with HIPAA, SOX, SEC Rule 17a all being key contributors to this tension with core business drivers. Given this landscape, it would seem appropriate that a solid governance approach would not only be desirable, but necessary in order to maintain coherence in software development.

What does governance mean in this context? Governance encompasses the initial scoping and business requirements, application design, deployment, versioning, operational maintenance and ultimately, the end of life of the application. Practically, it underpins the decision-making and project management processes to ensure that the application is fulfilling its mission in providing what the business needs. As defined in ALM, the purpose of governance is to make sure the application is responsive to the business needs, while maintaining data integrity, security, accessibility and efficiency. As such, governance is the ever-present aspect of the ALM, the only thing that extends throughout the entire ALM time span. In many ways, it’s the most

Additionally, the tools used in ALM must function across diverse platforms to support all phases of the lifecycle, from requirements through to deployment and maintenance. Traceability must be integrated to the extent that changes in requirements trigger alerts or notifications of the impact of those changes. The SDLC demands choosing the right range of features for your development scenario and keeping the lines of communication open across cross functional teams, while maintaining control over the development lifecycle with a view towards rapid release management.

So what does this all have to do with data governance? Consider that applications developed for business use mainly ingest, store and make information available for use, and as such, the way data is managed, used and governed becomes a key consideration in the SDLC and ultimately, over time, for the ALM. So now we have an expansion of our original thoughts about governance – not only for the application and its use, but also for the data utilized within the application. Even though there may be a tension between the “needs” of the application and the “needs” of the data contained within, both needs are integral to successful and complete application development. As an example of what happens when both are not part of the solution, let’s look at email systems, which have been around for over 20 years and yet the problem of effectively managing the volume of emails remains one of the enduring issues of our time! If only these applications had integrated tools to properly manage the data beast unleashed by them. These types of applications have been so successful and have generated so much data largely because they are effective communication tools. As Twitter and other popular communication platforms are also proving, maintaining and improving functionality are but among many other factors in the SDLC and the accompanying ALM governance process.

According to Gartner, over 70% of the data in an enterprise is redundant, outdated and trivial (“ROT”) and from the risk perspective, effectively acts as data “cholesterol” by clogging the information bloodstream and exposing the organization to unnecessary risk from over-retention and improper preservation of material subject to legal hold. And this is not even considering the additional technology and storage that must be brought on line to service this unnecessary evil. Added to this, the utility and value of the data are also reduced due to inadequate and inefficient search and retrieval protocols, because the data itself is largely ROT.

While ongoing management of data within the application is the clear and present issue, particular consideration must be given to what happens at the end of the application lifecycle. This occurs when the functionality of the application no longer effectively reflects the business, triggering the need for decommissioning of the application and proper disposition of the data within.

Planning the demise of the application and its data from the outset of development lays out a path for how to let software die a clean, uncomplicated death, and is an expression of true governance. This is similar to the retention/disposition of data question that bedevils every enterprise – why didn’t we configure and store data in a way that would allow us to expire it cleanly?

Till death do us part - It takes a special focus to consider end of life scenarios when developing and deploying applications, but as experience has shown, we ignore this step at our own peril. Maybe we ought to call it Application Deathcycle Management?

Read Also

Modernizing a Company's Digital Core

Randy Meyer, VP & GM, Mission Critical Solutions, HPE Servers, Hewlett Packard Enterprise