English | EN 
A story on how to enable innovation on legacy systems – and make use of the power of integrations
Integration with legacy systems is about as exciting as the legacy systems themselves, they are mostly based on old technology and the changeability follows the system.
A story…
The business needs to migrate the mainframe computer, you choose to migrate 1-1 because you do not consider it either advisable or dare to make changes. With some luck, you get the same legacy on a new platform!
Implementing this type of migration entails challenges throughout the chain from requirements to delivery. Not only technically but also organizationally.
At worst, there is no mainframe competence in the organization that has overall knowledge about the system, or who can read and understand old source code. The business may have created procedures to circumvent problems and peculiarities found in the old system, which are not necessarily documented.
So, if you have now migrated 1-1, have you succeeded in creating a future-resistant source code or will the functionality be broken on updates to OS and platform?
The design of the original system was based on completely different conditions than the new one. How easy is it to change?
The story could have taken another turn
One could have done a (time-consuming) pre-study and captured the company’s needs and requirements. Look at the information to be handled in the system and the capabilities required to meet the needs. One might have had a while to consider how workflows and processes can be improved and build a solution that fits the same. Design a solution that is quite easy to maintain and change.
Unfortunately, either way, one is faced with about the same issues as at 1-1 migration even in this way, in terms of business-critical knowledge and possible circumstances not documented.
End of story …
From my point of view, the mainframe migration itself is not the focus. The focus should be in how the business evolves and changes.
Yet another option.
If you build an API on top of the legacy/back-end, it may be possible to abstract the core and get the opportunity to update parts of legacy/back-end without affecting the information consumers. This would allow updating the legacy/back-end one part at a time.
In the same way that business becomes more change prone and more agile, processes and IT-services must change. The opportunity to create APIs on top of back-end and legacy systems and create a layered architecture with layers that abstracts information models and creates opportunities for creating front-end services. This will also allow short iterations for development. It will also allow exposure of APIs on which one can create innovation!
Integration is not only needed to connect the different layers in a layered architecture, it is also needed for connecting services consuming exposed APIs. This is when integration becomes interesting!
The layered architecture opens to use different technologies, with loosely coupled services. This includes both services and integration.
As in my earlier blog posts, I return to the core – the information. The needs and the capabilities that exist around the information are those that govern choice of both architecture and technology.
Reference architecture e.g. Digitechture
