What are the Legal Issues Surrounding Server Infrastructure in System Development?

In a sense, IT systems used in corporations are created by drafting specifications and design documents, and writing source code that corresponds to these contents. However, a system only functions in reality not just with these soft aspects, but also with the physical computers, or in other words, the infrastructure. In this article, we will discuss legal issues closely related to the field of infrastructure in system development projects.

What is Infrastructure in IT Systems?

Technicians who carry out system development are referred to as System Engineers (SE). The development project generally starts with the upstream processes such as creating specifications and design documents, followed by the implementation of the program and conducting its tests. Broadly speaking, a System Engineer (SE) can be described as a technician who handles all these necessary tasks. However, depending on the company or workplace, the job content and areas of responsibility may be further distinguished by specific names. The term ‘Infrastructure Engineer’ refers to technicians who, as part of their duties in the development and operation of IT systems, are particularly responsible for setting up the physical computing environment. IT systems used in companies and workplaces are, in a sense, abstract constructs made up of combinations of source code. However, in order for these systems to fulfill their intended roles, it is essential to build an environment around the infrastructure, including servers and networks. The practical work of system development progresses on two wheels: the implementation of program source code and the preparation of the environment around the infrastructure that supports its operation. This perspective is considered important in preventing unforeseen troubles.

Specific Scenarios Where Infrastructure Issues Can Derail a Project

In system development projects, it’s possible to focus solely on abstract programming and source code design, neglecting the perspective of infrastructure maintenance. However, if these two aspects are not in sync, it can lead to project failure.

How Server Sizing Errors Can Lead to Disputes

For example, after all the programming and testing is completed, it may be discovered that the server’s processing capacity is insufficient, rendering the system unusable. Predicting the potential load on the system during operation and maintaining the infrastructure according to the system’s scale is called “sizing”. There have been actual cases where server sizing errors have led to trouble. (One famous case, which was eventually settled, can be referred to here.) For more information on resolving disputes through “settlement”, please refer to the following article.

https://monolith.law/corporate/disputes-related-to-system-development[ja]

The fact that a dispute was settled means, simply put, that the dispute was resolved through discussion between the parties. Therefore, unlike when a judgment is handed down by a court, the content of the settlement is not accumulated as a precedent and is usually highly individual.

The Essence of the Case is the Scope of the Vendor’s Obligation to Respond to Unclear Specifications

However, the essence of such disputes can be considered to be “how much responsibility should the vendor bear for matters not explicitly stated in the specifications”. With this in mind, you can gain many insights from the content of the following article.

https://monolith.law/corporate/system-development-specs-function[ja]

The above article explains to what extent the vendor side should exercise discretion and bear implementation obligations for items not listed in the specifications. Here, it explains that the story differs greatly between “screen side” items (the so-called “front-end” domain) that can be easily visualized in requirement definition documents and basic design documents, and “logic side” items (the so-called “back-end”, “database” domain) such as data migration. In other words, it is considered that the “screen side” domain, where specification issues can be easily confirmed even by the ordering party/user (who usually does not have specialized knowledge about system development projects), tends to be attributed to the ordering party/user. On the other hand, “logic side” issues tend to be attributed to the contractor/vendor. Considering these points, server sizing issues are considered to be a domain that is difficult to recognize unless you are a technical expert, and therefore, they are likely to be attributed to the contractor/vendor. Therefore, unless there are proactive circumstances to exempt the contractor/vendor from responsibility, it is expected that the contractor/vendor will tend to be disadvantaged if this issue is seriously contested in court.

Measures to Prevent Troubles Due to Server Sizing Errors

In order to prevent the aforementioned troubles, it is important to align the implementation of programs and the writing of source code with the preparation of the infrastructure environment. The following are some of the specific measures that can be considered.

Clearly Define the Responsibility for Server Sizing in the Contract

Not limited to these cases, many disputes related to system development projects often arise from unclear role division between the system development experts, the vendors, and the users who are familiar with the internal affairs. While it goes without saying that close cooperation between the two is necessary for the smooth progress of the project, it is desirable to clarify the role division and responsibility range as much as possible in advance through contracts and the like.

Fully Implement Specific Development Requirements and Change Management

Also, if the functional requirements to be realized are vague, the risk of such disputes becoming complicated increases. This involves both the clarification of specifications in the initial requirement definition phase and change management during the project. For how to deal with specification changes during the project, please refer to the following article for a detailed explanation.

https://monolith.law/corporate/howto-manage-change-in-system-development[ja]

Select a Development Model that Matches the Nature of the Project

Also, deeply related to the above two measures, it is important to select an appropriate development model according to the nature and scale of the system development project. Generally, for the development of a system of a certain scale or larger, where server sizing can become important, it is considered beneficial to adopt the waterfall model, which is suitable for clarifying specifications and responsibility ranges. For a detailed explanation on selecting an appropriate development model based on the nature of the project, please refer to the following article.

https://monolith.law/corporate/legal-merits-and-demerits-of-development-model[ja]

Summary

Issues originating from the preparation of infrastructure environments can easily become blind spots in the smooth progress of system development projects. It is considered a significant burden for non-technical experts to pay attention to infrastructure-related problems. However, the preventive measures for such troubles can be said to be extensions of very basic measures such as “clarification/change management of specifications”, “clarification of roles/responsibilities”, and “selection of development models according to the scale and budget of the project”. The first point that those involved in corporate legal affairs should understand is that the basics of preventive law can be sufficiently applied to infrastructure problems. Also, for IT engineers, it is important to understand that infrastructure problems can become a serious risk of project failure, and to manage their work smoothly.