Jayson ReadProject ManagerEden Prairie, Mn, United States
I've been tasked with documenting a system as it works today. The intent of this document is to:
1.Build the structure for addressing a whole system rewrite in current technology (.Net vs. VB6)
2.Use as a comparison against vendor applications to determine where we’re missing in the industry and what niches we can outsource to a vendor as opposed to writing ourselves
3.Use as a comparison against enterprise-wide applications in our own company to see what’s missing from our enterprise solution
We want to keep this at a higher level so we can get through the task but we still want to get into some of the detail to really identify where we’re missing when comparing to vendor solutions and our enterprise solution.
Has anyone gone through this exercise and can you lend any insight into how to approach this? Thanks in advance.
Saving Changes...
Jayson,
You might want to start with documenting what elements are critical to the success of the project/application and add the level of detail to each success factor. When adding the level of detail, I would focus on adding the business rules first, followed by requirements related to user tasks, system tasks, user-friendliness, standard “global” features across the application, reporting capabilities, performance etc. You might want to rate the priority of these features and rate the existing system, the vendor system(s) and your in-house/custom system against each feature.
Please also consider that a system re-architecting effort is a great opportunity to streamline your existing processes so, you might want to document what you want the system to do and not simply what it currently does.
Good Luck!
Saving Changes...
Hans RobbersSenior Director| SalesforceVlissingen, Netherlands
The basis to work from is the code. There are some automatic translateres dependent on the code it is written in which might give you a head start. Most of the times you need to make human correction afterwards.
The process you are describig is known uder the term reversed engineering and can be easily googled.
Finally, dependent on the budget available I would suggest to outsource this work to India. Fast and cheap ad a good quality.
Good luck
Hans Saving Changes...
Anonymous
I've re-engineered old systems, cross-complied language-to-language, migrated platform-to-platform and upgraded code bases. None of it was pretty, easy or particularly effective.
Most commonly the business has moved on from where the current system ended. The current system may well be impeding doing business today. So reproducing it again onto newer technology may not be what your company needs at all.
It's best to document the business functions the current system supports and then either buy or build a solution that best meets todays business needs.
I'd focus on the business process 1st - that is implemented thru technology. I'd ignore the code completely (except if and when necessary to understand the business functions).
You could use modeling tools like Visio (IDEFO templates) OR you could use iRise / user stories approaches.
From this you could map to vendor packages functionality AND you could use the same outputs as input on an engineering exercise if you decided to go that direction.
Last time I dug into old code I found 20% dead code and significant defective code. cross compiling and reverse engineering will only ascerbate the problems and architectural limits implicit in the current systems and perhaps impede your ability to develop further business functionality.
Good luck! Saving Changes...
Brett KriegerPrincipal| Common VisionMelbourne, Victoria, Australia
I have worked on a few "legacy system replacement" projects and have typically found the following approach to be the most useful when assessing functionality for either rebuild or COTS product assessment:
1. Start by identifying the key functional areas/groups covered by the existing system (e.g. billing, inventory, accounts payable, security etc.). It can be worthwhile to survey the market to compare a "short-list" of third-party products by functional area.
2. Start with the primary (most important) area and identify the names of the most important functions the current system provides in that area (any one of UML Use Case names, User Stories or plain old Functional descriptions are useful for this) - Use Case diagrams can be quite useful for providing the overview - you only want the names at this stage)
3. Depending upon the time available, elaborate the Use Cases or stories via descriptions focussing on the most important functions first.
Two other things to consider:
1. Once you've identified the major functional areas, check with the Stakeholders that you've you've covered off the breadth of functionality before you go into too much depth in any single area.
2. Beware of documenting the existing system in too much detail, focus on the capabilities they provide rather than the how (newer COTS products may deliver the same capabilities/functions in a better way).
Jayson, Tim Briscoe is hitting the nail on the head. It sounds to me like your company is trying to save money by leveraging the financial commitment they've already made in the legacy system. Unless you can document some real savings and really provide a ROI - you'd be better served green-fielding a solution.
While this path will have some start-up costs, it would allow - even in pilot/proof of concept mode a demonstration of how the new system will provide equivalency with the legacy system. Most mature businesses have fairly well articulated processes, these would also include those manual processes that were never automated due to some reason forgotten by everyone but the guy who is retiring today...
Articulate the business processes as they are being executed, show how the new platform/system can deliver the function at an X% reduction in cost for Y$$ and you'll easily make the sale. . Saving Changes...
Selva Saravana PuvananthiranDelivery Lead Senior Manager| Accenture Solutions Private LimitedChennai, Tamil Nadu, India
I would approach in the following ways:
1. Identify the stakeholders, specifically the users, of the system that you are trying to identify the as-is process.
2. Setup meetings with them to go through the functional areas and start documenting them
3. Once you consolidate the functional needs, you may start analyzing whether you can buy a COTS package or build it in-house or outsource to satisfy the functional needs.
In my current client, the process starts with interviewing the business unit to identify and document their needs and then shop for COTS packages available in the market. Once you have a list of vendors, we will request the RFI from each vendors. Then it goes through the appropriate channels to choose a specific vendor.
It all starts with interview, conversations with appropriate stakeholders...
