• No results found

5. Result from the Interview with experts

5.2. Problems of legacy systems

5.2.2. Poor IT architecture and landscape

In old days, many systems were built in monolith architecture with hardcoded, including the legacy systems. The application is called hardcoded if the variable, value or data are written directly into a program. It makes an application is difficult modify because it is not parameterized or not configurable. It

also requiressufficient understanding of the implementation to be sure that the changewillnotintroduce inconsistencyandcausetheprogram to fail.

Application in which was built in monolith architecture tend to have user interface and data access are coupled with the logic of the source code. Such type of architecture has limitations which are not modularized and componentized application. Consequently, it is difficult to use only small part of it because the system works as a single piece. Figure 11 shows how monolith application is different with other type of architecture.

Figure 11. Monolith architect compare with other architects.

As depict in Figure 11, monolith architecture makes data, logic and presentation in one piece. Therefore, change in only one of them will require maintainers has to change the whole application. It is not componentized and is rigid to adapt to the new change. Another difficulty with monolith application is that it is hard or almost impossible to change the control flow of the application. Some architecture were designed and believed to be better that monolithic architecture.

Organizations that have been asked about support of the hardware tend to pin point on mainframe as an example of the legacy system. Clearly, because old mainframe systems are typically designed as monolithic architecture and can only allow specific programming language run on it. Moreover, not many experts are available to work with such are programming languages anymore.

Such way of programming leads to more problems such as:

Limited functionality. The systems which are built long time ago, only have simple operation which make

the functionality in legacy system is limited for today’s business requirement. Old technology with old type of connector has restriction to interconnect with the other systems. For instance, in insurance industry, customers’ information are first recorded on a policy application that can be re-use later on in completing a claim submission and later in a renewal form. However, to integrate the other systems to re-use the data from legacy system is difficult.

Not only for software, for hardware as well. Some modern application cannot always run in old system supported by old hardware (e.g. 16-bit to 32-bit or mainframe to PCs). A limitation like this was not a problem in the old days, but during the development in IT world, it becomes a problem because it is limited the movement (agility) of business nowadays. For commercial organization, if this limitation still continues, they have a risk of go out of the market.

Poor Architecture design. When application is made with monolithic architecture design, the connectivity

among the systems, more or less, is point-to-point. If n applications are connecting each other, it will produce n(n-1) number of connection or interface. Consequently, if system “A” need to be connected, it means the organization needs to generate, document, test and maintain 2n new connection. For instance, if organization has 5 applications with 20 interfaces, adding 6th application will require them add extra 10 new interfaces. It will increase the complexity as more applications are integrating each other. Moreover, an organization needs to modify the code in each of the application and resulting huge cost in maintain the systems.

It is also not easily configurable, when the new requirements are coming and require the developer to modify the code in the system. The developer has to find the line where the code needs to be modified. If developers or programmers are new and not familiar with the code, then it will take long time to change small part of the system. It makes even more difficult since each developer has his style of writing the code which can make other developer has to spend more time to understand the code.

All of those lead to poor architecture of the systems. The complexity of connectivity among systems is typical characteristic of the legacy systems. Sometimes, since legacy system is a core system, the other subsystems need to connect to it. Multiple systems had been added when the new requirements came. Function for printing, reporting and external connections are integrated with the legacy system. Even though it could be linked with other systems, the connection would be nasty and not in appropriate way (again because lack of documentation and expertise).

There is also the case that sometimes organization failed to remove the old system after new system was introduced. So, the new business processes are running in the new system and old business processes are running still in the old system. It creates redundant systems in the IT ecosystems of the organization. The maintenance will be difficult and expensive. However, for some organizations, they sometimes preserve the old system in purpose for compatibility reason in their ecosystem (e.g. services message provider organization). They do that to accommodate their clients who still use the old format of message. Although the cost for maintenance the old engine is perceived high, but as long as their clients are able to afford it, it works fine with them. Consequently, system is becoming big and large and contains complicated business rules as the time past over.

Such architecture often does not fit with the way people want to work and how the infrastructure work today. If the systems are not designed properly, it will run into trouble faster. The problem will be started when changes are made (inappropriate maintenance) and resulting the damage of the structure of the supplication. Figure 12 depicts the cause-effect relationship of factors that causes poor IT architecture and the consequences of having poor IT architecture.

Figure 12. Cause-effect relationship of "Poor IT architecture".

Related documents