The details are those things that are necessary to enable humans, other systems, and
programmers to communicate with the policy, but that do not impact the behavior of
the policy at all. They include IO devices, databases, web systems, servers,
frameworks, communication protocols, and so forth.
The goal of the architect is to create a shape for the system that recognizes policy as
the most essential element of the system while making the details irrelevant to that
policy. This allows decisions about those details to be delayed and deferred.
For example:

• It is not necessary to choose a database system in the early days of development,
because the high-level policy should not care which kind of database will be used.
Indeed, if the architect is careful, the high-level policy will not care if the database
is relational, distributed, hierarchical, or just plain flat files.

• It is not necessary to choose a web server early in development, because the high-
level policy should not know that it is being delivered over the web. If the high-
level policy is unaware of HTML, AJAX, JSP, JSF, or any of the rest of the

alphabet soup of web development, then you don’t need to decide which web
system to use until much later in the project. Indeed, you don’t even have to decide
if the system will be delivered over the web.
• It is not necessary to adopt REST early in development, because the high-level
policy should be agnostic about the interface to the outside world. Nor is it
necessary to adopt a micro-services framework, or a SOA framework. Again, the
high-level policy should not care about these things.
• It is not necessary to adopt a dependency injection framework early in
development, because the high-level policy should not care how dependencies are
resolved.