Approaches aimed at increasing functionality with smaller budgets are frequently discussed at management level in established companies, but are rarely successfully implemented. The reasons for failure (or at least lack of success) of these projects cannot be attributed to general factors (e.g. company size) or even a few different factors; reasons specific to the company in question also play a role. It is clear that a successful approach must be implemented in various areas if the core of the entire process of relevant innovation is not to be abandoned.
But how should familiar and recurring topics involved in management discussions be organized? Besides the more predominant IT-driven topics such as make-or-buy decisions (standard vs custom development) and agile procedure models, it is typically about flanking changes within the organization (set-up, processes and culture), the ongoing question of opening up new business potential and focuses, as well as cost efficiency.
Using the example of a successful (or succeeding) transformation project in the company-critical business and IT area of insurance, it becomes apparent what factors are key to success according to our observations:
- Transferring strategy into a clear project vision
- Promoting an agile approach
- Empowering the existing organization
- Putting innovation before tradition
- Using modern technologies
1. Converting Strategic Objectives into A Clear Project Vision
In the strategy phase it is necessary to define the objectives of the program as well as the developed IT architectural target vision (taking into account market and product analyses) and the overriding requirements. In the concrete example, both end users and internal users were able to recognize benefits in terms of automation, convenience and speed when the system went live for the first time. The defined program objectives were successfully implemented in collaboration with heterogeneous teams. These teams consisted of internal employees with technical expertise as well as external development service providers from a nearshore sector.
The fact that a graduated program vision was applied, which was broken down into individual domain-based modules, was a major advantage. The long-term objective allowed for ensuing discussions on giving direction to the scope of medium-term implementation.
2. Agreeing on and Promoting the Agile Procedure Model
Transforming the scope and extent of a legacy system, which has developed into a new system over the course of time, poses a major challenge in terms of IT transformations. Focusing on the engineering requirements of logical and meaningful business transactions and adequately defining specialist domains for the purpose of implementation is fundamental to this. A consolidated knowledge base for the legacy system is often not available; having the documentation without usable learning effects for the further development of the system is of no use.
Agile procedure models can be used to solve these challenges. Agile project management was applied throughout in the case of the example too by adjusting project management principles for the purpose of fixing the budget, time and quality as well to systematically prioritize the scope. A dual governance of conception and realization was chosen in order to strike a balance between communication effort and the need for conceptual preparation for the implementation. This dual governance was able to meet requirements in terms of both agility and organization.
Figure 1: Dual Governance for the Project
IT and business were interlinked, with the organizational requirements for project management being met at the same time. Baselines were laid down in general classic organizational structures, contents and overarching business logics were harmonized. Agility was also able play its part in the realization.
Later on, initial technical concepts were adapted to the respective application areas. Technological architectural guidelines, tools and quality standards were also refined. The process originally involved company-wide topics and epics as rough clusters for the description of requirements, which were then described in more detail through means of user stories on professional domains and microservices.
Figure 2: Technical requirements and IT specifications in context
Free scaling of developer capacities with the support of the respective business analysts and team leaders in the defined procedure model allowed the project to grow to involve more than 70 employees. This meant that the realization was parallelized accordingly and the speed of the implementation increased as a result. The continuous prioritization and re-prioritizaton of the backlog of user stories that had been created and was constantly growing in the respective modules ensured the achievement of the necessary scopes within the time frame, while adhering to the defined quality guidelines.
3. Carrying Forward and Empowering the Existing Organization
Carrying out the transformation in a manner that is not independent of the existing organization (let alone against it) is essential for the success of the procedure. From the beginning, it was part of the project’s DNA to carry the existing organization forward and to involve it in the changes. This was partly due to the continuous involvement of internal forces at all levels. It was also due to the fact that willingness to recognize the fundamental incompleteness of the software and applications could be promoted on a cultural level and, furthermore, it could help to shape the ongoing development.
4. Putting Innovation Before Tradition
Questioning logic, processes and functionalities is necessary in order to achieve clarity in the thinking and development process when considering the objectives and the tools that are possible and necessary for these.
The business model and the question of how and with what means economic success is to be achieved was worked out in full and consistently for the purpose of basic orientation. On the basis of this, the premise of full focus on customer benefit was applied in terms of speed, flexibility and service. The necessary derivations for designing the new IT application environment were sometimes complex but was necessary overall.
Outdated logic in defining the product and contract, sedimented processes based on backward technologies and rudimentary business transactions, which are regarded as prerequisites for the use of the new platform, were permanently questioned and optimized through means of innovative approaches as part of the procedure. As part of this, the core of the actual content always had to be extracted and viewed in relation to the customer benefit as well as the capabilities of modern technologies. This not only meant that innovations were devised but also communicated to employees in an understandable way by means of practical use cases. The final derivation for the insurance company in the sense of a further development of the organizational structure could actually gain credibility upon the actual realization.
5. Using Modern Technologies and Development Paradigms
Even in the early stages, it is necessary that technology and architecture not only fulfill the requirements of flexibility, security and continuous development, but also offer significant support to these.
Over the course of the project, a highly individualized platform with standardized components was identified as the best solution for mapping the client’s business requirements. Therefore, a microservice architecture with event-driven data retention was designed that offers high levels of flexibility and agility. The microservices defined by professional domains in terms of scope of functions and data retention are decoupled from one another, thereby allowing a high degree of modularity, maintainability and interchangeability. The technical separation of the services enables intensive further development by independent developer teams with corresponding flexibility in terms of resources. The integration of standardized and overarching components has been implemented on an ongoing basis.
As regards the operation, the basis for excellent performance, scalability and availability has been ensured by consistently using modern open-source models and cloud-based approaches (e.g. Docker and Kubernetes).
Short innovation cycles featuring high reaction speeds and agility in a dynamically individual market are a clear competitive advantage from the customer perspective. By consistently using new development paradigms and state-of-the-art technologies, releases and live settings can be virtually automated in real-time by means of continuous delivery and deployment. As a result, new functionalities can be continuously and productively set up in iterative cycles for the customer and the further development of the system. This enables the system to be adapted quickly so it can be developed further in line with requirements.
Regulatory requirements were met to a large extent thanks to the transparent and event-driven communication. All changes to the system’s master and transaction data are historicized, i.e. marked according to date and author – with retraceability and documentation of previous states. In the area of business intelligence and reporting, this enables maximum scope for design and freedom in terms of reading, evaluating and interpreting the data. This also ensures future-proof flexibility with regard to future reports and requirements.
In light of aging technologies, comprehensively transforming existing IT application environments is as necessary as it is challenging in large parts of the finance industry. The reasons for this need lie in the widespread technological limitations of legacy systems as well as there being a cost-benefit ratio which is no longer tenable when it comes to operation and further development, especially with regard to the anticipated future requirements of the market. The structurally disproportional set-up of capacities for ensuring regulatory and process security required in this initial situation is an additional burden, or rather motivation, in terms of a comprehensive transformation.
The high complexity of the task requires special measures, in particular the successful interlinking of the success factors described. The success of the transformation cannot be guaranteed through this interlinking but, based on our experience, the probability of the implementation being successful can at least be significantly increased.