There are several areas to touch when we start discussing about producing the flexible architecture and we may have several posts back to business side if we not put a scope to this dialectic. So I decided to put aside the points regarding the whole product delivery process, development process, architecture review process, and requirement management process, and let’s concerns on the technical design topics which will be a lot easier to keep it practical and be able to apply to our job immediately:

  1. Have good prioritized requirements or scenarios, so we know what are the core or value-added functionalities of the service.
  2. Clear and concise traceability from scenarios and features down to the chain of system components.
  3. On/off configurations and scripting for non-core features.
  4. Stateless and horizontal scalability are still the most preferable.
  5. No distributed transaction.
  6. Decoupling the business process logics from the processing or workers.
  7. Decoupling the service interface from the service implementation.
  8. Modularity and composability
  9. Self-containment and isolation of the services/modules.
  10. Interoperability and open standard protocols.
  11. Contract-driven design for both data and interfaces.
  12. Loose-coupling.
  13. Weak Typing.
  14. Prefer stateless over stateful connection.
  15. Fire and forget communication.
  16. Event and message driven.
  17. Not so realtime, please.
  18. Cross-cutting and common concerns.
  19. Dependency management and injection.
  20. Make sure to have the complete test stubs.
  21. Easiness in deploy/undeploy/re-deployment is always preferable.
  22. Virtualization and cloud computing.

Note: Although this list is not prioritized in any order because it could be vary from project to project, but it sure is a good starting point for reviewing our design and even apply it immediately. The flexible architecture provide us a lot of benefits both during both creation and modification times. During creation time, we can plan and develop the system in the distributed agile mode because we can adopt the “Just Enough Design Upfront” concept to analyse the context and create the skeleton architecture or schematic design to use as a common high-level picture among the distributed teams. We will then define the contracts (plus some important specifications) and review it together through the interaction simulations per each scenario.

In order to let the architects to create the pictures to compose together, requirement/scenario management and synchronization between the product managers is critical.

After we have the same clear common high-level pictures, scenarios, interactions, contracts, and responsibilities. Each team then start their works at full speed. Be aware that some teams may have to provide the test stubs or mocks to other teams or even do the prototypes, while some teams may be not. So planning and orchestration skills of the project managers is the key.