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
