Legacy system: Difference between revisions

Latest revision as of 09:42, 8 January 2023

System Fundamentals^[1]

In computing, a legacy system is an old method, technology, computer system, or application program, "of, relating to, or being a previous or outdated computer system."Often a pejorative term, referencing a system as "legacy" often implies that the system is out of date or in need of replacement.^[2]

Legacy systems are usually still in use as opposed to retired (or archived) systems, which are no longer in use. Please remember this distinction.

Compatibility issues can arise in situations where a new system or technology must be integrated with an existing system or technology. These issues can be particularly pronounced in situations where the existing system is a legacy system, or in situations where two businesses are merging and their systems must be integrated.

Some common compatibility issues that can arise in these situations include:

Incompatibility of hardware or software: If the new system uses hardware or software that is not compatible with the existing system, it may be necessary to make changes to the existing system in order to enable the two systems to work together.
Incompatibility of data formats: If the new system uses data formats that are not compatible with the existing system, it may be necessary to convert the data between the two systems in order to enable them to work together.
Incompatibility of protocols: If the new system uses protocols (e.g. communication standards) that are not compatible with the existing system, it may be necessary to implement protocol conversion in order to enable the two systems to work together.
Incompatibility of processes: If the new system uses processes (e.g. workflows) that are not compatible with the existing system, it may be necessary to modify the processes in order to enable the two systems to work together.
Incompatibility of user interfaces: If the new system has a user interface that is significantly different from the existing system, it may be difficult for users to adapt to the new system and may require training or other support to enable them to use the new system effectively.

Real-world practical advice[edit]

When you are planning a new system you should include compatibility planning as part of your new system. If you are a system administrator, programmer, network administrator, much of your work will involve getting different systems to be compatible. It's always nice when you have a new system, new company, and a new process, but this isn't the norm.

There is a lot more to say about this, but my advice is to assume any system you are involved with needs to be compatible with other systems and legacy systems.

Standards[edit]

Outline compatibility issues resulting from situations including legacy systems or business mergers.

References[edit]

[1] ttp://www.flaticon.com/

[2] ttps://en.wikipedia.org/wiki/Legacy_system

[1]

[2]

@@ Line 3: / Line 3: @@
 In computing, a legacy system is an old method, technology, computer system, or application program, "of, relating to, or being a previous or outdated computer system."Often a pejorative term, referencing a system as "legacy" often implies that the system is out of date or in need of replacement.<ref>https://en.wikipedia.org/wiki/Legacy_system</ref>
-Legacy systems are usually '''still in use''' as opposed to retired (or archived) systems, which are no longer in use.
+Legacy systems are usually '''still in use''' as opposed to retired (or archived) systems, which are no longer in use. Please remember this distinction.
+Compatibility issues can arise in situations where a new system or technology must be integrated with an existing system or technology. These issues can be particularly pronounced in situations where the existing system is a legacy system, or in situations where two businesses are merging and their systems must be integrated.
-=== SL version ===
+Some common compatibility issues that can arise in these situations include:
-When you have a system that is working, it is common to get requests to change the system. '''There is a difference between a feature request, and a bug report'''. If something if isn't working, a user should file a bug report and report it needs to be fixed. If everything is working and the user wants to change it, we begin the change management process.
+# Incompatibility of hardware or software: If the new system uses hardware or software that is not compatible with the existing system, it may be necessary to make changes to the existing system in order to enable the two systems to work together.
+# Incompatibility of data formats: If the new system uses data formats that are not compatible with the existing system, it may be necessary to convert the data between the two systems in order to enable them to work together.
-The important thing to understand about change management is '''you MUST carefully consider all the possible ramifications of the change'''. Changes must be carefully planned, implemented, tested and then refined. We don't just make a change without thinking because this could create unintended problem later on. We could also create [[technical debt]] that we need to pay later.  Changes should follow the same process as building software (that is, the [[design cycle]]).
+# Incompatibility of protocols: If the new system uses protocols (e.g. communication standards) that are not compatible with the existing system, it may be necessary to implement protocol conversion in order to enable the two systems to work together.
+# Incompatibility of processes: If the new system uses processes (e.g. workflows) that are not compatible with the existing system, it may be necessary to modify the processes in order to enable the two systems to work together.
-Change requests usually originate from:
+# Incompatibility of user interfaces: If the new system has a user interface that is significantly different from the existing system, it may be difficult for users to adapt to the new system and may require training or other support to enable them to use the new system effectively.
-* problem reports that identify bugs that must be fixed, which forms the most common source
-* system enhancement requests from users
-* events in the development of other systems
-* changes in underlying structure and or standards (e.g. in software development this could be a new operating system)
-* demands from senior management (Dennis, Wixom & Tegarden, 2002).<ref>https://en.wikipedia.org/wiki/Change_request</ref>
-=== HL version ===
-Change management should be supported by a change management system. This is a system which tracks requests for change, assigns unique ID to a change request, and allows developers to collaboratively work on the change. Every part of a change needs to be recorded and tracked. See also [[version control]].
-The more complex a system is, the more important it is to manage change effectively.
-Finally, just because a user requests a change doesn't mean you should make it. Requests for change are related to the stability of a system. If a change would radically change the system, or make it less stable (or secure) the change may have to be denied. Please be careful, because systems must support users. If you do not change, your users will start using better systems.
 == Real-world practical advice ==
-"Hey can you change this one little thing for me?". This is a very common request. Here's the thing: users think a request is minimal, "no big deal" or "just a little thing". But because end-users don't have a full picture of a system, they do not have information to evaluate if a change is minimal or if it more involved.
+When you are planning a new system '''you should include compatibility planning as part of your new system'''. If you are a system administrator, programmer, network administrator, much of your work will involve getting different systems to be compatible.  It's always nice when you have a new system, new company, and a new process, but this isn't the norm.
-When a user asks you to change something, you should smile and take a deep breath. You should then spend time carefully understanding '''exactly''' what functionality the user wants and how you can best plan and implement the functionality.
-In larger organizations, there is a well-established Request For Change process which uses a change request form<ref>https://en.wikipedia.org/wiki/Change_request</ref>. Always think before you make a change.
-== Do you understand this material? ==
-This is a simple example:
-A small business has a computer kiosk inside the store which allows customers to sign up for a email newsletter. If a customer signs up for a newsletter inside the store, they will get a 10% discount on their first purchase at the store. The owner hopes this 10% discount will be an incentive for customers to sign up for the email newsletter.  The business will then regularly  email the customers special offers and savings. The business owner expects to benefit from this system by having increased sales. The customers expect to benefit from this system by having access to special offers, to save money, and to see what is new and trendy at their store.
-'''Change request:''' The customers ask the business owner if they could also add their mobile phone number, as they would like to get a text message if the store is having a sale.
-Question 1: Describe '''why''' we should carefully manage this change process.
-Question 2:  List the steps you would take to make this change (what would you do first, then next, then next).
-== Do you have an advanced understanding of this material? ==
-A school of 900 students has a secure web-based application which manages attendance data. The school administrators carefully track attendance for the students so it can identify when students have been absent for a customizable threshold. For example, the school might set a threshold of 5 absences within 30 days, which then automatically notifies the student, parent, and teacher there is a problem with attendance. The threshold might be 3 times within 10 days, or something like that. The system keeps track of attendance and tardies. The system has customizable attendance codes. For example, "absence for school trip", "excused absence", "medical absence" are all allowed absence codes.
-School administrators expect to benefit by having data about attendance so they can support students and parents to be in school. School administrators also expect to benefit by giving parents and students information about attendance (so parents can support their children to be in school). Finally, school administrators expect to benefit by using attendance data to apply for government funding (as they can prove how many students were in class on a specific day).
-Parents expect to benefit by knowing when their children are in school or miss school. This way parents can support their children to be in school. Being in school is a '''shared value''' between the school and the parent.
-Students expect to benefit by understanding how many days of school of they have missed. The school expects students to have a strong "ownership of learning" and manage their attendance.
-'''Change request:''' a school administrator asks for a card-system, so students touch their id card to a reader and be automatically counted as present. There will be a card reader and camera in every classroom. Students must touch their id card to the card reader and then smile for a camera picture. the picture and information embedded in the card is stored in a database and used to provide evidence the student is present in class.
-Question 1: Describe '''why''' we should carefully manage this change process.
-Question 2:  List the steps you would take to make this change (what would you do first, then next, then next).
+There is a lot more to say about this, but my advice is to assume any system you are involved with needs to be compatible with other systems and legacy systems.
 == Standards ==
-* Outline compatibility issues resulting from situations including legacy systems or business mergers. [[Level 1]]
+* Outline compatibility issues resulting from situations including legacy systems or business mergers.
 == References ==