A platform for organizing the production of information systems. Part 1

Short description

The market of IT product manufacturers is increasingly focused on agile tools, which allow for the creation of value in the production of IT products. However, flexible methodologies are limited by high financial costs due to a high level of uncertainty of the desired result. To address this, a tool is needed to create pilot solutions rapidly, at minimal cost and with high levels of documentation. Digital platforms can help shift the focus from IT products to IT services and support the digitalization of information systems. Platforms allow for the creation of large, flexible systems from individual modules and applications offering accessible services to solve technological or functional tasks.

A platform for organizing the production of information systems. Part 1

I Introduction

The modern market requires rapid changes in the organization of the production process of goods and services, but at the same time maintaining the stability and quality of the business level that was formed earlier. These trends, in turn, dictate special conditions in the market of IT product manufacturers.

Recently, IT production is increasingly dominated by a shift of emphasis from IT projects, the result of which is Productto the IT product, the result of which is Value for the customer This trend promotes Agile tools, focused on IT production in the context of changing requirements, which allow you to sort through options for the creation of value in the creation of an IT product. But the application of flexible methodologies involves a number of limitations, primarily high financial costs, due to the high uncertainty of the desired result.

I would like to use a tool that allows you to create pilot solutions in a short period of time, at minimal costs, with a high level of documentation of the process itself and the result. This should allow obtaining comprehensive information for the analysis of the implemented functionality of the IT product and its deviation from the desired one.

I have already published an article reviewing similar solutions, discussing their advantages and disadvantages link to the article.

But this topic gained new momentum after the departure of some players from the Russian market.

This article is devoted to the discussion of the concept of the organization of the production of IT products.

II Platform for organizing production of IT Products

In order to support the above-mentioned trends, tools are needed that make it possible to build large flexible systems – digital platforms from individual modules and applications in the form of accessible services.

1. Definition of a digital platform

In order to agree on a common understanding of the subject area terms discussed below, let’s delve a little into the theory.

Digital platform – an automated information system of a special class that allows a conditionally unlimited number of people to use its capabilities with the help of Internet technologies and to solve their technological or functional tasks in an automated mode.

In the platform, it is customary to distinguish 3 aspects of application:

  • Platform as a technological structure (software integration of data and applications for their processing);

  • The platform as a business model, a corporate organization-ecosystem, which includes developers and suppliers of individual modules and applications around the platform company, the value is created by reducing the complexity and increasing the efficiency of interaction between producers and consumers. At the same time, costs are transferred from the development of a new individual product to the creation and improvement of universal functionality, a reusable platform;

  • The platform is an open, publicly accessible infrastructure (site, marketplace, etc.) for interactions between producers and consumers.

The use of platforms should shift the emphasis in the production of software from the use of IT products, the use of IT services that support the digitalization of the development processes of Information Systems (hereinafter IS), the use of a common “lake” of data and the organization of IT services in the general business model of the enterprise – the developer IS.

2. Model of the IP production organization platform

When organizing the production of an IT product, one of the key problems is manifested by uncertainty in understanding its structure and principles of operation. To eliminate this singularity, a method of formalizing requirements for the subject field is usually used. It is the Requirements, drawn up in one form or another, that on the one hand help to understand the essence (context) of the target Product, and on the other hand are a framework for organizing work on its implementation. The obvious conclusion follows from this that the better the requirements for the target system are formalized and described at the initial stages, the less uncertainty remains in the intended solution, and therefore the chances of a successful and efficient organization of work on its implementation increase dramatically.

Unfortunately, in practice, it is far from always possible to organize the process of collecting requirements and designing IP systematically, fully, and at the appropriate level. There are many reasons for this: from the physical impossibility of gathering requirements to the functionality of the system, to the lack of sufficient competences in the team for a high-quality and complete implementation of the design stage. One way or another, but in life there are many examples of the development of excellent information systems, created without a full-scale design stage, at least at the stages of pilot initiatives.

From this we can come to the disappointing conclusion that in practice the IT product production system is perhaps organized as with a full-scale design stage and “smearing” these works by the implementation stage. But in both cases, if the IT product is not created as an instant solution that everyone will forget about tomorrow, but is built with a development perspective, it is necessary to devote sufficient time to fixing the requirements for the IS being developed.

Therefore, to automate this kind of activity, at least 2 macro-services can be identified:

  1. “Accounting of IT Product Requirements”;

  2. “Organization of IT Product production”;

Each of the services, in turn, consists of smaller IT services. Let’s start by discussing the first one.

III IT Product requirements management service

For the sake of fairness, it should be noted that, less often, there are inflections that are the opposite of those mentioned above. Sometimes analysts send excessively detailed, detailed requirements, overly saturated with diagrams, schematics and other specific artifacts, to the development shop. This option is also difficult to call constructive. It takes a lot of time for developers to “get into” the structure and style of submitting Requirements and be able to organize their work effectively on their basis. A detailed discussion of this topic can be viewed on my YouTube channel.

Development experience shows that with any iterative approach to product implementation (Scrum, RUP, MSF, etc.), it is more convenient to manage not with individual tasks, but with metrics that group work for a certain product functionality. In RUP – this Precedentsin Agile methods – this Feature (usefulness) or Store (set of possibilities) and others. This is due to the specificity of the process itself, when it is impossible to test or demonstrate a separate completed task (algorithm, part of the code, etc.), but it is possible to analyze the result of a group of works embodied in the final assembly: the functional possibility of user interaction with IS.

1. Submission of the IT Product in the form of Requirements

Based on the concept described above, the Requirements, for their effective implementation, are most conveniently presented in the form of a hierarchy that details the context of the target Product from the description of itself to its constituent elements and their characteristics. It is appropriate to reduce the constituent elements of the Product to a description Opportunities (functionality). The requirement for functionality may be supplemented by non-functional requirements, for example, conditions of use, etc.

Based on the above, despite the maturity and format of submission of Requirements by the design team, in the service “Product production organization” they should be in the form of a description of the capabilities of the IT Product or its components or the conditions of their operation. Therefore, the Requirements must differ in the type that determines the methods of their implementation. The type can have the following values: 1) “Product”; 2) Component; 3) “Opportunity”; 4) “Condition of use”; 5) “Behavior”; 6) “Algorithm”; 7) “Visual performance” and others. Example:

the Requirements tree

2. Ways of submitting Requirements for an IT Product

It is often convenient to infer the context of a product around a set of visual prototype forms. It is natural and easily understood by most interested parties. For example, the requirement:

1.3.2. Submission of the Requirements version form Visual performance

can be a key, in its field of description, component of the target product and contain a layout of the form, see Figure 1.

Figure 1. Layout of the claim form

Other requirements can be formed around it. For example, the description of the calculation algorithm associated with the user’s action can refer to the button element displayed on the form layout; The description of the database table can be related to the input fields on the layout, etc.

This option is very convenient for discussing the possibilities of an IT product with employees who are far from digitalization technologies.

Let me clarify once again, we are not talking about the way of developing requirements, but the way of their presentation for further effective implementation in an IT product. You can see how to develop requirements on my YouTube channel

Since the Requirements are a complex agreed structure, in addition to hierarchical relationships, it is necessary to take into account logical ones. Fig. 2, essence – “Communication of requirements”. For example, fixing the fact of replacing one requirement with another under the influence of external factors, or the mutual influence of a group of requirements on each other. This technique will avoid the uncontrolled occurrence of errors in the IT product, when trying to change one of the related requirements, without assessing the degree of necessity to change the related ones.

Figure 2. Requirement

3. Modeling the Requirements life cycle

In order to monitor the progress of the implementation of the Requirement in the target Information System, the formed Requirement must be sent to the service “IT Product Production Organization”, as the context of the task with its implementation. In the production service, works will be organized that embody the requirement for the functionality of the IT product, their results will be recorded, and the current stage of its life cycle will be returned in response (hereinafter – ХС). So we will be able to monitor the degree of its readiness in the target product in the requirements accounting service itself, see

Figure 3. Interaction of IT services

In this regard, the status of the Requirement should be fixed, which determines the current stage of its processing and the degree of readiness in the current version of the IT product. For example, “Created”, “Under development”, “Implemented”, “Cancelled”, “Superseded” see Fig. 2.

Since the Requirements are formed hierarchically and reach the top to the target Product, this tool can effectively manage the progress of implementation of selective functions (Requirements) in the target IT product. Example:

where already implemented Requirements are highlighted in blue

4. Complex organization of Requirements for product lines

Developers of IT product lines may have another problem. For example, if the same Product is supplied to several customers who may have different requirements for individual IS elements. At the same time, most of the changes in the Requirements must occur synchronously, and minor changes in individual branches must be made independently. That is, one business product can have several implementations in IT products that have few differences. For example, a version for a non-commercial structure and a commercial one. And there are possible variations of the solution.

Since the assembly of the version of the Product was purchased by the service “IT Product Production Organization”, then it is rational to collect the necessary versions of business solutions in the final IT product. For convenience, these activities will be taken into account there in different Projects.

But we will develop this topic in the next part, where we will consider in detail the services that support the organization of the process of implementing requirements in an IT product.

Related posts