Leveraging design principles and existing solutions

Practice · Chapter 5

Design concepts as building blocks

Designing from scratch is hard, but many design issues are already solved. Design concepts — reusable principles and solutions — are building blocks for an architecture. Four kinds:

Software architecture patterns
Reference architectures
Tactics
Externally developed software

Selecting a design concept

Match the concept to the stage and nature of the problem — e.g. a reference architecture suits early structure; a tactic suits a specific quality attribute scenario later. You may combine several.
Identify candidates via your own knowledge/experience, your teammates’, and best practices; then weigh pros, cons, and cost. Respect constraints — one may rule an option out.

Software architecture patterns

Documented, reusable solutions to recurring architecture design problems, distilled from what people did successfully. Apply one only if it genuinely solves your issue and is the best fit for your context — don’t force it.
Covered in depth in Software architecture patterns.

Reference architectures

A template architecture best suited to a particular domain — recommended structures, elements, and relationships.
Benefits: a tested, proven solution (technically and business-wise) that reduces design complexity, effort, cost, and errors while speeding delivery and raising quality.
Refactoring: expect to make design decisions and refactor a reference architecture to fit your app; the amount depends on how closely it matches your requirements. They exist at different abstraction levels — even a mismatched one can serve as a guide. Well-understood domains have many; novel domains few. Adopting one means you inherit its issues (you must decide how to handle them, even if the decision is to exclude something).
Create your own: a finished architecture can itself become a reference architecture — useful across a software product line, with the advantage that it already fits your domain.

Tactics

Proven techniques that influence a single quality attribute scenario, so they’re simpler than patterns or reference architectures. They provide options to satisfy an attribute but need other design concepts plus code to be fully realized. Examples:
- Lower complexity in a component by raising cohesion and reducing coupling (maintainability).
- Friendly, informative messages to improve usability.
- A retry strategy to handle transient faults for availability.
- Clean removal of an old version during updates to improve installability (portability).

Externally developed software

Rather than build in-house, leverage software built outside the org — a component, application framework, product, or platform (e.g. a logging library, a UI framework, a server-side platform).

Buy or build?

“Buy” means use something built externally (not necessarily paid — many free/open-source options exist). Before deciding: understand the problem and its scope, research whether suitable external software exists (a unique problem may have none), and confirm the org has resources/time to build, maintain, and support an in-house solution.

Build — pros: unique and tailored to you, full control and source ownership, freedom to modify, possible competitive advantage. Cons: costs time and resources; may lack the feature-richness of a proven external tool (e.g. building your own distributed full-text search engine is usually impractical).
Buy — pros: saves development time, potentially higher quality (already tested/used in production, bugs found and fixed), ongoing improvement, available support/training. Cons: may cost money; license may withhold source or limit use; if you can’t modify it, functionality is controlled by someone else; you depend on an external org for fixes/changes.

Researching external software

Ask: Does it solve the problem? Is the cost acceptable? Is the license compatible? Is it easy to use (do we have people who can)? Does it integrate with our other tech? Is it mature with stable releases? Is support (paid or community) adequate? Is it widely known enough to hire for? Build prototypes/POCs to evaluate and compare candidates.

Open source software (OSS)

Written by the community for the community; widely available, so solutions exist for many problems and OSS use is now common (some orgs forbid it — check yours).

License matters. Many use OSI-approved licenses (e.g. Apache 2.0, BSD 2-/3-clause, CDDL, EPL, GPL, LGPL, MIT, MPL 2.0). Terms differ: MIT lets you distribute your app without open-sourcing it; the GPL requires your distributed app to be open-sourced (even if free and unmodified). Internal-only, non-distributed use can stay proprietary.
Advantages: like “buy” (no build time, rich features, tested/proven) plus free (cost savings); active communities bring continuous fixes/features; Linus’s Law — “given enough eyeballs, all bugs are shallow” — means problems surface faster; source access lets you modify it; some view many eyes as more secure.
Disadvantages: still costs effort to integrate/modify/learn; no guarantee of continued support (projects can be abandoned); can become less secure if no one actively reads the code (the average programmer writes more than they read, and critical vulnerabilities have gone undetected for long periods); open source also lets malicious actors hunt for vulnerabilities.

Citations

Software Architect’s Handbook (Packt, 2018), Ch.5 “Leveraging design principles and existing solutions”, pp. 301-318.