Monitoring was the most important requirement when computers were just computers. What I mean by this statement are those times when there were barely any monitors or consoles attached to the computers, when printing was a costly affair and storing, backing up and restoring data was a big challenge! Monitoring was one of the main features that the mainframes provided to bridge the lack of transparently inherent in the erstwhile computer architectures. The developers and users alike were inquisitive and actively looking for what was stored on the storage devices and how accurate and correct it was. It was hard for users to remember for a long time what exactly they punched on punch cards and how many cards really got read successfully by the card reader.
Fast forward three to four decades of evolution of IT industry, you’ll notice that few business analysts talk about visibility of health of system to be a built-in feature and correctness and purity of data. Developers code with a tunnel vision without trying to identify pieces of sub-systems and data that people beyond developers i.e. end users, MIS department, top management and customers would like to see through. Architects dole out decent set of artifacts upfront in the beginning of project to show 1+4 views of the target system. However monitoring requirements are touched upon in a passé, as something that can be addressed by monitoring tools if and when needed.
State of Monitoring Technology
Tooling: Monitoring is deemed by all stakeholders as a “non-functional” part of application that would be mostly addressed by third party monitoring tools like HP OpenView, IBM Tivoli, Nagios, if and when the client feels a need for it.
Language support: Even modern day languages like Java, ROR, PHP, Microsoft stack offer little support when it comes to monitoring. Java introduced JMX api and JConsole but leaves much to be desired considering its penetration in enterprise IT. The focus has been on defensive coding to ensure that only golden data makes it to the system. Like an ostrich with its face tucked in the sand, developers think that data will stay golden at all times and hence no monitoring needed.
Mobile platforms: iOS and Android seem to yet to get a break from enriching their respective APIs to address the need for monitoring of enterprise mobile apps.
OS landscape: Unlike Mainframes which started off as batch processing systems with excellent monitoring capabilities, Unix, Linux and later Windows took quite a while to introduce tools and utility programs that will help with monitoring of applications. Unix and later Linux at least started coming bundled with whole bunch of smaller utility programs that help cobble together sophisticated application monitoring and management scripts. This spawned a category of IT professionals called Unix Administrators. Windows didn’t really become a server side OS for a long time and lack of monitoring didn’t become a big deal until lately.
Cloud computing: This brand new paradigm of deploying and running applications has got its own list of monitoring pros and cons. On one hand, 99.999% availability is commoditized and being sold as a premium offering. On the other hand, cloud providers have been restricting database backups or forcing their ways of doing monitoring. Nonetheless the ability to offload a big part of monitoring to the cloud provider is a significant cost effective proposition for enterprises.
For instance, one of my client’s system has got a notion of “Service tickets”. Initially it was thought of as sufficient that a creation_date, creation_user, modify_date, modify_user on the ticket would be sufficient to track progress of ticket as it gets serviced. However at a later stage, the customer started asking for more detailed monitoring of tickets like:
- Which employee or associate looked at the ticket the first time, and how much time passed between creation and first look
- Which associate updated the ticket, and how long it took relative to time of creation of ticket
- Was the ticket updated after some effective action or just returned back to the customer with a comment that it not serviceable at this time
- Was a counter proposal or suggestion made so that customer doesn’t feel ignored or feels that the system is apparently lost in red tape
The long and short of it is that “Service tickets” are only seemingly a simple workflow but for customer satisfaction equally important are the monitoring aspects of it.
Here is how I would propose requirement gathering and designing of a “Service request” handling application.
- Apply CRUDS rule– how, when, where a ticket (the entity in question) would get created, retrieved, updated, deleted, and be searchable.
- Now, ask yourself if the entity is driven by a workflow. What is the state transition diagram and the number of states that it will go through before finally entering the close state. Draw the state transition diagram on paper or in a modeling tool.
Then as a rule of thumb, I would recommend “If the number of states is more than three or the number of times the state can change is more than three “ then you have got a functional type of monitoring requirement. Add a UI for displaying the monitoring aspect of the entity in question as part of scope of development. If you don’t throw it in, you’ll anyways do it as scope creep or a new requirement in a later iteration. Until that time, your end users have to bear with lack of visibility and transparency in the system. Bear in mind, addressing it in a later stage will be harder and long drawn task as it might involve design level changes.
Part of the reason, monitoring gets victimized so callously or ignorantly by all stakeholders is because it is not considered as a must-have task for success of the system or product especially when time to market is short. Hence no budget is allocated for monitoring in first few iterations of development. Unfortunately by the time monitoring is addressed, the rot has already gotten down a little too deep and introducing monitoring becomes quite an uphill task. Like any other requirement, if it is not addressed early on during the SDLC (Software Development Life Cycle), the cost tends to escalate exorbitantly.
The hard fact is that monitoring is a functional requirement and enough bells and whistles should be built by design to enable monitoring at a later stage in the life of a project.
How is your enterprise dealing with “functional monitoring” needs in your SDLC process? Is it more than often panning out as impulse knee jerk reaction in response to a series of face offs with end users. Or is it more planned & organized and part of the development process? Share with us.
Take charge of your enterprise app strategy. Use this CALCULATOR to find what your app type should be: