Certain policies can have significant impact on the design. Some of the policies I become aware of when setting out to design a new solution are not always commonly known outside the issuing department.

Therefore, I find it worthwhile to help spread awareness of these policies amongst my stakeholders, and also let them know what it means in terms of development effort and long term maintenance.

I recommend that this chapter contains a table with the following columns:

Reuse before buy, buy before buildIt is believed that building software is more expensive than buying, and that it’s always cheaper to reuse.Attempting to cater to other less known systems, or future needs, increases the complexity of the code, hence slowing down development and risking missing deadlines and overspending.

Also, connect a wide range of consumer systems to a service locks its design because it’s too overwhelming to coordinate with multiple other teams when needing to refactor the design.

This solution’s services are designed to only service the solution itself, thereby shortening the development time and lowering the long-term maintenance costs.
Services must only perform a single function.It is believed to promote enterprise-wide reuse of services, thereby lowering developments costs in future projects.This solution’s services have a secondary function that enrolls them in the solution-wide heartbeat mechanism, which is necessary to achieve the operability design goals.

Good operability helps discover and mitigate operational risks before they materialize into acute problems.
The integration tier must be kept stateless.No one has offered any arguments in favor of this policy, and the integration infrastructure doesn’t include any database technologies.Since the integration services can’t store data, the integration tier can’t maintain an inventory of managed information entities and their present state. This limits the measurability, integrity, non-repudiation, operability and recovery design goals.

It also requires squeezing foreign keys into each integrated system for safe-keeping, which increases the overall development time and long-term maintenance costs.

This architecture also misuses the available MQ server for short-term storage of some state data.
The table shows example policies I have come across in various companies.

The example policies are quite common. Notice that I am allowing myself to describe the offered rationale for each policy with some reservation.

I’m using this to gain backing from stakeholders to challenges center-productive policies, which are sometimes not devised from people with actual hands-on expertise.

Other frequently encountered policies are:

  • Naming conventions (service names, variable names etc.)
  • Design principles imposed on the project, for example by the enterprise architects.