It’s like building a house. Yes, but this is only the ideal case. Think about it, even when building a new house, you have to consider numerous interconnected factors, such as the location of the land, climate, security, scalability, and sustainability aspects.
One of Egnosis’ core competencies is industrial software development. This is where our service portfolio has expanded over the years. The way we assessed our workflows has helped us define and shape our organisational culture and value system.

Within this service, we use a market-validated workflow which relies on the state-of-the-art “Software Development Life Cycle” (SDLC) model.

In a globalised world, we have encountered a wide variety of customer types and business needs. Our experience has shown that, regardless of the industry, only those companies or organisations that share the same business values can create long-lasting partnerships. We believe that it is extremely important to identify these values together with our partners right at the beginning of our collaboration. Because there is nothing more demotivating than struggling to rescue a failed project or break through an unresolvable conflict due to a hasty decision of collaboration.

More specifically, once we conclude that we have the same value system, we aim to establish a mutually agreed framework contract that regulates the business relationship between the two parties, terms and conditions, working methods, and general obligations as soon as possible. Even though we highly appreciate the power of the given word, this would act as the basis of our cooperation, from which we can derive project-specific agreements.

It starts with the definition of the business segment, a multi-stage consultation in which we map the general needs and define the request type. First, we need to understand the big picture and then act strategically. Therefore, we are looking to answer general questions such as: is it about an already existing or a completely new product development, where is the company positioned in the digitalisation process, how much of the workflow is affected by the request, how mature is the company to take on the development, what is the type of the custom development, how does the request align with the company’s goals, how much critical imports will the development bring, what is the planned implementation timeline, and what are the potential constraints.

It is not simply small talk. Within this multi-round workshop, our knowledge of the business domain prevails, as we are not speaking in “programming language” but rather as a consultant with a deep understanding of the industry. Our industry focus relies on management, logistics, packaging and manufacturing.

We want to make sure we can meet the requirements, and therefore, after a general mapping of the request, the feasibility study will be carried out by our experts. In many cases, after a thorough examination, we can provide a simple answer and move on quickly. Such situations are when the customer wants to develop an existing industrial software further, already has a well-developed digitalisation skill set, understands the way of working or has an internal IT department and is looking for an IT supplier with niche competencies.

The more difficult situations where bold clarity is needed are when the customer wants to act by impulse, for instance, to react to the competition’s actions not to lose competitiveness. They expect digitalisation and automation to provide the answer. Their expectations and goals might exceed our scope. In this case, the project might be feasible, but it is necessary to realistically define our own capacity constraints in order to avoid over-commitment.

It is important to note that no software or tool will change company culture. For comprehensive growth and strategic development, long-term and radical mindset shifts are compulsory.

The heyday of the monolithic software giants is over. Unsystematic data structures, microservices and versatile nano-front-ends reign.

What end devices should we be compatible with? Does this still matter if we are designing the software architecture of the future? Not at all, as reality shows us that the production line sees the tasks on displays in real time, the warehouse manager sees them through VR glasses, and the manager looks at reports and takes the necessary actions on his tablet or mobile phone.

These requirements generate different directions, and without a proper understanding and management of their complexity, the architecture would fall apart. Furthermore, we need to consider scalability, data format compatibility and interoperability, as well as code sustainability, Hardware/Software maintenance, and personnel operating costs.

In contrast to traditional software design philosophies, agile software development targets complex systems and projects in a dynamic, non-deterministic and non-linear way. Accurate estimation, robust planning and forecasting at an early stage are often difficult to achieve. Therefore, large-scale pre-designed plans and breakdowns are likely to cause huge losses in the sense that they are not economically sound. These basic arguments, together with previous industry experience and the successes and failures of years of trying, have helped us develop an adaptive, iterative, and evolutionary development approach that favours agile software development.

This is the heart of the process: transforming and implementing business needs into software code according to the chosen technology and schedule. And here we know no compromise: following a strict methodology, stories are broken down into feature blocks and then into tasks. These are assigned to validation checkpoints that guarantee the full and high-quality development of what is defined in the requirements specification. The focus is on reusability, maintainability, and scalability.

Defining quality without a quantifiable set of criteria is a very bold and subjective undertaking. That’s why along with the feature blocks and tasks, we create an Acceptance Criteria list with the customer’s approval during the planning phase. Based on these, test cases and automatic validation functions are created.

Performing and validating these processes requires multiple steps, as the package must first pass the internal testing phase. After that, testing in a “real” or production environment occurs at the customer’s site. One of the main challenges is replicating the real client environment, as data security reasons often limit our testing capabilities.

Furthermore, industry and domain knowledge are essential to identify emergencies that may occur in production environments. This is where we stand out due to our varied field experience.

Just like a new piece of furniture at home. The initial thrill quickly disappears when you have to find its right place, take the old one out of use, and make sure the new item fully meets your expectations.

The proper delivery of a new software solution requires as much detailed preparation as designing it in the first place. The critical impact of a product shutdown on the company’s business operations, the reaction of the affected integrated environment, the vulnerability and migration of data, the adequacy of the hardware and environment are just a few of the organisational and operational aspects that form the basis of a detailed deployment plan.

Therefore, delivery planning starts at the project’s initial phase to ensure that all scenarios are adequately monitored, thus minimising the risk of delivery failure and unforeseen risks.

With development orders, the drafting of agreements for commissioning and product support services will start simultaneously. Here, first and foremost, the industrial complexity and user volume are taken into account and used as the basis for the tiered product support processes. The best practice for industrial applications with a significant number of users (>50,000) is to have first and second-level “on-site colleagues” responding, with the majority of situations arising related to the use of the application. Our colleagues’ expertise excels in training and familiarisation with the software. Making people within the company, as end-users, understand that the software is being introduced to make their work easier is a very critical moment.

A well-established product support workflow that has been proven over the years, where the submitter knows exactly when and where their request has been registered and from whom they will receive a predictable response to the request, is a key part of our software support service.