The system is developed and implemented. What's next?

When you are hiring a team for some Web application or software development, the first thing that interests you is the development time and the total project cost. Besides, you should think about how your IT system will work at the beginning of the project, also take into account development technologies, architecture, etc.

Quite often it turns out that the system is in a stage of active development and modernization for a very long time. During this stage, the concept of support and development is unclear for you as for system representative or system owner, all the system support should be as background of basic system development.

Introduction

Client: Reporting statistics stopped working, besides for some reason there are no transactions that should passing through payment terminals. Would you be so kind as to check what has happened there?

Developer: Excuse me, but your system support agreement has expired for more than six months ago. System development and its upgrade also stopped for a long time ago. We don’t have the required resources to service your system at this time.

Regrettably, in this case it’s your problems! The development company simply doesn’t have an ability to hold employees in case of "and suddenly you need something"...

Was it forced cooperation or necessity?

When you are hiring a team for some Web application or software development, the first thing that interests you is the development time and the total project cost. Besides, you should think about how your IT system will work at the beginning of the project, also take into account development technologies, architecture, etc.

Quite often it turns out that the system is in a stage of active development and modernization for a very long time. During this stage, the concept of support and development is unclear for you as for system representative or system owner, all the system support should be as background of basic system development.

It is very important to understand the difference between these two processes, and here’s why:

Before the system will be launched into production, the developer’s main idea is to create architecture, build a scalable web application, create functionality, qualitative software coding according to the certain deadlines. Testing web application according to the test cases and automated testing allows you to find bugs or defects of the logic of work according to normal mode and liquidate them according to plan, preparing a software product for release.

After release, there is happening actual testing of the system. At this moment, quality of incidents play center stage, their classification and response time (fixing). The quality of support will be determined by the speed of incident response and total change of incidents quantity of different types. At this stage, the team's priorities and loading conditions are changing.

In order to avoid problems with understanding tasks importance or bugs-fixing time, you need to clearly separate these two activities during software deployment to production environment.

All additional modernization, implementation, etc. is basically have the same principles as the previous core development. With regularly and calmly software testing. All maintenance tasks are described in a separate agreement, with task classification and deadlines. Consequently, you will not depend on the conditional terms for publishing the next sprint's functionality in terms of system performance. You don’t have to make a decision "publish now or wait" - all such cases will be described in the agreement.

Subsequently, the support agreement, it’s not an opportunity for your technology partner to “tie” you to himself/herself. It’s a tool that will allow you to specify and regulate your cooperation more clearly in the future. This agreement will help you to control system survival and its development.

How to calculate support cost and not overpay (maintenance costs)?

Your system can consist of many components.

This is the hardware (servers) and installed software environment on them, which controls them. These are additional systems that support the work of your project. Yes, and the project itself. It is conceivable that in such a complex configuration, an error can occur at any time and everywhere, especially at the first time after system deployment. In addition to this, all your ideas on the system development stage, its modernization should be evaluated and described into understandable tasks for engineers. This is a job for the business analyst and project manager, which should be paid.

You, as a business person, cannot be in abeyance, you should have specific numbers of expenses monthly of your system support. But if you rely only on actual requests, then you will not have a harmonious system of expenses. It may be that you don’t have an incident for a long period of time, and then occurs a critical one that will require an urgent reaction, or occurs an idea for implementation that has never existed before.

For this case, we have such type of an agreement, which helps the parties to determine the resources that hypothetically may be necessary to maintain or fix the maximum limit of such services on a monthly basis. Service-level agreement (SLA) is an agreement between a service provider and a user about a service level. It contains quantitative and qualitative characteristics of the provided services such as their availability, customer support, bug-fixing time, etc.

Having clearly defined SLA terms and conditions, you can plan your expenses. If you notice that the service levels according to the SLA terms are not achieved, you can effect another deal or reconsider an agreement.

Automation support

This section provides more tips and tricks for improving the efficiency of your system support. If the support team doesn’t have its own automation practices, then you should move forward them to automation practices or find another support team.

Basically, the most important part of system support is to get information about what, when and where had happened. There is no point of losing a certain part of the profit and, in addition, customer loyalty just because you had problems with free space on the server from which the system stopped working normally.

That is why, Codein company uses the following techniques:

Conclusion

Of course, the cost of system maintenance will be significantly influenced by the technology which you have been chosen, the necessity to pay for certain licenses, the cost of server’s infrastructure maintenance and, even, the architecture of the solution. Because, if the architecture is ill-considered, then there can be a situation that you cannot fix the problem because you should “break down half of the system”.

In any case, Codein is ready to help you in maintaining your system, optimizing it and reducing the cost of it!

Please contact us.