1. Discuss here any example, instance, or application of a principle of general systems theory that you have experienced or come across in your job or student life. Your example may or may not have anything to do with computer systems but must illustrate some aspect of what we mean by “systems thinking” in the world.
Answer: From my understanding, Systems thinking involves taking the most pragmatic approach towards solving problems that arise in everyday life weighing the problem’s relevance with all the components that get affected with the problem. I would like take the example where I experienced systems thinking in my work experience.
Resolving a production defect: During my stint with Infosys, I worked on many Life Insurance development projects across all life stages of software development which often involved tight deadlines right from the stage of requirement analysis, preparation of high level design specifications, detailed level technical specifications, coding, testing and production deployment. Many projects also had production warranty support where the production defects have to be serviced without charging any service fee to the clients.
In resolving any production defect, before jumping into the problem and debugging the underlying code, I always found it useful to first understand the scenario in which the end user was facing the problem. I used to double check the system’s functionality based on the requirement specifications and also confirm with the business analyst to determine if the scenario which resulted in defect was a valid scenario or not! This approach saved me a lot of time and effort as I could filter many invalid scenarios where the end-user was not following the proper approach while submitting the transactions.
However, many a time, succumbing to the high pressure environments involving adherence to the deadlines, it did happen that many enhancement projects would always result in few escaped bugs, not caught by both the development team as well as the quality assurance team that directly affecting the production system. As a developer, once I confirmed that the defect is indeed a defect, I used to gain an understanding of the scenario that was executed and analyze the module that contained the functionality that was not working. Instead of blindly fixing the code, I used to ask myself few questions – Will changing the code fix this problem? Is it a right decision to fix the code especially when you know the module has never had any problem earlier? What are the top level modules that have passed the data to the sub module? Is there something wrong with the top level modules calculation that is passing incorrect data? What is the relational flow between all modules? Are there any changes done by other in the top level modules recently?
All these questions opened multiple perspectives and enabled me to think about the information flow across all the modules involved in a functionality and in many cases I found the exact root which was not in the module that was erroring out but a the error propagating from the top level module to the sub modules. After I fixed the error, I used to test the functionality to make that the fix is working and also do a thorough research on finding the impact of fix on other modules as a fix done for resolving one problem could pose severe threats to other bottom-level functionalities that rely on the module which was fixed. This method of regression testing made me analyze sometimes labyrinth of relationships across the whole set of modules and gain understanding about the systems entire functionality and safeguarding it from the after-effects of resolved bug.
2. From your own experience working with or observing information systems or from surveying the Net, provide an example of an information systems development project where the “wrong” problem was solved. In about a paragraph or so, describe the project, explain the wrong problem solved and state the resulting consequences. Provide your own comments. Provide the URL link if any.
Answer: Last year, I got to work on the functionality of testing the Over-Loan Policy termination functionality for TIAA-CREF life Insurance.
Background: Every Life insurance company relies on information systems to administer the insurance policies that are active with the company. Most of the companies have a single policy administration platform. Any whole life insurance policy with a sufficient cash value built-up over time is entitled for Loan not exceeding certain percentage of cash value. Every loan is charged certain amount of interest rate which is due along with policy premium which is paid at a frequency based on user discretion. Over the course of time, if the policy loan value exceeds the cash value, the insurance policy should get terminated because of over-loan condition.
Problem: The existing functionality of over-loan check was only terminating the policies based on the anniversary check i.e, even though a policy went into a over-loan situation on a particular day, the insurance policy remained active and in case of any occurrence of insurable event, the full insurance amount was paid out to the beneficiaries.
Desired State: The over-loan condition check should happen on every policy that has a loan on it during every day nightly batch run. If a policy goes to over-loan situation on a particular day, the policy should terminated and correspondence should be sent to the policy owner about the termination.
Proposed Solution: Enhance the Policy administration system by developing a new module that did a daily check of cash value for the policies that had loan and terminated the active policies so that the benefits of insurance are no longer applied. The estimated effort was 100 hours of development and testing and 10 hours of project management effort.
Resolving the Problem: Upon careful analysis, I just had to implement a new product rule in the whole life product configuration so that the over-loan termination check happens every day. It just took 3 hours to actually analyze the problem.
Lessons Learnt: It is clear that many time a functionality does exist in the current system and wrong configuration causes major problems. Simple tweaks can resolve the problem but many people do not analyze the current existing functionality and take decisions that cost company a whole lot of effort and duplicate the existing functionalities!
3. The analysis and design of an information system, done well, often eliminates jobs in a company. Why? What can be done about the loss of jobs? [Economic analysis supports the creation of new jobs when this happens, but generally there is a time lag between the structural loss of jobs and the creation of new jobs.]
4. Visit and review the website of The Software Engineering Institute at Carnegie Mellon University (www.sei.cmu.edu). Comment upon the main solutions, products, and services they offer.