SDLC: Seeing the Forest for the Trees

When I was a Professor, my favorite topic of discussion with students was System Development Life Cycle (SDLC) phases and practices for IT projects.  I enjoyed this discussion because I knew every one of my students; no matter what discipline, no matter what department, would experience this process in their professional life and probably experience it many times.  My consulting career requires that I exercise these principles beyond the ivory towers and manifest methodologies idealized in the classroom.  In my opinion, the SDLC is a label.  It is a label of different phases of Information System development that exist, and they exist no matter which formal development methodology followed.

  • Planning
    • Define the opportunity, think about timelines, and build a team.
  • Analysis
    • Sketch a model of “What is” and “What should be” even if only on a napkin.
  • Design
    • Turn those napkins into physical designs.
  • Development
    • Build rapidly, release, test, and seek feedback. Repeat.
  • Implementation
    • Outline strategies and mitigate risks; Parallel, Pilot, Plunge, Piecemeal, Continuous.
  • Maintenance
    • Continuous improvement go back to planning.

The topic of development methodologies are controversial for some who might feel strongly about specific procedures and best practices.  The controversy and hype might also include monetary considerations.  Some professionals become a “certified” expert on numerous methodologies for management and IT development projects.  This certification bumps your salary or increases bill rates.  With 20 years of consulting experience, I believe the best IT development methodology is home-grown.  It is a development process that works for individuals and with the culture of the organization.  It borrows tenants from many best practices and tailors them to unique environmental considerations.

I have worked in environments where certain methodologies aren’t mere suggestions, they are strictly adhered to entirely.  In these environments, I’ve experienced more dissatisfaction than others who loosely couple certain principles and simply adapt their teams via consensus.  The best teams and projects try principles for periods of time; measure results and satisfaction, and tailor ideals to their project.  Every project and every project team is different, we should not assume what works for one team will work again similarly for another team or project.  Beyond the technology and all the “cool” stuff we build, beyond any ground breaking system – there are people.  People are supreme in accomplishing lasting impactful change, especially when we try to mimic behavior with software.

The most important principle I’ve learned and stressed is iterations.  I try to stress the importance of simplicity as first steps.  This is a detachment from traditional Waterfall development.  With every project requirement, I try to find simple solutions initially and build upon success.  For example, are we trying to automate an intense human manual procedure?  As a first step, would it be beneficial to accomplish X automatically via a technology?  The key is to find X and think about the multi-step process that exists today.  Seek to find 80/20% time sinks in X.  There is probably a series of related steps which contains 80% of the time.  If you can automate that time sink, you’ll be successful in building strong relationships with happy customers.

Iterations are stressed in all modern development methodologies.  It is an important principle stressed by; Agile, Unified, and Lean.  Personally, I’ve worked in organizations on projects that practice Rational Unified Process, eXtreme Programming, Agile – Scrum, and yes Waterfall.  We have also researched and adopted ideas from The Capability Maturity Model.  At the beginning of any project, we might have standard policies and procedures to follow while ramping up our team, but very quickly we adapt and change to best fit our project and people.  This is a continuous process of adaptation and improvement, we introduce new practices as we evolve and regularly review outcomes.

Sean Dowd, one of my colleagues here at Avalon Consulting, LLC, recently wrote a couple blogs about DevOps and the importance of making releases trivial and routine.  We also partnered with a global retailer to contribute our expertise in facilitating success within organizations for an open-source project automating Cloud based release cycles.  This project is called OneOps and provides an automated deployment functionality for Cloud based applications.  Setting up applications in the Cloud can be a little daunting and repetitive, so OneOps provides an opportunity to automate this process.  Just like in the example above, OneOps could potentially save 80% of the time required to manually set-up servers in the Cloud. (See the post Automate, Automate, Automate by my colleague Andy Cohan for more insights on the importance of automation to project success.)

As businesses continue to shuffle internally hosted applications to the Cloud, OneOps and similar projects will become even more important.  I suspect that we’ll see companies like Amazon build similar services and applications in order to attract and retain Cloud customers.  OneOps is advantageous because it’s service neutral.  You can use OneOps with any Cloud service like Azure or AWS or Rackspace.  For Amazon though, they’ll most likely want to increase “switching” costs and make AWS “sticky”, which means if you shop around and decide to move to another service – you might have trouble with release cycles.

If you are considering changes in your development processes, visit our contact us page, or simply email us at info <at>  We help cater Cloud enabled development for your IT projects.

Will Thayer About Will Thayer

Will Thayer is a Principal Consultant Technologist at Avalon Consulting, LLC. Will has more than 20 years’ experience in planning, strategy, development, and training. His expertise includes web application development, big data analytics, NoSQL, management information systems, and system development life cycle practices. As an Adjunct Professor at the University of Denver, Will taught graduate and undergraduate students for 5 years. His research in Open EDI and XML EDI has appeared in books as well as trade periodicals. Will lives in Evergreen, Colorado where he enjoys skiing, hiking, biking, and camping in the Rocky Mountains with his wife and children.

Leave a Comment