Software Development

Functionally separate services that encapsulate a specific business logic and can be deployed independently of each other. The services provide interfaces and implement a specific use case, which can be seen as separate from other services. This is referred to as a bounded context in the sense of domain-driven design.

API-first means that a service in the cloud (SaaS) provides all features via an application programming interface (API). This means that there are no features that can only be controlled via a proprietary UI. All features and setting options are accessible via the API.

The aim of cloud-native is to operate scalable systems that automatically adapt to the number of users: if there are few users on the system, fewer resources should be used. If there are many users on the system, many resources should be made available so that the system always reacts quickly and adequately. This is achieved by using services in the cloud, so-called software-as-a-service solutions, which usually offer this option out of the box, or by using services offered by the corresponding cloud providers (platform as a service (PaaS)).

With this architectural approach, the business logic is made available to all clients in an interface (API). The backend system is no longer responsible for preparing the data for specific frontends; instead, intelligent API design allows the various clients to make use of this interface for each channel.

We implement all our projects using agile methods.

The goal of the MVP approach is to create the smallest functional product in order to make it available to the customer quickly and thus receive user feedback immediately. This user feedback is enormously important in order to prioritize the next steps, the further development of the product. To meet the customer needs in the best possible way and to reduce the time-to-market.

Non-functional requirements are characteristics of a software system that describe the demand on the software quality. These can be found in the ISO/IEC 9126 standard and are defined using the following generic terms: Modifiability/Maintainability, Usability, Efficiency, Functionality, Transferability, and Reliability. We describe the requirements of a system, such as how reliably it should be deployed, using scenarios. For each of our customer's use cases, there are completely different requirements for software quality, and the costs for the different qualities are also very different. We are familiar with this and find the right way for the overall architecture in these different dimensions!

This refers to the possibility of making certain business logic available on the platform of a specific cloud provider (e.g. Microsoft Azure or aws) without having to worry about the scalability and high availability of the system. That this function is available when it is needed is guaranteed by the cloud provider.

Resilient software design is the handling of error states in the live operation of a software system. This means that if a particular service is not available, the entire system is not affected. Users are informed accordingly that a particular service is currently unavailable, for example product inventory management, but a product can still be ordered.

Information is available here.

The central management of users and access rights is of crucial importance, especially for distributed systems with very different services. We are experts in various IAM systems and their features, be it Single Sign On (SSO) or two-factor authentication. We know open source products like Keycloak, commercial products or the solutions provided by our cloud provider partner companies (Microsoft Azure and aws). Together with our customers, we select the most suitable solution.

Represential State Transfer (REST) is a paradigm that is mainly used for web services. Here, it is important to build the interface (API) according to certain rules and also to fully exploit the possibilities of the HTTP protocol. This means supporting HTTP status codes for success and error cases as well as media types in order to signal to the client what it can expect from the interface for a response on the one hand, but also to specify on the server side how to react to certain states.

GraphQL is a query language for APIs that allows clients to request the data they need to represent the current use case. As a result, the data is selected accordingly in the backend and only the information that is really needed is transferred to the client.

MACH goes one step further than a pure microservices architecture. Here, it is necessary to combine different service solutions with each other in interaction with individual microservices. The products used must also meet certain requirements. The API-first approach specifies that the products are completely controllable via the API. For example, an e-commerce system has no hidden features that can only be set with a separate admin UI. The cloud-native approach is also important. The systems are designed for the cloud, scaling up and down fully automatically. This means they save costs in the event of underload and make resources available when many users want to use the system at the same time. Added to this is the headless approach. Interfaces for displaying the user interface are provided for all clients - a modern frontend, a PWA or a native mobile app can display the interface with the same interface according to the requirements.

We decide together whether using the MACH architecture is an advantage or whether an enterprise solution is a better fit. We can do both! For many of our customers, the enterprise solution is exactly the right decision. On the other hand, we also have a lot of requests with very specific requirements. The customizing of a large enterprise solution must then be weighed against the individual strengths of a MACH architecture, in which lightweight SaaS solutions are combined with individually created microservices and, if necessary, lead to the goal faster and more cost-effectively.

Time-to-market is critical. The faster an important feature is usable, the better. However, a new feature always carries the risk of error conditions. By using agile methods, it is in our DNA to provide high test coverage for all features. Automated unit/integration and, if required, surface tests are executed every time features are integrated. The deployment scenario is also built individually according to the requirements. Uninterrupted deployment is a matter of course for us. Of course, it is also possible to test how a certain feature is accepted by means of A/B tests only.

With resilient architectures, we make it possible that the entire system is not affected if a specific service fails. The user is informed that a certain service is not available, but he can still use most of the features.