Lack of quality DevOps: Reason for software product failures?

If you do analyze spectacular software product failures, you will find one thing in common: Lack of better handshake between the app development and the operations (this handshake is fondly called 'DevOps', that personifies the communication, collaboration and integration between the app developers and IT people responsible for the operations)

• As the developer of the application, do you know what features in the app are valued by your customers most?
• As the tester of the application, do you know how closely your test plan and test scenarios align with the way your users approach the app? Are your test cases mimicking the exact user actions?
• As the app admin, do you know the details of the exception even before your user raises a 'SOS' ticket?

• As the user of an app, do you know what features are forthcoming in the next release?

All these things are possible when the DevOps is working at its best. But the question is how many times we have seen it's working perfectly? In many customer meetings we would have heard they speak about different applications or environments in which the app we develop is going to integrate or operate and we would have no clue whatsoever about those unique apps or environments.

Agile processes to some extent address the DevOps with the insistence that the Product Owner must work with the dev team to bridge the communication between the two worlds. Product Owners guard the product backlog and the feature priorities and thereby representing or protecting the interests of the customers. But quality DevOps is much more that and that's where you need  Application Analytics

Application analytics integrates the development and operations by sharing the operations data with application development and vice versa. For a well thought out DevOps, the development needs to 'instrument' their code consciously with the available APIs or their own mechanisms. Currently tools are available that inject instrumentation code post build right into the compiled assemblies.

Once the right instrumentation bits are available in the assemblies, all that you need to do is to receive the usage data from the applications, ETL the data (if required), analyze and publish in dashboards and reports. Published data will provide you with a lot of insights into what's happening to the application that's gone to the production. There are even cloud based analytics systems available now that accept your data, validate and analyze your data and provides static and dynamic reporting like cubes.

 Some of the usual data collected as part of the application analytics strategy are

• Application usage data
• Feature usage data (what features are used most, what features are dumped after initial attempt to use the feature)
• Session data
• System data (client system configuration details)
• Exceptions data (both handled and unhandled exceptions)
• Performance, app responsiveness data etc.

With such obvious benefits, still most apps don't help quality DevOps. Reasons could be many, but the most important ones are

• Lack of knowledge
• Security and privacy concerns
• Political reasons
• App sponsor not strong enough to unite the app development and operation streams
• Etc. etc.

Having a forceful application analytics strategy is part and parcel of your agile intentions. Let's hope we will have this in mind when we go for the next big app development