There are many methods, supporting tools, training and mentoring sources, infrastructure platforms, organizational structures and adoption methods for Solution Delivery and Lifecycle Management (SDLC). Most of these focus on the process and activities involved in taking an idea and turning in into a product or solution that has desirable value. The methods define the roles, responsibilities and the work products they deliver as part of the overall solution. Methods like Waterfall, Rational Unified Process, Agile, Scrum provide excellent guidance, and are well known and well practiced. While all of these SDLC methods address many of the same concerns, they do so from different perspectives, using different time horizons, and different supporting tools. The characteristics of the project domain, client preferences, level of risk, requirements stability, etc. contribute to deterring which method to employ.
Current literature, courses, and blogs tend to be narrow and deep about a particular method, describing the details of the method, and the guiding principles for practicing the method. The Eclipse Process Framework has been used to formalize these methods and publish them in a tool that makes them accessible to practitioners.
This blog will be looking at SDLC methods and tools, but perhaps from a different perspective. We’ll be exploring SDLC facets from a more broad and shallow viewpoint, exploring the relationships between the various facets, how work products are shared and integrated across lifecycle phases, and the challenges and mitigating best practices and tools that address these challenges.
The approach I’m going to take is based on lean principles and the concept of Value Stream Mapping. The idea is to think of SDLC as a set of services that establish a value chain connecting the demand and supply side views and stakeholders. Each facet of SDLC provides services that have goals, needs and expectations of the consumed resources, and value propositions, capabilities and commitments for the provided resources in the value stream. The value stream map connects compatible consumers and providers to maximize the exchanged value, and minimize waste and costs. This will be covered in more detail in a particular blog post.
The goal is to provide a more holistic view of SDLC, that is somewhat method independent so it can apply to Waterfall, RUP or Agile, and to insure the parts fit together. What we often see on client engagements is that a particular department will focus on one aspect of SDLC, say testing. They will go narrow and deep in testing to get the best of breed tools and most effective methods. But then when this new testing initiative is deployed, its sometimes the case that it doesn’t fit well with the rest of the development process. That is, testing information might not be easily integrated or shared with other SDLC activities and tools, it might not be sufficiently connected to the requirements management activities, the build process may have a negative impact on what can be tested where, or how the results of the build are deployed to provisioned test platforms may be a gap.
Hopefully by taking a broader view of SDLC, we can balance local optimization of particular SDLC facets and activities against their broader impact on the overall solution delivery business outcomes.