The technical choices are made and assumed by the Feature Team.
The Feature Team must act responsibly to identify the choices that impact itself exclusively and the choices that impact the organization.
The choices that exceed the scope of the Feature Team (eg, license, infrequent programming language) must be validated by the organization or by peer convergence process .
The right tool for the good use is a source of savings.
A bad tool imposed on everyone is a risk. The misuse of a good tool can have very damaging consequences. For example, poorly used Agile methods are dangerous.
Tools must be questioned.
Excel is often a rational choice but it is not a tool to do everything (CRM, ERP, Datamart, …)
Prefer Build for the core business.
Consider Buy for the rest, case by case.
The more a tool brings a differentiating feature for the organization, the more it should be built. The core business must allow specificity and adapt quickly and often. Some enterprise software are sometimes adapted to this need.
For the rest: SaaS, Open Source, Build or Vendor are to be studied case by case.
Opt for Open Source.
Alternative choices must be explained.
Proprietary solutions are a risk for the organization which must be able to take over maintenance if needed.
Few are the proprietary tools that do not have open source alternatives.
The organization benefits from the Open Source Community and can pay it back with its contributions.
Develop stand-alone and loosely coupled services.
Loose coupling must be the norm.
Each micro-service has a clearly defined interface.
This interface determines the coupling between micro-services.
Domain Driven Design helps, especially through Bounded Contexts, to anticipate this problem.
Each service has its own data storage system.
A Data Store is intended to be coupled only with a single micro-service.
Data access from one micro-service to another is done exclusively via its interface.
This design implies consistency over time across the platform. It must be apprehended at all levels, including UX.
Each micro-service must have a reasonable functional perimeter, which "fits in the head".
A micro-service offers a reasonable number of features.
Do not hesitate to split a micro-service when it begins to grow.
A service of reasonable size makes it possible to consider serenely the rewriting, if the need arises.
The Reactive Manifesto opens the way towards the design of reactive architectures.
Responsive programming focuses on the flow of data and the propagation of change. It is based on the "Observer" pattern, contrary to the more traditional "Iterator" approach.
The Reactive Manifesto sets some fundamental axis: availability and speed, resilience to failure, flexibility, elasticity and message oriented.
Asynchronous processes foster decoupling and scalability in favor of performance.
Exchanges between applications must be asynchronous first.
Asynchronous exchanges naturally allow loose coupling, isolation and flow control (back-pressure).
Synchronous communication should only be considered when required.
The information system must be event-driven.
The event-driven functional processes are naturally implemented in an asynchronous manner.
Being event-driven allows for approaches such as Command Query Responsibility Segregation (CQRS) and Event Sourcing.
Prefer a simple, robust and powerful message-broker to a "smart pipe".
ESB showed their limits: scalable maintenance is critical, both from a technical and organizational standpoint.
Message brokers like Kafka offer a simple, durable and resilient solution.
Smart endpoints and dumb pipes is an architecture that works at scale: it's Internet.
The full synchronization of the system should be thought of during its design.
If the synchronization between two systems is ensured by an event flow, the total resynchronization of these systems must be planned at design time.
An automatic synchronization audit (example: by samples) allows to measure and detect any possible synchronization errors.
Services configuration is centralized, their discovery is managed through a directory.
Micro-services configuration is centralized for all environments.
A central directory ensures dynamic discovery of micro-services.
The IS' global scalability depends on this directory.
Feature Teams provide a sandbox environment.
Feature Teams maintain a sandbox environment (current and upcoming versions) to allow other teams to develop at scale.
In non-nominal cases, some features may be disabled in the development environment.
Your system will crash!
Design it so that it is fault-tolerant.
Your system will fail, it's inevitable. It must be designed for this (Design For Failure).
Plan redundancy at every level: hardware (network, disk, etc.), application (multiple instances of applications), geographical zones, providers (example: AWS + OVH).
Provide toolkits, do not impose strict frameworks.
Beware of transversal in-house technical components! They are restrictive, expensive and difficult to maintain.
Accelerators, toolkits, technical stacks can be pooled, at the choice of the Feature Teams, avoiding a dogmatic approach.
Public, private or hybrid, the cloud (IaaS or PaaS) is the standard for production.
PaaS services are preferred, simple, and scale quickly.
IaaS services allow for greater flexibility but require more operational work.
A private cloud is not a traditional virtualization environment, it relies on commodity hardware.
Feature Teams do not manage the infrastructure, it is provided and maintained by the organization.
Infrastructure issues are not the responsability of the Feature Teams. Infrastructure must be provided and maintained by a transversal service.
Containers provide the flexibility needed for heterogeneous tooling.
Containers provide the flexibility needed by Feature Teams to enable heterogeneous tooling in a homogeneous context.
The use of containers makes it possible to overcome the problems of technical environments.
The containers (example: Docker) make it possible to abstract the environments differences.
The deployment process must be agnostic to the environment.
Some components such as databases should not be deployed in containers. Their deployment is still automated.
Metrics must be centralized and accessible to all.
Metrics are accessible to everyone with different levels of granularity: detailed view for the relevant Feature Team, aggregations for other members of the organization.
Access to metrics does not imply access to data, access must be controlled to maintain confidentiality.
All environments are concerned.
Software quality is a key factor.
Code reviews are systematic. They are conducted by members of the Feature Team or other members of the organization, as part of Continuous Improvement.
That is not you being audited but your code: "You are not your code!".
Qualimetry can be partly automated, but nothing beats the "fresh eye".
Automated testing is a non-negotiable prerequisite for continuous deployment.
Automated testing ensures quality of the product over time.
It is a prerequisite to continuous deployment, it allows for frequent changes and deployments.
Production rollout becomes a non-event!
Tests at all levels : unit, integration, functional, resilience, performance.
Integration and functional tests are the most important ones, they ensure the correct behavior of the product.
Unit tests are suitable for development.
Performance tests measure performance over time.
Resilience tests help to anticipate failures.
Coverage is the primary unbiased indicator of test quality.
The tests code coverage is a good metric of code quality.
It is a necessary condition but not sufficient, the coverage of a bad test strategy can be high without guarantee that the code is of good quality.
Security is a process, it should not be treated in response to problems.
Security experts can be integrated directly into Feature Teams if needed.
Security experts are available in the organization for audit purposes, awareness and sharing.