Dealing with pre-relational network databases has long been the domain of specialist DBAs. Unfortunately, this talent pool is shrinking rapidly as IDMS specialists retire in droves, driving up maintenance costs, creating scarcity and compounding risk. To complicate matters, in today’s digital transformation-centric IT landscape, dynamic integrations and a broad view of organisational data is now vital for management reporting, business intelligence, analytics and decision support.
So what do you do when critical data from important lines of business is locked up in legacy databases that are incompatible with modern data management solutions? For most organisations working with legacy databases, the first impulse is to manage the problem internally. However, resources are often an issue, along with priorities, so at what cost does this come to other projects? Overcoming legacy data may be more important than these other projects, but if it takes three times as long with a lower probability of success due to lack of experience, the migration will suffer. Let’s take a look at what IDMS modernisation options are available.
Maintain status quo
The first choice for any scenario is always to do nothing and ‘let it play out’. As time passes, dealing with data issues becomes more difficult as data is increasingly less accessible, there is an increased requirement backlog and more money is used on repeat / rework due to the lack of IDMS specialists available. By choosing this approach, organisations will not able to reap the benefits of the following best practices:
- Business intelligence and data warehousing
- 360 degree views of business entities
- Cross-functional, cross-disciplinary systems
- Extensive development / DBA community
With this approach, data integration solutions will be required to share data, whether this be between departments or through business-to-business data exchange. This is important to consider as The Digital Business Report 2020 found that 43 per cent of respondents agreed that a lack of integration between core applications has held them back from doing their jobs effectively.
SQL bridge-to-legacy databases
SQL bridge-to-legacy databases simulates SQL access to a non-relational database like IDMS. This approach works well for small, straightforward requirements, but not for more complex queries which are typical of reporting / business intelligence / analytical applications. Success in this approach is dependent on using the non-relational database schema. However, this concept is inherently flawed as the non-relational database is ill-suited for modern usage.
IDMS has also historically been well renowned for its speed, and this was one of the many reasons organisations opted for IDMS, yet adding a bridge is going to harm its performance. Additionally, this approach is very resource intensive for the mainframe as well as having expensive licensing fees. It’s important to note that this option does not resolve the resource challenge, as IDMS specialists are still required.
Extract, transform and load (ETL)
Extract, transform and load is a technology architecture that gathers data, usually in batch mode, from various data sources into a single data store (data warehouse, data mart or repository). This is achieved by integrating the data and providing it with a common structure.
Since it typically involves IT experts doing their own custom coding, ETL is one of the most common data integration methods used in the marketplace, although it is the most limited. Hand-coding greatly reduces efficiencies of scope and scale as there’s no rigidly defined process, so data integration can be inaccurate or incomplete. In addition to the risk of human error, the hours and effort required to integrate data manually, drives up the cost of labour.
Large processing overheads carry a heavy infrastructure footprint that can affect the entire enterprise architecture. So although ETL can help ‘get the job done’, it does so in a way that creates additional complexity and challenges around cost, scalability and maintenance. ETL demands specific requirements up front and ties the process to those requirements. Our recent 2020 Mainframe Modernisation Business Barometer Report found that 85 per cent of respondents prefer an agile approach to modernisation rather than a waterfall approach. However, ETL does not promote agility.
IDMS refactoring
Automated IDMS refactoring includes the generation of a new relational database to replace the functionality, set relationships, indexes and data structures that are currently part of the IDMS network database. The new target database can reside on or off the mainframe, and can use any of the standard relational database management systems (RDBMS): Microsoft SQL Server, Oracle or IBM Db2.
The automated technology protects legacy assets, reduces maintenance costs, provides agility and flexibility, and allows REST service creation with business-critical applications. The resulting database is fully relational. Primary keys, foreign keys and index definitions are automatically created. All constraints are generated into the resulting DDL. Table spaces, indexes, table names and column names are all generated according to your naming standard.
To find out more about the best practices and must-haves when choosing migration solutions, watch our on demand webinar. We share real-world examples of successful IDMS modernisation projects, including how we recently modernised 54 databases holding 6.3 billion records in under 24 hours at the Department for Work and Pensions.