Digital {{Dev}} Lifecycle

I was watching a movie with my 9 year old son and the story moved to show the city of the future with all jazzy flying cars and stuff and my son excitedly shouted that it’s a ‘Digital City’. Till then I thought ‘Digital’ was a jargon used by techies to describe upcoming trends both in terms of solutions and practices. Strangely ‘Unified’, ‘Converged’, ‘Next-Gen’ and such jargon haven’t gone into my son’s vocabulary yet!

Along the way I’ve been looking at how development Life-cycle has adapted to the upcoming ‘App’ Paradigms…I can see that a lot has changed, but still the fundamentals have remained…This search actually began to benchmark multiple ‘Cloud’ App hosting solutions in the market and qualitatively compare them.

Why this search?

I’ve been trying to learn about multiple cloud solutions, but before I take a deep dive any one, I wanted to be sure that their ecosystem was good enough to meet the demands of the ‘Digital Enterprise’…especially the Mode 2 Teams which will become powerful in the next few years.

So First Let’s look at what are the different stages in the life of an ‘App’…

Traditional Dev Cycle

Traditional Development Practices


The Idea to build the app can come up from anything ranging from an ‘Automation’ Initiative to making something to ‘Comply’ to something else. Traditionally these have been restricted to top bosses in IT/Business to ideate and typically happen over formal meetings with lots of budget and Strategic Direction Orientation. However with the significant decrease of ‘Difficulty’ to get compute, Storage and Plug-n-Play Solutions in the market, ‘Shadow’ IT groups start springing up with solutions that work outside the IT’s control and get the job done at significantly less price and time. This in turn has prompted IT to become more ‘Open’ to ‘Crowdsource’ Ideas. Both the platform and Effectiveness vary significantly but is being been as inevitable. This is where Chat Rooms and Online User Forums are being seen as more effective than boardrooms.

Formal Requirements, Solution and Work Plan

Once IT has decided to work on the App the very first step is to consolidate and finalise the ‘Requirements’. This has been traditionally done via multiple meetings and then getting documented in Doc/PDF Files and then shoved into Shared Folders. Sadly the rapidity of rebuild, requirements change and target for first release do not allow for the old way of doing things. The new way is to move the documents in to Wiki Docs that allow for simultaneous edits, reviews and change approvals on the fly with clear tracking and auditable versioning. This is important as during the start of the project, the ‘Idea’ Owners themselves may not have a clear idea of how the solution should look like and perform the various tasks. The First Requirements on which coding will start should be expected to be minimalistic with functionality that are very clear and should steer clearly out of unclear functionality. Once the first version of app is released there will be more clarity and further requirements can be collaboratively negotiated and added.

Traditional Documents significantly slow this process and add excessive lead times that IT cannot afford.

The same logic applied to the further stages of Solution and Work Package Planning. Putting everything inside individual documents is an outcome of bookkeeping practices of the Paper world. Unfortunately Such Practices are not conducive to rapid development and Upgrades needed in the ‘App’ Economy.

Infrastructure Readiness

A Decade ago, I would have titled this stage as ‘Infrastructure Build’, but the realities of current Generation Infrastructure make the work ‘Build’ too insignificant and ‘Readiness’ In My Opinion carries more weight and emphasis and Security and Network Approvals probably may be the slowest activities in this this stage. In the old world, developers would hardly know what is their network requirements…But now Knowledge of Basic Networking is significant for success of the App surviving in the wilderness of ‘Cloud’ Infrastructure. The Programming Language themselves are web based and need the developer to know which network resource they will need and don’t…

Dev->Test->Release Pipelines

I remember a CMM guideline where the project lead is supposed to clearly identify what will be the stages of development and what will not be performed if justifiable. But I have never seen the project lead being able to negotiate and the clearance cleared from QA Managers Even for small projects that were only 2 weeks of effort 😀 …Sadly such ridiculous strictness is not ok in the Digital Side of things. Please note, I’m not making a blanket statement here….The consideration of what needs to follow all pipelines and what could skip pipelines is a decision to be taken by the developers and not external QA folks who have no clue if the artifact is cosmetic or has financial implications. Automation of asset management and audit-able Issue Tracking is definitely something that available now.

User/Developer Documentation

Documentation is the key element that ensures the survivability of the App in the Long run. The Language and usage will be different for Users and Developers. But typically we find User Facing Documentation built by developers and ends up being ineffective. This is where the role of IT-Ops comes into picture with the User centric documentation moving out of developers and developers ensuring that ‘their’ documentation remains in ‘their’ language. Further Documentation moving from silos of PDF and Visio files to wiki portal pages keep the documentation ‘alive’ and audit-able.

User Feedback

User Feedback, just like the Ideation phase has always been limited to the UAT Stage in traditional Orgs. After UAT the App ‘Improvement’ Stops and end-user suffers. The Current paradigm is to involve the end user is providing feedback not just in online forums but directly to the ‘Issue Tracker’ from inside the application. Imagine how dull the mobile App Stores and Mobile Apps would be if user feedback was not available! Not embracing this in the application design as a default is unforgivable.

So In summary, this is how I see the Development Lifecycle in Future

Digital Dev Cycle

Digital Development Lifecycle

One Comment

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s