For example, Seilevel worked with a health insurance company that upgraded its claims processing system to a new COTS system. The new system degraded KPIs for several departmental processes and further improved the organization`s core KPI (administrative cost per member) by 100%! This thread represents an actual discussion that reflects a specific set of circumstances. While Don and I believe this approach can be useful in a variety of projects, it may not be suitable for all situations. In this case, the old system had to be replaced due to specific technological risks. The system was vast and complex. There were thousands of business rules. The underlying business processes, rules, and data structures should change only moderately. Reusing the business rules contained in the old system made sense, but reusing the legacy code itself did not. There are a number of alternative approaches to modernizing existing systems and initiatives to improve business processes. We look forward to discussing this with you in future broadcasts. Our client has undergone a fairly significant overhaul of business processes and wants to implement these new processes with the new system. The new process design is designed to be much more efficient, save money and improve customer service.
Their current old system limits their ability to deploy these new business processes, and they want to make sure the new system is designed for new processes and not old ones. Drive 1: Since rules are mostly hard-coded and code step-by-step in mainframe systems takes too long, what is the best way to extract business rules from legacy systems without using the tools? On the other hand, retiring a legacy system to meet regulatory requirements, reducing licensing and maintenance fees, or adding additional/enhanced features that increase business value are all reasons that typically add value to a business. Therefore, you should carefully select and plan the business analysis techniques that you will use when collecting requirements. For example, in this situation, brainstorming challenges may be “groupthink” or “dominant personality” when the group focuses on a dominant idea. Defining the scope of the new system is very important in a replacement project. While the scope is known, there is a risk that certain types of features will be harder to freeze and wait for the new system because the old system is an active system. This is often the case in highly regulated industries (finance or government) where legislation is constantly evolving. Don Estes & Associates is an independent vendor consultant for vendors, governments, and private organizations specializing in BPM applications, modernization and targeted reuse of existing assets, and risk management associated with large IT projects.
Don is a graduate of MIT and the University of Texas. www.donestes.com, send an email to donestes[at]donestes.com. Next, consider future requirements, processes, etc. Only then are you ready to consider an alternative. It can be a direct exchange 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. Don Estes: Hi Mark, I want to schedule a demo of a tool I`ve used in the past that can help us extract the details of business rules from the old system. This is an important part of the re-engineering and legacy modernization services required for this project. Legacy systems are older computer systems that haven`t been updated in years, sometimes decades. They still serve a specific purpose, but their functionality has likely changed over time and the programming language they were created with can be outdated and difficult to use when changes need to be made or bugs need to be fixed. For this reason, many companies prefer to move away from legacy systems and upgrade their software systems to something newer and easier to use. The old system has been around since companies were able to use computers to track financial information, inventory, etc.
The legacy system name comes from the fact that these types of systems often stay in place long after their manufacturer no longer supports them – like an old computer that you can`t get rid of because it`s still running your favorite programs and files. If you don`t know how to manage the legacy system, you may encounter issues that can hurt the business. That is why I appreciate your proposal for a two-pronged approach. The addition I would make is that any rules “as is” extracted (either from the system or from interviews or observer users) should be subject to meaningful and critical scrutiny. Ideally, complex business rules should be reduced to their simplest essence so that they are easy to understand and there is no ambiguity. Thank you Don, understand and agree with your comments on the notion of completeness in general, but I would also say that many of these old invisible business rules built into the old system may no longer be relevant. In fact, some may inhibit the organization in a way it doesn`t understand, because they don`t even know the rule exists. 2. Find out who is responsible for maintaining the system code. Somewhere, there is a developer who is currently doing this or who has already written code for the system.
Talk to them as they can probably give you technical data about the system. We suspect that the agency itself does not know all the rules in sufficient detail for them to be implemented. The rules built into the old system were developed and continuously modified in production for 30 years. It was estimated that at least 15% of the system`s business logic required annual change to keep pace with new or changing federal mandates, legislative changes and changes in agency policies. Some of the original design, implementation and support people have retired. 3. Does your company have technical architects? If they do, it will also be good to talk to them, as they will be able to advise you on how the system fits into your technology stack – which systems depend on it and which ones depend on it themselves? Note: If you talk to the technical architect, you will get different information than the developer.