By Philippe Magne <\/h3>\n<\/div><\/div><\/div>Summary<\/h2>\n\n- Define the target<\/a><\/li>\n
- Engage rapidly in “tooling”<\/a><\/li>\n
- Adopt a policy of “quick wins”<\/a><\/li>\n
- Communicate all-round<\/a><\/li>\n
- Make the upper management a stakeholder<\/a><\/li>\n<\/ol>\n<\/div>
The BFSI sector (Banking, Financial Services, Insurance) relies heavily on the use of\u00a0legacy\u00a0<\/strong>(or as IBM would say, heritage) platforms, such as mainframe and IBM i (aka iSeries, AS\/400) for their most crucial \u201cbusiness-critical\u201d applications. \u00a0Many users have simply \u201cforgotten\u201d that these back-end systems exist thanks to their various front-end mobile or web interfaces \u2013 however these applications are very much in existence and delivering stable core functionality.\u00a0 They fulfil not only the most valuable of business goals and revenue streams but are also a key part of these organisations\u2019 future strategic direction.<\/p>\nThe essence of all BFSI companies is risk management. This is probably the main reason why these legacy systems are still part of the IT landscape. Whilst there are many IT outsourcing companies and migration tools<\/em> providers whose business model and profit motive are to \u201crip and replace\u201d these legacy applications, migrations like this tend to be fraught with difficulty and go against all the \u201crisk management\u201d based goals of most BFSI organisations.<\/p>\nBut how is it that in this day and age we can still imagine replacing them with other \u201cbetter\u201d or more \u201cmodern\u201d alternatives while keeping the risks of migration perfectly under control? The number of companies that will dare to take such a risk is shrinking by the day.<\/p>\n
To balance this, of course the strategy of \u201cchanging nothing\u201d would be just as risky for one main reason: “the age pyramid”. Let\u2019s face facts – in the next 5 to 10 years, 75% of existing legacy skills and development resources will be moving into retirement.<\/p>\n
Most executive management teams with BFSI as part of their risk management strategy have fully understood the challenge and the urgency of achieving a \u201cgenerational transition\u201d. \u00a0There is a real consensus that this means going through a\u00a0DevOps<\/strong>\u00a0transformation. \u00a0It is increasingly clear with BFSI\u2019s that by organizing development in a more agile way and equipping teams with modern tooling that we can attract and retain young talent to eliminate the risk of the \u201cageing population\u201d holding legacy skills.<\/p>\nFrom strategy to implementation, there is however a definite \u201cjourney\u201d to undertake, with many obstacles on the way, and \u201csolutions\u201d needed to succeed. \u00a0The purpose of this article is to offer you guidance and advice to secure your DevOps transformation and give you back control to eliminate the \u201cbusiness risk\u201d you face.\u00a0The advice contained in this document is based on both over 5 years of experience of implementing a DevOps strategy and also a proven track record of success working with companies across the world in many of the world\u2019s most successful and innovative BFSI\u2019s organisations and their IT suppliers.<\/p>\n
The 5 key steps are:<\/p>\n
<\/div>\n1. Define the target<\/strong><\/h2>\nIt may sound basic as a first piece of advice, but too many people start off with relatively unclear goals, simply because\u00a0DevOps<\/strong>\u00a0addresses three levels: strategic, managerial and technical. \u00a0For this reason alone it is worth taking a little time to define the milestones of a transformation that, in any case, will last several years and for which the stakes are vital. A clear\u00a0roadmap<\/strong>\u00a0integrating all milestones of the change with precise deadlines will guide all those involved, from the developer through to the management, including the security and operations teams. The objective in a sense is to \u201cdownplay\u201d these\u00a0legacy <\/strong>systems, consider them a technology like any other, and most importantly, demystify them completely for the younger generations. \u00a0Because in the end, experience shows that the only barrier is a set of preconceived ideas that are readily dropped in practice.<\/p>\nCertain goals are inter-related, meaning they can be achieved simultaneously with minimal additional work, creating a “ripple effect” of achievement of multiple corporate objectives and goals.\u00a0 For example, increasing the level of automation in the deployment and release process whilst \u201cshifting the number of defects to the left\u201d implies:<\/p>\n
\n- By definition, the more automation in the deployment process, the more rapidly developers can test <\/strong>new functionality in a production-like environment and the more rapidly they can fix defects and re-deploy.<\/li>\n
- Increased automation ensures that developers do not spend their time performing \u201cmanual\u201d smoke testing or build verification testing on a recently deployed application, thus freeing up their time to pack more functionality into each release.<\/li>\n
- Advanced automation includes the ability to perform a seamless rollback<\/strong> in case of problems, therefore eliminating the risk of defects found late in the testing phase when they are more expensive.<\/li>\n<\/ul>\n<\/div>\n
2. Engage rapidly in “tooling”<\/strong><\/h2>\nUnlike application projects where you can spend time setting up “terms of reference” to ensure that the needs of all users are covered, it is almost impossible to do this in a DevOps strategy, because of the profusion of technologies in the distributed world.\u00a0 This is in complete contrast of course with the scarcity of choices available for legacy.<\/p>\n
The movement feeds on “good stories” that develop virally through the network and promote the rapid emergence of authentic standards. This is how the Git<\/strong> source management tool became a de facto standard in the distributed world in just a few years, and, as it happens, is now also a “must” for the Legacy code. Similarly, Jenkins<\/strong> as orchestrator of integration tasks is a natural fit. \u00a0Is it the best technology on the market? \u00a0The question is irrelevant. \u00a0It’s a standard<\/em>. Finally, we should also mention Jira<\/strong>, which has become a reference in project management.<\/p>\nThe goal then is to build a consistent and efficient DevOps chain. \u00a0Either your own teams have the skills (and the time) to do the integration themselves, or you rely on a vendor who offers you a global and already integrated chain. This is the value proposition of ARCAD Software.<\/p>\n
Tools are not the only driver for change but they do offer you a framework for continuous improvement and way to document and prove your DevOps is beginning to deliver value.<\/p>\n
<\/div>\n3. Adopt a policy of “quick wins”<\/strong><\/h2>\nIt\u2019s all about gaining buy-in by a proof by example. \u00a0Transitioning all teams to a multi-platform DevOps stack is far too ambitious. \u00a0Choose an initial application that contains a mix of different technologies.\u00a0 Do try however to cover the entire DevOps cycle in order to demonstrate the maximum value of the chain and go beyond a one-on-one comparison with what existed before. \u00a0We need \u201cquick wins\u201d to prove value, but not everything can be achieved all at once. \u00a0Instead of subdividing by phases, it is better to apply small changes step by step on each application domain.<\/p>\n
Some \u201cquick wins\u201d to measure include the increase in number of releases and the \u201cshift left\u201d of defects described above. However, from our experience a large number of intangible benefits are also gained from a \u201cquick win\u201d approach.<\/p>\n
In the past, typically IBM i \/ Legacy applications development teams have delivered a large amount of functionality in each relatively infrequent release (often 2 x releases per year with bug fix effort in between). In this context, application owners have tended to \u201cover pack\u201d both \u201chigh business value functionality\u201d with \u201clow business value functionality\u201d into each release to ensure they can leverage the benefits immediately as soon as the once the new release cycle comes around and the development team have released into production.<\/p>\n
With the advent of DevOps, we have seen a huge benefit from a natural \u201cprioritization\u201d of functionality. Since releases following DevOps are more frequent, the features that are the most \u201cvaluable\u201d (from the viewpoint of revenue generation or cost saving) can be delivered within weeks rather than months.<\/p>\n
Documenting these \u201cquick wins\u201d is very important to ensure you can prove to your stakeholders the success of your DevOps process on an ongoing basis.<\/p>\n<\/div><\/div><\/div>
Summary<\/h2>\n\n- Define the target<\/a><\/li>\n
- Engage rapidly in “tooling”<\/a><\/li>\n
- Adopt a policy of “quick wins”<\/a><\/li>\n
- Communicate all-round<\/a><\/li>\n
- Make the upper management a stakeholder<\/a><\/li>\n<\/ol>\n<\/div>
The BFSI sector (Banking, Financial Services, Insurance) relies heavily on the use of\u00a0legacy\u00a0<\/strong>(or as IBM would say, heritage) platforms, such as mainframe and IBM i (aka iSeries, AS\/400) for their most crucial \u201cbusiness-critical\u201d applications. \u00a0Many users have simply \u201cforgotten\u201d that these back-end systems exist thanks to their various front-end mobile or web interfaces \u2013 however these applications are very much in existence and delivering stable core functionality.\u00a0 They fulfil not only the most valuable of business goals and revenue streams but are also a key part of these organisations\u2019 future strategic direction.<\/p>\nThe essence of all BFSI companies is risk management. This is probably the main reason why these legacy systems are still part of the IT landscape. Whilst there are many IT outsourcing companies and migration tools<\/em> providers whose business model and profit motive are to \u201crip and replace\u201d these legacy applications, migrations like this tend to be fraught with difficulty and go against all the \u201crisk management\u201d based goals of most BFSI organisations.<\/p>\nBut how is it that in this day and age we can still imagine replacing them with other \u201cbetter\u201d or more \u201cmodern\u201d alternatives while keeping the risks of migration perfectly under control? The number of companies that will dare to take such a risk is shrinking by the day.<\/p>\n
To balance this, of course the strategy of \u201cchanging nothing\u201d would be just as risky for one main reason: “the age pyramid”. Let\u2019s face facts – in the next 5 to 10 years, 75% of existing legacy skills and development resources will be moving into retirement.<\/p>\n
Most executive management teams with BFSI as part of their risk management strategy have fully understood the challenge and the urgency of achieving a \u201cgenerational transition\u201d. \u00a0There is a real consensus that this means going through a\u00a0DevOps<\/strong>\u00a0transformation. \u00a0It is increasingly clear with BFSI\u2019s that by organizing development in a more agile way and equipping teams with modern tooling that we can attract and retain young talent to eliminate the risk of the \u201cageing population\u201d holding legacy skills.<\/p>\nFrom strategy to implementation, there is however a definite \u201cjourney\u201d to undertake, with many obstacles on the way, and \u201csolutions\u201d needed to succeed. \u00a0The purpose of this article is to offer you guidance and advice to secure your DevOps transformation and give you back control to eliminate the \u201cbusiness risk\u201d you face.\u00a0The advice contained in this document is based on both over 5 years of experience of implementing a DevOps strategy and also a proven track record of success working with companies across the world in many of the world\u2019s most successful and innovative BFSI\u2019s organisations and their IT suppliers.<\/p>\n
The 5 key steps are:<\/p>\n
<\/div>\n1. Define the target<\/strong><\/h2>\nIt may sound basic as a first piece of advice, but too many people start off with relatively unclear goals, simply because\u00a0DevOps<\/strong>\u00a0addresses three levels: strategic, managerial and technical. \u00a0For this reason alone it is worth taking a little time to define the milestones of a transformation that, in any case, will last several years and for which the stakes are vital. A clear\u00a0roadmap<\/strong>\u00a0integrating all milestones of the change with precise deadlines will guide all those involved, from the developer through to the management, including the security and operations teams. The objective in a sense is to \u201cdownplay\u201d these\u00a0legacy <\/strong>systems, consider them a technology like any other, and most importantly, demystify them completely for the younger generations. \u00a0Because in the end, experience shows that the only barrier is a set of preconceived ideas that are readily dropped in practice.<\/p>\nCertain goals are inter-related, meaning they can be achieved simultaneously with minimal additional work, creating a “ripple effect” of achievement of multiple corporate objectives and goals.\u00a0 For example, increasing the level of automation in the deployment and release process whilst \u201cshifting the number of defects to the left\u201d implies:<\/p>\n
\n- By definition, the more automation in the deployment process, the more rapidly developers can test <\/strong>new functionality in a production-like environment and the more rapidly they can fix defects and re-deploy.<\/li>\n
- Increased automation ensures that developers do not spend their time performing \u201cmanual\u201d smoke testing or build verification testing on a recently deployed application, thus freeing up their time to pack more functionality into each release.<\/li>\n
- Advanced automation includes the ability to perform a seamless rollback<\/strong> in case of problems, therefore eliminating the risk of defects found late in the testing phase when they are more expensive.<\/li>\n<\/ul>\n<\/div>\n
2. Engage rapidly in “tooling”<\/strong><\/h2>\nUnlike application projects where you can spend time setting up “terms of reference” to ensure that the needs of all users are covered, it is almost impossible to do this in a DevOps strategy, because of the profusion of technologies in the distributed world.\u00a0 This is in complete contrast of course with the scarcity of choices available for legacy.<\/p>\n
The movement feeds on “good stories” that develop virally through the network and promote the rapid emergence of authentic standards. This is how the Git<\/strong> source management tool became a de facto standard in the distributed world in just a few years, and, as it happens, is now also a “must” for the Legacy code. Similarly, Jenkins<\/strong> as orchestrator of integration tasks is a natural fit. \u00a0Is it the best technology on the market? \u00a0The question is irrelevant. \u00a0It’s a standard<\/em>. Finally, we should also mention Jira<\/strong>, which has become a reference in project management.<\/p>\nThe goal then is to build a consistent and efficient DevOps chain. \u00a0Either your own teams have the skills (and the time) to do the integration themselves, or you rely on a vendor who offers you a global and already integrated chain. This is the value proposition of ARCAD Software.<\/p>\n
Tools are not the only driver for change but they do offer you a framework for continuous improvement and way to document and prove your DevOps is beginning to deliver value.<\/p>\n
<\/div>\n3. Adopt a policy of “quick wins”<\/strong><\/h2>\nIt\u2019s all about gaining buy-in by a proof by example. \u00a0Transitioning all teams to a multi-platform DevOps stack is far too ambitious. \u00a0Choose an initial application that contains a mix of different technologies.\u00a0 Do try however to cover the entire DevOps cycle in order to demonstrate the maximum value of the chain and go beyond a one-on-one comparison with what existed before. \u00a0We need \u201cquick wins\u201d to prove value, but not everything can be achieved all at once. \u00a0Instead of subdividing by phases, it is better to apply small changes step by step on each application domain.<\/p>\n
Some \u201cquick wins\u201d to measure include the increase in number of releases and the \u201cshift left\u201d of defects described above. However, from our experience a large number of intangible benefits are also gained from a \u201cquick win\u201d approach.<\/p>\n
In the past, typically IBM i \/ Legacy applications development teams have delivered a large amount of functionality in each relatively infrequent release (often 2 x releases per year with bug fix effort in between). In this context, application owners have tended to \u201cover pack\u201d both \u201chigh business value functionality\u201d with \u201clow business value functionality\u201d into each release to ensure they can leverage the benefits immediately as soon as the once the new release cycle comes around and the development team have released into production.<\/p>\n
With the advent of DevOps, we have seen a huge benefit from a natural \u201cprioritization\u201d of functionality. Since releases following DevOps are more frequent, the features that are the most \u201cvaluable\u201d (from the viewpoint of revenue generation or cost saving) can be delivered within weeks rather than months.<\/p>\n
Documenting these \u201cquick wins\u201d is very important to ensure you can prove to your stakeholders the success of your DevOps process on an ongoing basis.<\/p>\n<\/div><\/div><\/div>
The BFSI sector (Banking, Financial Services, Insurance) relies heavily on the use of\u00a0legacy\u00a0<\/strong>(or as IBM would say, heritage) platforms, such as mainframe and IBM i (aka iSeries, AS\/400) for their most crucial \u201cbusiness-critical\u201d applications. \u00a0Many users have simply \u201cforgotten\u201d that these back-end systems exist thanks to their various front-end mobile or web interfaces \u2013 however these applications are very much in existence and delivering stable core functionality.\u00a0 They fulfil not only the most valuable of business goals and revenue streams but are also a key part of these organisations\u2019 future strategic direction.<\/p>\n The essence of all BFSI companies is risk management. This is probably the main reason why these legacy systems are still part of the IT landscape. Whilst there are many IT outsourcing companies and migration tools<\/em> providers whose business model and profit motive are to \u201crip and replace\u201d these legacy applications, migrations like this tend to be fraught with difficulty and go against all the \u201crisk management\u201d based goals of most BFSI organisations.<\/p>\n But how is it that in this day and age we can still imagine replacing them with other \u201cbetter\u201d or more \u201cmodern\u201d alternatives while keeping the risks of migration perfectly under control? The number of companies that will dare to take such a risk is shrinking by the day.<\/p>\n To balance this, of course the strategy of \u201cchanging nothing\u201d would be just as risky for one main reason: “the age pyramid”. Let\u2019s face facts – in the next 5 to 10 years, 75% of existing legacy skills and development resources will be moving into retirement.<\/p>\n Most executive management teams with BFSI as part of their risk management strategy have fully understood the challenge and the urgency of achieving a \u201cgenerational transition\u201d. \u00a0There is a real consensus that this means going through a\u00a0DevOps<\/strong>\u00a0transformation. \u00a0It is increasingly clear with BFSI\u2019s that by organizing development in a more agile way and equipping teams with modern tooling that we can attract and retain young talent to eliminate the risk of the \u201cageing population\u201d holding legacy skills.<\/p>\n From strategy to implementation, there is however a definite \u201cjourney\u201d to undertake, with many obstacles on the way, and \u201csolutions\u201d needed to succeed. \u00a0The purpose of this article is to offer you guidance and advice to secure your DevOps transformation and give you back control to eliminate the \u201cbusiness risk\u201d you face.\u00a0The advice contained in this document is based on both over 5 years of experience of implementing a DevOps strategy and also a proven track record of success working with companies across the world in many of the world\u2019s most successful and innovative BFSI\u2019s organisations and their IT suppliers.<\/p>\n The 5 key steps are:<\/p>\n It may sound basic as a first piece of advice, but too many people start off with relatively unclear goals, simply because\u00a0DevOps<\/strong>\u00a0addresses three levels: strategic, managerial and technical. \u00a0For this reason alone it is worth taking a little time to define the milestones of a transformation that, in any case, will last several years and for which the stakes are vital. A clear\u00a0roadmap<\/strong>\u00a0integrating all milestones of the change with precise deadlines will guide all those involved, from the developer through to the management, including the security and operations teams. The objective in a sense is to \u201cdownplay\u201d these\u00a0legacy <\/strong>systems, consider them a technology like any other, and most importantly, demystify them completely for the younger generations. \u00a0Because in the end, experience shows that the only barrier is a set of preconceived ideas that are readily dropped in practice.<\/p>\n Certain goals are inter-related, meaning they can be achieved simultaneously with minimal additional work, creating a “ripple effect” of achievement of multiple corporate objectives and goals.\u00a0 For example, increasing the level of automation in the deployment and release process whilst \u201cshifting the number of defects to the left\u201d implies:<\/p>\n Unlike application projects where you can spend time setting up “terms of reference” to ensure that the needs of all users are covered, it is almost impossible to do this in a DevOps strategy, because of the profusion of technologies in the distributed world.\u00a0 This is in complete contrast of course with the scarcity of choices available for legacy.<\/p>\n The movement feeds on “good stories” that develop virally through the network and promote the rapid emergence of authentic standards. This is how the Git<\/strong> source management tool became a de facto standard in the distributed world in just a few years, and, as it happens, is now also a “must” for the Legacy code. Similarly, Jenkins<\/strong> as orchestrator of integration tasks is a natural fit. \u00a0Is it the best technology on the market? \u00a0The question is irrelevant. \u00a0It’s a standard<\/em>. Finally, we should also mention Jira<\/strong>, which has become a reference in project management.<\/p>\n The goal then is to build a consistent and efficient DevOps chain. \u00a0Either your own teams have the skills (and the time) to do the integration themselves, or you rely on a vendor who offers you a global and already integrated chain. This is the value proposition of ARCAD Software.<\/p>\n Tools are not the only driver for change but they do offer you a framework for continuous improvement and way to document and prove your DevOps is beginning to deliver value.<\/p>\n It\u2019s all about gaining buy-in by a proof by example. \u00a0Transitioning all teams to a multi-platform DevOps stack is far too ambitious. \u00a0Choose an initial application that contains a mix of different technologies.\u00a0 Do try however to cover the entire DevOps cycle in order to demonstrate the maximum value of the chain and go beyond a one-on-one comparison with what existed before. \u00a0We need \u201cquick wins\u201d to prove value, but not everything can be achieved all at once. \u00a0Instead of subdividing by phases, it is better to apply small changes step by step on each application domain.<\/p>\n Some \u201cquick wins\u201d to measure include the increase in number of releases and the \u201cshift left\u201d of defects described above. However, from our experience a large number of intangible benefits are also gained from a \u201cquick win\u201d approach.<\/p>\n In the past, typically IBM i \/ Legacy applications development teams have delivered a large amount of functionality in each relatively infrequent release (often 2 x releases per year with bug fix effort in between). In this context, application owners have tended to \u201cover pack\u201d both \u201chigh business value functionality\u201d with \u201clow business value functionality\u201d into each release to ensure they can leverage the benefits immediately as soon as the once the new release cycle comes around and the development team have released into production.<\/p>\n With the advent of DevOps, we have seen a huge benefit from a natural \u201cprioritization\u201d of functionality. Since releases following DevOps are more frequent, the features that are the most \u201cvaluable\u201d (from the viewpoint of revenue generation or cost saving) can be delivered within weeks rather than months.<\/p>\n Documenting these \u201cquick wins\u201d is very important to ensure you can prove to your stakeholders the success of your DevOps process on an ongoing basis.<\/p>\n<\/div><\/div><\/div>1. Define the target<\/strong><\/h2>\n
\n
2. Engage rapidly in “tooling”<\/strong><\/h2>\n
3. Adopt a policy of “quick wins”<\/strong><\/h2>\n
![\"ARCAD](\"https:\/\/www.arcadsoftware.com\/arcad\/wp-content\/uploads\/2018\/06\/banner-datasheet-arcad-for-devops-en.jpg\")
<\/p>\n![\"Philippe](\"https:\/\/www.arcadsoftware.fr\/arcad\/wp-content\/uploads\/2025\/06\/Photo-Arcad-Philippe-Magne.png\")
<\/span><\/div><\/div><\/div>