Traditionally, one of the most vital aspects of application development is defining and following a strict and proven Software Development Life Cycle (SDLC). In many new organizations and SMBs, this process is often ad-hoc (un- or under-defined), ignored (little to no buy-in) or a too-generalized industry solution that doesn’t fit the culture or business driven processes of the organization. In larger organizations the SDLC may be strictly followed but overly bureaucratic and result in excessive bottlenecks, delaying the ability to deliver projects in reasonable timeframes. The correct SDLC should be decided for your organization with buy-in from all stakeholders, including Engineering, QA, IT, Product Design, and of course the Product Owner or Client (within reason!) All who are involved in the process should believe in its ability as a framework to deliver timely and successful projects and applications, and more importantly, the SDLC should prove this consistently.
A typical SDLC involves:
- Planning – Product/Business Owners define a problem or new idea to bring to market. Product Design, UX Design, Wireframes, Mock-Ups and requirement documents are put together.
- Development – Once Product and Engineering agree on a timeline, set of features and priority, a delivery schedule and have worked out any ambiguities in the requirements, the engineers can now break ground (code).
- Integration (and code merge) – With multiple developers working on common code libraries, you must have an integration environment to ensure that everyone's changes play nice together in the sandbox.
- Testing – Unit Testing, Systems Testing, Regression Testing, etc. This step is critical to ensure quality. Rushing this step along is highly discouraged in order to avoid embarrassment upon delivery. How about an historical reminder why?
- Deployment – Deployments are performed throughout the life cycle progressing from development, integration, QA, staging or UAT, and finally Production. Deployment also requires configuration management as well as potential data migration efforts.
- On-Going Maintenance – Following all of these steps ensure a quality product, but nothing is perfect. An SDLC must be followed for maintenance releases as well as new project development.
PaaS, or Platform as a Service, automates aspects of this process and can cut down the time between phases drastically. No more are Software Engineers reliant on IT to procure environments and Release and Configuration Managers to deploy and configure the software. No more are the Engineers reinventing wheels and integrating a wide array of third party technologies to solve common problems as they can make use of the Platform’s packaged solutions offered as a Service. No more are IT departments forced to maintain licenses for frameworks, databases, and third party libraries necessary on each environment’s servers to execute the software. With the advent of Virtual Machines, IT no longer has to secure, purchase and then maintain physical infrastructure for each environment necessary to support the software life cycle.
However, VMs solved only half the battle. They still require maintenance, configuration, patching, virus protection and other forms of systems administration and compliance. With PaaS, many of these concerns only come up during a “Remember When” discussion over drinks. Does this mean these steps in the SDLC are no more?
PaaS offers all integration and testing environments through a push-button, multi-tenant infrastructure approach. Developers themselves are now empowered with tools to spin up environments as soon as their software is ready to check-in. But is this the right approach? As technology progresses and once-cumbersome tasks become automated, it can have an adverse effect on governance. These tools make our lives easier and do speed up development, but they do not remove the need for a proper cycle to be followed by all parties involved.
The SDLC is a strict framework for software departments and their stakeholders, but it is an organic process to define and continuously refine it. At a minimum, an SDLC should be revisited yearly by all parties. It is also recommended to bring in outside consultants who can provide a window into what generally works in other organizations of your type and in your vertical. As they do not have emotional investment in how things currently are, they can offer a fresh perspective and help you formulate a process that fits. This allows the SDLC to remain relevant with changes in technology, staff, business-drivers and philosophies. As soon as following an SDLC results in an unsuccessful project delivery, the adoption of it as a guide will flounder and it must be revisited before the next project starts. A post-mortem discussion is not always going to result in identifying “who dropped the ball.” Sometimes it will reveal an out-of-date or weak SDLC.
- Planning - Utilizing PaaS solutions still must be done effectively and result in clear and concise requirements. Fast-to-Market does not change this.
- Development – Code still must be developed. PaaS does not “do this for you!” This phase still requires requirements and discovery along with approval processes on specifications.
- Integration (and code merge) – This is still very important when you have more than one developer modifying code. This should be the environment from which you deploy to your cloud-based PaaS, not from a developer’s IDE.
- Testing – Nothing changes here. Technology can make testing easier, it will not make it unnecessary.
- Deployment – Under PaaS, this phase may be shorter and automated, but it still must be governed. While a developer can deploy their own code through an IDE add-on provided by the service provider, they should avoid this. Changes to the code should be deployed to a local, integration environment. It should be unit tested and confirmed before it is uploaded to a PaaS-provided sandbox for QA to begin testing. Release Management overhead is lessened, but it still exists to coordinate the release to your integration environment. While configuration and maintenance of the server is no longer necessary in many cases for IT, configuration is STILL necessary. It simply moves earlier on in the process.
- On-Going Maintenance – PaaS-sourced applications have maintenance releases too!
These standards can be followed regardless of the methodology your company employs. Be it Waterfall, Agile (SCRUM or otherwise), Test Driven Development, Design Driven Development, etc., the process will incorporate each of the provided phases mapped to their appropriate positions. With the collaboration and weigh-in of all your stakeholders and the assistance of consultants, your SDLC will support projects or sprints with repeatable success.
A bad life cycle is still a bad life cycle whether you're developing in a traditional environment in-house, or leveraging Platform as a Service. Management must be conscious of this and not be blinded by misconceptions of what PaaS providers offer. The result can not only be embarrassment over the lack of quality of your products resulting in loss of faith by your customers, but a highly demoralized staff asked to perform miracles with an unstructured development process. This fast-growing industry is very exciting and quickly proving to become the future of application development and emerging DevOps, and it is up to you to stay calm and succeed.
-CJ Kadakia, Director, Cloud Advisory Services – Applications Strategist
Post Date: 04/04/2014