Architecture principles for non-legacy systems

Based on our understanding of legacy and, in contrast, non-legacy systems we could propose a set of architecture principles, providing general rules and guidelines that can support architects in better managing a ‘brownfield’ architecture landscape. As defined in TOGAF, architecture principles consist of a general statement, their rationale and their implication on the organization.

Our proposed set of architecture principles is defined at the level of application and technology decisions, for avoiding/eliminating/detecting legacy systems or components within an application landscape. These principles are provided in a more generic way than we would advise them to be used within your organization, and for that reason we only include a statement and our initial rationale with each principle. The implication would be too specific to the context of any organization, so it would be best to add this yourself as part of your architecture work.

• Principle 1: Embrace simplicity and human understanding
  • Statement: Simple and easy to understand solution options are preferred over complex and inconsistent options.
  • Rationale:
    • reduced complexity in developing systems;
    • better understanding, with less documentation;
    • easy maintenance and control of changes;
    • modularity and separation of concerns.
• Principle 2: Make consistent architecture decisions
  • Statement: Architecture directions are well communicated to relevant stakeholders and are applied consistently when taking application and technology decisions.
  • Rationale:
    • less technical debt;
    • better understanding;
    • communication of architecture standards, principles and guidelines;
    • build on best practices;
    • apply architecture patterns, methods and frameworks – SOA, EDA, microservices, etc.
• Principle 3: Budget for evolutions
  • Statement: The application and technology landscape is managed for continuous maintenance and evolution, and not for large-scale revolutions.
  • Rationale:
    • roadmap for technology upgrades & lifecycle management;
    • maintenance & refactoring are built-in for development teams;
    • not budgeting for large-scale revolutions but evolutions;[DSM1]
    • reduce technical debt;
    • reduce cross-dependencies;
    • continuously evaluate available expertise and resources in the market.
• Principle 4: Reuse, before refactor, before redesign, before replace
  • Statement: An application needs to be maintained and updated on a continuous basis, with a different impact and effort based on the level of change that is initiated in the existing system. Preference is given to the option that provides the best ratio of effort and impact for implementing the required change.
  • Rationale:
    • large impact increases operational risks and uncertainties;
    • small changes can best be resolved with a small impact, as large impact gives additional unintended changes;
    • gradual improvements or refactoring are often less business disrupting than completely replacing systems.
• Principle 5: Control changes with (automated) testing
  • Statement: Testing is the necessary control mechanism to ensure trust and confidence in making changes to systems.
  • Rationale:
    • trust and confidence in making modifications;
    • ensure critical business operations;
    • better understanding of cross-dependencies.
• Principle 6: Ensure compatibility
  • Statement: Applications and technologies within our landscape can easily and seamlessly work together.
  • Rationale:
    • systems can work in the same (technical) environment;
    • confirm standards for the (technical) environment.
• Principle 7: Facilitate interoperability
  • Statement: Systems that need to exchange information use the most appropriate standards and methods for doing so.
  • Rationale:
    • systems can work together and exchange information;
    • confirm standards for interoperability or provide intermediate integration platforms.
• Principle 8: Driven by business capabilities
  • Statement: Evolutions in business systems are aligned with and driven by changes in business capabilities.
  • Rationale:
    • follow the changes in business capabilities and processes, or updates in business strategy and roadmaps;
    • use business opportunities to modify and upgrade business systems;
    • update technologies and applications for future business requirements.