Software Risk Driven Application Development

Understanding Software Risks Created by Poor Application Development and Release Practices

While the conditions that drive software project managers, development teams and their leadership are often in the best interest of the company, they sometimes fail to recognize the software risks introduced to the business by these decisions or behaviors.  A review of the latest software risks affecting businesses illustrates that development organizations are notoriously poor at managing software development processes such as releases and evolutions.

One cause is that organizations lack standard software lifecycle management processes.  Each company creates its own process, tools, and strategies, resulting in custom, unique practices that are not repeatable and prevent industrialization. This creates many issues, as software systems grow in complexity and components within a software stack evolve over time.  These common changes are difficult to identify or forecast within large, complex and poorly managed stacks.  For instance, changes which most of us have experienced include; port platform from 32-bit to 64-bit, moving from Windows to Linux, updating frameworks, upgrading development languages/environments/run-time libraries and these days, the commonly discussed topic of moving development or production environments and platforms to the cloud.

Further, a major side effect of any evolution is the potential effect it has on the business. The results or output generated with the new or evolved software/system may be different compared to the legacy platform. Such evolutions might affect business performance, user experience or cause unexpected behaviors.

When managing the software lifecycle, most processes do not take into account the risks and impact of changes on the product platform and the generated output. The existing process and tools are not good enough to manage and explain the product upgrades and evolutions.  To address such concerns, organizations must define a plan of action:

• Perform a system-level analysis to study the complete software/stack.
  • System-level analysis provides a holistic view that can identify elements, technologies, or components that could evolve over time. "Evolve" means changes in the environment (e.g., upgrades, obsolete technology, vendor policy changes) which could have a side effect,such as unexpected hardware usage, security violations, slow performance...all of which may have an negative impact on the business.
• Define a process to manage the upgrade and modification/update/change of these elements in the software stack to minimize the impact on to the business.
• Automate the process to reduce operation costs and the cost of managing evolutions.
• Provide means/tools to end-users to visualize the evolutions between legacy deployments and the new system. At the same time, also provide tools to understand the impact of the evolution on their work and/or business.

This approach insures a sustainable, overall understanding and experience with software systems, the dimensions (Technology, Language, Platform, Domain, Market Trend) and their derivatives (Web Services, Cloud computing, Frameworks, etc.).  The relevance tree below illustrates an example of the influence software evolutions:

Knowing how IT and businesses have evolved over time, you can expect additional dimensions over a period of time, which will result in new derivatives. There are several approaches to track the changes or the evolution in a software stack including measuring their impact on different business criteria such as performance, security, robustness, maintainability and more.

You could use static code analyzers (SCA) or system-level analysis solutions to give you a complete view on the structure changes of the systems. The tool provides a high-level dashboard presenting the impact of these structural evolutions on various aspects, such as Sizing (via Function Point), Architecture (dependencies across various tiers, security flaws), Product Standards (e.g. Defined by OWASP/CWE, CISQ) and Quality (based on performance, security, changeability, maintainability, transferability and robustness).

I would like to hear from you on best practices or processes/tools you have used to manage evolutions in your software stack/platform/systems. Please write to me in the comments below.