Business applications are subject to continuous change. In particular, the typical cost drivers that only arise in the course of a project – above all, functional changes and integrations – are repeatedly underestimated and are responsible in the long term for the failure of even very large IT projects.

 

In short

  • Typical cost drivers in SW development and operation and what lies behind them
  • Why data models are so important
  • How technical adjustments and operation remain manageable during the life cycle of an application

 

 

Whitepaper about Low Code for individual enterprise software

As a software company mgm has been developing individual enterprise software for over 25 years. The core idea of A12 is based on a series of recurring observations from various projects.

12 is an enterprise low code platform for the development, integration, maintenance and operation of enterprise applications in complex IT landscapes. It combines a low code approach, where business experts can create an application without programming skills, with professional custom software development and system integration.

This is an excerpt from the white paper “A12 Low Code and Co-Innovation for Individual Enterprise Software”.

Download the full paper here.

 

Cost driver: Increased expectations towards enterprise applications in the life cycle

Business domains – anything but standard

The models underlying all enterprise software do not follow any standard. On the contrary: they are highly individual and always contain exceptions and in some cases contradictions.

Each enterprise software models a certain section of the company-specific reality. The models of entities are subject to continuous change. This is a major effort driver in enterprise software development.

The following points are mainly responsible for the change:

  • A grown business is a complex network. The knowledge about it is distributed over many minds. There are a lot of parameters that very different representatives of the company are constantly working on.
  • The business is continuously developing. The portfolio changes. Distribution channels are added or removed. Depending on the industry, new regulatory requirements must be met.
  • Companies organize their business individually according to very different rules. They also use their own terminology, which is successively expanded and adapted.

Another cost driver is also related to the underlying models: They depict ever larger sections of the business reality that are relevant for success in the respective business domain. The models are thus becoming successively more complex.

 

 

Cost driver: Functional changes in enterprise applications in integrated and complex IT landscapes

Different representations of business entities

From a software development perspective, any changes in business entities are very costly. This is because they must be represented differently in different technical contexts. Between these different representations mappings are necessary. The representations must be mapped to each other. In practice, this means that even the smallest technical change involves a whole cascade of adaptation steps in the software.

The following list shows an overview of these different representations and mappings that typically occur in enterprise software.

The starting point is the specification (1). As a template for implementation, it represents the first representation of the modeled business entities and their relationships to each other. In a three-tier architecture, the following representations are added:

  • In the data storage layer the business objects are stored in a database. For this purpose, a representation is required that meets the requirements of this persistence layer (2). In a relational database, it takes on a tabular form. In order to make the data of the tables processable in an object-oriented high-level language such as Java, an object-relational mapping takes place (3).
  • The business layer contains the application logic. It brings along its own representation (4), which results from the respective processing of the business objects, components and workflows.
  • In the presentation layer another representation (5) is required again. This is about how the business entities are represented in the user interface and which interactions with them are possible.

In addition, further representations and mappings of the business entities arise in the following contexts:

  •     Providing services for certain functionalities – for example, retrieving inventory (6)
  •     Generation of Word or PDF documents, such as insurance policies or notices (7)
  •     Integration with other systems within the company’s IT infrastructure (8)
  •     Extensive migrations, which become necessary due to further developments of the schema of the underlying database (9)

Each of these mappings brings its own challenges and efforts. Some of them only come into focus after some time. Business applications usually do not stand alone. And if they do, they do not for long. Rather, they are embedded in complex IT landscapes and only develop their full potential when they are linked to a range of internal and external applications.

 

Cost driver: Technical changes and operation for enterprise applications in the life cycle

Heterogeneous IT landscapes

The IT landscapes of medium-sized to large companies share a characteristic feature across all industries. They consist of large applications such as SAP or larger individual applications as well as a number of smaller applications. With regard to their integration in the processing of business transactions and data exchange, all applications ideally work in an integrated manner.

Due to the variety of technologies used in their applications (SAP, Java applications, cloud-based applications, etc.), these IT landscapes are usually built on a permanently heterogeneous technological basis.

This means in detail:

  • The individual applications in this landscape usually have their own project team, their own release cycles, and their own technological basis
  • For custom applications, different technology and architecture decisions are made depending on the age of the application and the preferences and decisions of the project team. This also applies to integrated applications that are based on a product such as SAP or MS Dynamics.
  • Different applications usually also have different contact persons on the business side, who create the technical specifications for the initial and further development of the application.

The heterogeneity of the IT landscape is a further expense driver that cannot be completely resolved even by today’s low code approaches. Individual development work can be reduced, but cannot be completely avoided. Even if business applications start out small, integration issues usually arise sooner rather than later – because only when integrated do applications unfold their full potential.

A12 is therefore not designed as a pure low code platform, but as a holistic approach that takes system integration into account from the very beginning.

Read the whole whitepaper now and learn more about innovative software development based on Enterprise Low Code. Download it here.