Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures

by Neal Ford

Software developers build outstanding skills in searching online for solutions to a current problem.

For architects, many problems present unique challenges

Don’t try to find the best design in software architecture; instead, strive for the least worst combination of trade-offs.

software architecture is the stuff that’s hard to change later.”

data is the most important asset in a company. Businesses want to extract value from the data that they have

One of the most effective ways of documenting architecture decisions is through Architectural Decision Records

One of the most difficult tasks an architect will face is untangling the various forces and trade-offs at play in distibuted architectures.

“Software architecture” is the stuff you can’t Google answers for.

A skill that modern architects must build is the ability to do trade-off analysis.

the first step in trade-off analysis is untangle the dimensions of the problem, analyzing what parts are coupled to one another and what impact that coupling has on change.

Two parts of a software system are coupled if a change in one might cause a change in the other.

Determining the proper size for microservices seems a pervasive problem—too-small services create transactional and orchestration issues, and too-large services create scale and distribution issues.

An architecture quantum is an independently deployable artifact with high functional cohesion, high static

coupling, and synchronous dynamic coupling. A common example of an architecture quantum is a well-formed microservice within a workflow.

Monolithic architectures always have a quantum of one

Broker event-driven architectures (without a central mediator) are less coupled, but that doesn’t guarantee complete decoupling.

The nature of how services call one another creates difficult trade-off decisions because it represents a multidimensional decision space, influenced by three interlocking forces: Communication Refers to the type of connection synchronicity used: synchronous or asynchronous. Consistency Describes whether the workflow communication requires atomicity or can utilize eventual consistency. Coordination Describes whether the workflow utilizes an orchestrator or whether the services communicate via choreography.

When two services communicate with each other, one of the fundamental questions for an architect is whether that communication should be synchronous or asynchronous.