In the article “The Dawn of the In-House Software” of the portal Logistics Tech Outlook, CIO Kevin Glynn of DSC Logistics talks about the advantages of software development by in-house teams. With the ever-increasing accessibility of tools and the continuous improvement of processes, as well as agile methods and easily available cloud solutions, it has never been easier to develop business-critical software in-house.
In-house development as a counterpart to software bundles
An advantage of internal development is the possibility to roll out individual features instead of extensive version updates. According to Kevin Glynn, this allows companies to avoid two problematic scenarios:
- Most companies adapt Suite solutions to their individual needs in order to optimize work processes. With frequent version updates, these adaptations must be carried out repeatedly, which costs time and resources.
- The adaptation costs incurred by the update often make the update financially so unattractive that it is preferable to continue using an old version, which can lead to security gaps and compatibility problems.
Another risk of packaged solutions is that its developers have no direct connection to the business models for which they offer solutions. In addition, the product must cover a wide range of use cases. This is a problem that should be familiar to all users of an office solution: Only a fraction of the features are actually used, the rest of the package only gets in the way of using these features more efficiently.
DevOps and cloud solutions as a basis for in-house development
The easy availability of cloud solutions mentioned above minimizes the risk of not being able to scale your own development. Projects for implementing a suite solution, on the other hand, are more complex and thus potentially more error-prone and cost-intensive. In the long term, the DevOps model allows the risk factor support to be handled internally, which improves response times and increases the quality of the product, as users, implementers and quality assurance are able to act at any time, according to Glynn.
“DevOps is agile IT (operations) delivery, required to match the cadence of agile IT development. DevOps is a philosophy, not a method, or framework, or body of knowledge, or *shudder* vendor’s tool. DevOps is the philosophy of unifying Development and Operations at the culture, practice, and tool levels, to achieve accelerated and more frequent deployment of changes to Production. – Rob England: The IT Skeptic
This is in line with the current requirements for software in intralogistics:
- Availability, stability and security
- High performance at all workstations
- Data in real-time, maximum support of mechatronics
- High parallelism in warehouse processes
- High potential for adaptation and expansion
- Simple, consistent maintenance processes
- Scalability of infrastructure and throughput
This quality objective can be excellently supported by our manufactory philosophy. After all, a potential weakness of in-house development is that it is possible to lose sight of the market, which is changing at a rapid pace, especially in logistics. The danger that the fate of Nokia (German) may befall one, and one does not recognize the change in time, cannot be dismissed.
The software manufactory
The goal of our approach is not to hone down an existing product so that it meets the requirements, but to create the right solution for a concrete problem.
Software follows function
The manufactory combines the advantages of in-house development with those of a service provider: development cycles remain shorter and feature-based. At the same time, there is no need to adapt a suite solution to individual needs. The central advantage of the software manufactory approach, however, is the market-based use of all produced software, which an in-house solution can never achieve to this extent. Recurring patterns can be derived from the requirements of different companies and business models, which can be better addressed and solved by combining proven modules with individual adaptations than would be possible from the perspective of the individual company. This is because the manufactory model relies on individual solutions derived from standardized processes, as opposed to bundled solutions that are susceptible to grey areas with little added value due to their broad scenario modeling.
What the manufactory model offers:
- Standards at its core, flexible adaptation to processes
- Stable, open architecture
- Best practice concepts from the entire industry
- Fast and small update cycles
- High performance through tightly defined scenarios
- Hardware and platform independence
The foundations of the software manufactory
An essential prerequisite of the model is a high level of expertise in the field of intralogistics, a precise knowledge of current solutions on the market as well as project management and software development techniques. Only if the manufactory and the customer speak the same language in terms of methodology can the cycle of analysis, consulting and implementation be transformed into a continuous value-added process that follows the Plan-Do-Check-Act model.
Clean Architecture as the basis of the software manufactory
The first understanding for complex software projects should be that it’s as an ongoing process. To prevent software solutions from influencing the process and thus gradually adding more and more ballast to business processes. Therefore, business rules should define the actual core and thus the value of an application.
With the business rules at the core of the architecture, systems are created that fulfill the following conditions:
- Independence from frameworks. The architecture does not depend on a feature-overloaded software library. This makes it possible to use frameworks as tools instead of pressing the business rules into an existing system corset
- Testability. The business rules can be tested at any time without user interface, database, server or other external elements by decoupling them from the system
- Independence from user interfaces. The business rules remain the same, even if the interface changes: They can be displayed via a command line as well as via a graphical user interface
- Independence from databases. The way the rules are stored and managed does not depend on a specific architecture
- Independence from external influences. The business rules have no connection to the outside world.
This core is overlaid by other layers that transport these business rules further outwards.
The inner circles are guidelines, the outer ones are mechanisms. The special thing about it is that dependencies in the source code may only refer from one outer circle to the next inner circle, so the outer layers can easily be adapted and exchanged while the core process remains intact.
Context-Aware Frontend Architecture to ensure sustainability
Due to the constant development and transformation of digital infrastructure, the cycles in which software has to be adapted are shortened. This results in the requirement to strictly separate front and back end right from the start and to understand all components as independent modules that can follow their own release cycles. Similar to the previous model, functional levels are defined here.
- Die The service level is the classic backend in which the business processes are made available
- The delivery level (Lieferebene) aggregates the business processes for display and processing in the front-end and meets the requirements regarding intermediate storage
- The client level contains all possible clients in which the application part is displayed
This makes the manufactory model particularly suitable for complex projects over a longer period of time in moving markets, where it also develops its greatest strengths over suite solutions, as all modules and processes achieve the greatest possible flexibility and independence by avoiding dependencies on outside elements and using business rules as a central design rule.