The association of functional supervision with technical supervision

FOCUS ON FUNCTIONAL SUPERVISION

An application can function perfectly from a technical point of view even though certain business processes or certain application functions do not function correctly or are unusable due to faulty functioning of one or more elements of the application or too long response times. Functional supervision makes it possible to get closer to the feelings of users, by automatically playing out scenarios for the use of applications or processes (end-to-end involving several applications) and by placing points of verification and measurement of response times at each stage of the scenario . The functionalities and the way to test them (scenarios) are described step by step then executed at regular intervals and / or according to a chosen schedule in order, for example, to check before the arrival of the users or after an update that all the functions are actually available with the expected level of performance. The regular play of scenarios 24/7 also makes it possible to detect key niches during which performance is reduced. If one of the scenarios fails at one or more steps or takes longer than expected to be executed, an alert can be raised according to the same principle as the technical supervision alerts (critical if it is a failure or an intolerable threshold overrun, warning if the response time is overrun which remains “bearable”).

Functional supervision, also called monitoring of user feelings, is the second step in supervision projects but is often reserved for large organizations with two separate Research and Production departments or even a DevOps entity heavily involved in the automation of tests.

It would be easier to limit oneself to this single method of supervision which effectively ensures to know whether an application is available and efficient for users. However, functional supervision only points to unsuccessful steps or response time overruns but does not make it possible to diagnose the origin of an incident or a problem unless it is purely functional . If a web application malfunctions, the scenario will detect it and point to the concerned step (absence of an entry zone on a page for example) but it will not be able to specify the technical origin of the incident or problem (server web, application server, database, network, bug…).

Conversely, limiting oneself to technical supervision, which itself offers many diagnostic solutions, also presents flaws since this does not allow us to decide between problems of technical origin and problems of functional origin (which is often particularly useful in particular. in the relationship with the editors), nor to objectify the response times in order to qualify them (comfortable, bearable, intolerable). These two technical supervision shortcomings very often lead to communication problems and misunderstanding between IT or more precisely the operators, for whom the services are available and the users or application project managers, for whom the application does not work. not.

Who has not experienced the unavailability of a critical application even though all the technical elements seemed to work perfectly? Situation during which the dialogue between end users and IT and even between research departments and production, systems and networks departments, often turns into a storm.

Who has not lived, response times multiplied by 10 at a certain time of the day, making it impossible to meet its business commitments, even though the database seemed perfectly operational?

In addition to this, you will need to know more about it.

In addition to this, you will need to know more about it.

SHOULD WE PREFER FUNCTIONAL SUPERVISION OVER TECHNICAL SUPERVISION?

Generally, IT supervision tools only address technical supervision needs, without even ensuring application consolidation, which is however the purpose of the IT service to provide users. This limits supervision solutions to technicians' tools and does not ensure easy understanding of the application state, nor of measuring the impact of observed malfunctions, nor of being certain that users have full access to all the functions. they need with the expected level of performance. Furthermore, this does not allow user support actors to have enough information to carry out an initial diagnosis, understand the impact of an alert, deal with incidents effectively, scale up to the right skills and ensure good communication with the users.

In addition, technical supervision alone does not provide the functional managers of the studies and projects departments with the elements that interest them, both with regard to performance monitoring and for the purely functional monitoring of business applications and processes. This gap forces them to turn to dedicated solutions such as test robots to get closer to users' feelings and in doing so they do not have solutions to investigate and diagnose. However, how to analyze, understand and resolve a recurring drop in performance over a particular time slot, without having capacity monitoring? Isn't it easier to have bandwidth monitoring available to plan a request that generates a high-consumption data flow? Who has not witnessed a dialogue of the deaf between the IT department which presents excellent availability and performance rates while for users the application's response times sometimes make it totally unusable?

In addition to this, you will need to know more about it.

In addition to this, you will need to know more about it.

WHAT ARE EACH NEEDS?

The needs in terms of IT supervision are in fact not identical according to the actors of the IT organization:

1. Operators need to know the operating state of each brick and technical service at a given time, to be alerted as precisely as possible and to measure their impact and criticality: in the event of a failure in progress, in order to correct the incident as quickly as possible (ITIL incident management process), in the event of a risk (exceeding a threshold or growing a file, for example) in order to have a proactive approach within the allotted time to anticipate and prevent the occurrence of incidents (increase in time a tablespace or disk space for example). They also need to historize the technical operation, the incidents, their recurrence, to analyze them, parallelize, dissect, to set up a management of the problems aiming at eradicating the recurring incidents, minimizing the risks, anticipating the needs, managing the problems. capacities, have a pro active approach, ...

2. Functional managers and project managers need to know whether applications and business processes (including processing, requests and flows) are functioning effectively and with response times acceptable from the point of view of users (performance management). They also have this same need in “classic” production time but also during the testing, preproduction, acceptance phases, upstream of changes such as production releases (side effects, regression, drop in performance, etc. ) in order to check that all the functions remain available, including those which have a priori nothing to do with the change made (side effects). They still have to make sure that this change will not lead to a decrease in performance of all or part of the application.

3. The Information Systems Department needs to know whether the commitments made to the General Management and to the users are respected, in terms of availability, continuity and performance of the applications. They must also have the information enabling them to foresee future needs, particularly in terms of technical and organizational resources (capacity management), sometimes in the long term when the purchasing processes do not offer them great responsiveness (public contracts in particular). In a process of valuing the IT contribution to the businesses, they also need to "sell", in the most objective and convincing way, the service provided, the gains and the added value offered by IT to the various businesses. At a time when the race for budget cuts requires talking about return on investment, the IT department should no longer be reduced to a cost center. These needs suppose that the studies (projects and changes) and production (systems, network, support) departments dialogue during all the application life phases, understand each other and share the same vision of the operation, availability and performance of applications. and IT services made available to businesses.

4. We can even consider the trades , as a fourth actor needing to know, to understand, to be reassured about the proper consideration of their needs in functional terms such as performance and continuity of service but also during updates. or significant migrations. IT no longer has to deal with users who are resistant to IT or who are totally idiotic in use, yet this does not necessarily make the dialogue between these two worlds simpler. It is necessary to popularize the operation and IT complexity without suggesting that it is comparable to operate the IT of a company or a public establishment and the "home" computer reserved for domestic use. In this context, supervision must be able to serve as a showcase for the IT department.

PILOT IT A FEDERATORY SOLUTION

In addition to this, you will need to know more about it.

To reconcile all these actors around the same vision, the same issue, it is useful to set up supervision that meets the needs of all the actors involved, which implies associating functional supervision with technical supervision to present a unifying application operation.

This association will in most cases make it possible to rule on the technical or functional origin of a malfunction such as a drop in performance and to objectify response times, thus avoiding both misunderstandings and wasted time.

If we take the example of a given application, its consolidated operating state will result from the check:

• the technical condition of all the components and services it needs to function optimally (database, web service, application services, server, network, resources, etc.),

• the result of the functional scenarios played (response time thresholds included) with, for example, the following steps: launching the application, entering the identifier / password pair, opening a page, entering text, modifying a element triggering the opening of a page, recording and then disconnecting from the application.

If a scenario is unsuccessful or with intolerable response times, either the technical condition will make it possible to understand the reasons and intervene quickly, or all the technical components seem to be working correctly and this will allow us to focus on the search for 'a functional cause.

The solution must therefore present a consolidated statement of the various services that the application needs to operate and the associated functional tests (response time included), to provide the support service with useful and relevant information so that it can intervene in the best possible ways. deadlines and with the best efficiency.

Responding to these 4 needs, all essential, through a single supervision solution, able to combine functional supervision with technical supervision to deduce real application supervision, will thus present both organizational and technical advantages. This will unite all the players around the same tool, consolidating the results of technical controls and functional tests as well as their monitoring and offering alerts also consolidated into a single vision of application operation, that of the service effectively and objectively rendered. to users.

Combining functional supervision with technical supervision in the same tool also ensures better information sharing between the teams since this shared tool for the same objective must be enriched both by the projects, involved in the functional test scenarios, as well as by the operators, in charge of the deployment and configuration of technical supervision.

This will allow both support and on-call services, in direct contact with users, to play their full role of communication, initial diagnosis and escalation to the right interlocutors, thus reducing the bottleneck effect and waste of time in return to service.

The results of functional and performance checks, automated in scenarios performed periodically by the supervision tool, in the same way as the results of technical checks launched, can thus be compared and taken into account in the calculation of application availability. . The same tests hitherto used only for testing and acceptance purposes before going into production can also be reused in a production context, which adds efficiency to relevance.