The solution options are as follows:

• The logical separation of the application into various tiers (for example, client, presentation, business logic, integration and EIS tiers) allows a system to be flexible and easily maintained. When there are any changes in presentation, it will be done at the presentation tier, and it will not affect the other tiers. If there are any business logic changes, only EJB components business logic get changed, and it will not affect other tiers, and vice versa.
• The MVC architecture leverages command patterns at the web tier (JSF backing bean classes) for handling web events. Therefore, when new functionalities are added to the system, it will not affect the existing system. We can easily create a new web action by developing a new backing bean class and configuring it in a faces-config.xml file. Modifying the existing functionality becomes easy by changing the respective backing bean classes.
• Object orientation like encapsulation, inheritance, high cohesion and low coupling are leveraged in application design. So, the subsystems changes will have less impact on applications which are using it as long the interfaces remain same.
• Independence of interface from implementation permits the substituting of different implementations for the same functionality.
• Design systems and layers that demarcate the system's UI, processes, and data access funtionality.
• Design cross-layer interdependencies by leveraging abstractions rather than concrete implementations, and minimize dependencies between layers and components.
• Design a plug and play architecture that facilitates easy maintenance and upgrades, and improves QA processes. Use APIs enabling plug and play modules or components to maximize flexibility and extensibility.
• Leverage the built-in platform features wherever available instead of custom implementation.
• Design modules to have high cohesion and low coupling to enhance flexibility and provide reusability and replacement.
• Establish the method to manage dynamic processes and dynamic rules, by leveraging workflow engine if the business processes tends to change.
• Solution business components to implement the rules if the rule values are dynamic or an component such as rules engine if the business decision rules are dynamic.
• Provide artifacts that explain the overall structure of the application. Good documentation of the application, which consists of architecture diagrams, interfaces, class diagrams, sequence diagrams, and coding guidelines are the key criterion for maintainable IT systems.
• Identify areas of concern and consolidate them into logical depiction, business, data, and service layers as appropriate.
• Establish a development model with tools and frameworks to provide workflow, and collaboration.
• Establish guidelines for architecture, design and coding standards, and incorporate reviews into your SDLC process to ensure guidelines are diligently implemented.
• Establish a migration roadmap from legacy applications, and isolate applications from interdependencies.
• Expose functionality from layers, subsystems and modules through APIs that other systems and layers can invoke.
• Logical separation of the application into different tiers (client, presentation, business logic, integration and EIS tiers) allows a system to be flexible and easily extensible.
• Leverage design patterns throughout the application architecture.
• OOD, like encapsulation, inheritance, low coupling, and high cohesion are leveraged in application design. This ensures that changes to dependent systems will have less impact on SuD.
• Excellent documentation of the applications (for instance, architecture diagrams, interface agreements, class diagrams, sequence diagrams, coding guidelines, and so on).
• Separation of concerns required, providing a catalogue of services from a registry and allowing various processes to leverage these services through a defined protocol.
• Independency of interface and implementation allows substitution of implementations for the same interface.
• A strategy to separate data and functions addressing various concerns. As the concerns are different, one can update each concern independently.
• Emphasis on runtime design and no hard coding in the application implementation.