Forums for the Business Analyst

 
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Where to start documenting a Legacy System
Previous Previous
 
Next Next
New Post 1/23/2020 7:15 AM
User is offline Rosie D
2 posts
No Ranking


Where to start documenting a Legacy System 

Hello, I've been tasked with documenting one of our legacy system.  Oh and by the way, the only documentation is the code base.  I've started with the intergrations, since that will allow the team to look at the poslibility of finding a vendor to possibly help with parts of this.  

I've documented legacy systems in past with documentation available.  Any advice would be much appreciated.  

 

 

 
New Post 1/23/2020 11:24 PM
User is offline Stewart F
96 posts
7th Level Poster


Re: Where to start documenting a Legacy System 

Hi Rosie

What is the main ambition of the project? Is it to replace the system or upgrade it for example?

Knowing what the main reason for doing this is will enable us to understand what you are trying to achieve. So, does your documentation need to be more technically slanted or more process driven?

My first steps would be:

1. Get full access to the system (if you haven't already). That way you can document screens and User journeys throughout the system. Make sure it is full access though, not just a Customer's access. 

2. Find out who is responsible for the code maintenance of the system. Somewhere there is a developer who either currently does, or previously had written code for the system. Speak to them as they will probably be able to give you some technical data about the system.

3. Does your company have Technical Architects? If they do, then they will also be good to speak to as they will be able to advise you how the system fits in with your technology stack - what systems are a dependency to it, and those that depend on it themselves? Note, speaking to the Technical Architect will give you different information from the Developer. The Developer should be able to tell you about the workings of the system you need to document - what it's failings are, how much time and effort it needs to bring it up to scratch, known issues etc.

4. Can you also find out who was previously the Product Owner for that system? If you can (and your company has them) then you may be able to find out what plans were considered (and why they weren't implemented) for the system.  

 
New Post 1/27/2020 1:23 PM
User is offline Rosie D
2 posts
No Ranking


Re: Where to start documenting a Legacy System 

Thank you Stewart, the ultimate goal is to either replace or update what we have.  I've been tasked with mapping out the external integrations first so that we can determine if there are any 3rd parties that can handle the communication with the brokers and commodities exchange.    This will determine what pieces we will have to rewrite.  

Little background, the current application we use has external interfaces with Brokers and with the Commodies Merchantile Exchange.  Best case would be to find a vendor that has something we can use vs rewriting.  

I have already begun discussions with the developer, and want to come up with an outline so that we don't get off track.  With regard to the Product Owner, I have identified her and will be able to get her information when necessary.

We do not have a technical architect, I will be doing my best to document the systems dependancies.  

 

 

 
New Post 1/29/2020 7:33 AM
User is offline Stewart F
96 posts
7th Level Poster


Re: Where to start documenting a Legacy System 

HI Rosie D,

You seem to have most things in hand then really. The Product Owner or Developer (ask both) should have some documentation for when that legacy system integrated with the external Interfaces. Its then a question of working backwards. 

I would suggest (which its sounds like you already are) a simple flow diagram type approach where the Interfaces are shown. Then have a secondary diagram for each individual Interface which outlines in greater detail they key parts to each of them (what dependencies are, what data is passed between the two, if there are other interface dependencies etc)

Was the legacy system a 3rd party platform or did you build it yourselves?

A word of warning:- speaking to multiple 3rd party vendors is draining ! They go on for ever, and tell you very little. Make sure you have a cold drink and some snacks to keep you going !!

 

 
New Post 1/30/2020 2:53 AM
User is offline Kimbo
450 posts
5th Level Poster


Re: Where to start documenting a Legacy System 
Hi Rosie and Stewart

I suggest modelling the as-is business requirements. Interfaces are important but really just a side issue. The system is supporting business processes and functions. Any new system will have to do the same. So you must understand and model what they are first.

Then you consider the to-be requirements, processes etc. Only then are you ready to consider a replacement solution. It may be a straight swap with another system or even several or even replacing that system and one or two others with one. There may even be manual processes or outsourced processes.

Remember, business requirements drive solution, not the other way around.

Kimbo

 

 
Previous Previous
 
Next Next
  Modern Analyst Forums  Business and Sy...  Structured Anal...  Where to start documenting a Legacy System

Community Blog - Latest Posts

Gen1us2k
Gen1us2k
Most of the IT projects imply constant cooperation between the team members and customers. Although it might be often overlooked, the role and the importance of the client within the project is very crucial. Thus, it is in your interest to build a strong relationship based on trust. However, gaining trust on a single occasion is not a dealmaker &md...
0 Responses
emorphistechno
emorphistechno
Introduction In today's world, most enterprises work aggressively to achieve a higher level of business growth, which is made possible by leveraging one of the best automation technologies. One such technology is Robotic Process Automation (RPA) that plays a vital role in streamlining the customer experience in the most profitable manner.&nb...
0 Responses
Nick Stowers
Nick Stowers
Introduction   When I was introduced to scrum, the burndown chart was a tool that was highly emphasised however I feel the purpose has changed from it being a tool to predict (to a certain level) timescales for delivery to a tool that measures a team’s productivity…..in other words, the focus is on the number of points clear...
0 Responses






Latest Articles

Copyright 2006-2020 by Modern Analyst Media LLC