• BA As Detective
  • IIBA Podcast Episode 4: User Experience
  • Why Agile isn’t Enough Part 4: Lean Startup Learn Phase and BA Techniques that Enhance it
Monday, 16 February 2015 12:14

5 Considerations When Taking an Enterprise Architecture Approach to Core System Transformation

Written by

Jackson Feb13

Many financial organizations find that it’s easier to just keep patching old technology rather than to make the kind of major changes to their core systems needed to become the business they really want to be. So, they keep pushing major transformations off, until one day the risks of maintaining the status quo become overwhelming.

Unfortunately, when legacy/core modernization projects are under time pressure, they often fall victim to the very issues that their solutions are meant to address—inefficient business processes, redundancies, and information not getting to the appropriate people at the right time.

Ensuring that one of the most challenging initiatives an organization undertakes is done correctly requires a holistic perspective that considers not just the IT questions, but also addresses the processes, resources, and more.

Taking an EA Approach

Leadership at one insurance company came face-to-face with these issues when it identified the number one risk to its future: aging legacy systems supporting critical policy administration functions. Its enterprise analysis approach had five key aspects:

1. Architecture First

To enable business growth and change, the insurer established an enterprise architecture (EA) group. The EAs completed a comprehensive inventory of the various capabilities across the company, including those involved in policy administration. This let them focus on the aspects of the business that would be impacted by the change.

2. A Product Prism

Product architecture is often overlooked in discussions of systems transformation. However, when looking at its product offerings, the team discovered that two major divisions within the organization structured their insurance products differently and used the same terminology in different ways. If not corrected, or at least identified early, this situation could negatively affect being able to bring in a new policy administration solution created to unify the company’s work.

3. Business Processes

The inventory the EAs created allowed for the creation of a hierarchy of the business processes currently in place. A significant portion of the project was spent eliciting and documenting information about as-is processes and where they could be improved. This is an excellent example of focusing on process and using software as an enabler of process, rather than building your business around someone else’s code.

4. Attention to Systems

When an organization looks to retire legacy systems, there needs to be a clear understanding of the interfaces and interactions that the new solution will need to maintain. Those connections include the links both internal to the organization and external.

5 Tools to Use

The amount and critical nature of the information gathered in this process is difficult to track using such tools as Word or Excel. A relational repository is needed for all enterprise architecture artifacts as well as for documenting and managing requirements and tracing them to business goals.

Next Steps

Transforming an organization’s core systems is not an easy undertaking, yet a considered, thoughtful approach can mitigate the risks and help an organization take a significant step toward achieving its long term vision.

Don't forget to leave your comments below.

Read 10694 times
Doug Jackson

Doug Jackson is Sr. Director, Requirements and Business Analysis Practice for Robbins Gioia. A key contributor to “The Problem with Requirements: Why is it Still a Problem?”, he is a certified business analysis professional with over 20 years consulting and practitioner experience in all areas of business analysis.

© BA Times.com 2019

macgregor logo white web