Architectural values

There has been much written about the value of values for a team: simple statements of priorities which help everyone in the team make decisions and reinforce delegation. The agile manifesto is a great example of these: an easily understood statement of priorities which help everyone develop software the agile way.

Over the years I’ve found values to be helpful for describing the our architectural principals, assisting the team to make the right calls. Here’s our values:

Buy over Build​

In my current role, we run a small engineering team. The temptation to build software is always present but, unless the organizational product is truly software, it rarely makes sense to roll your own. Better to look for best in class products and integrate. From time to time you’ll hear it claimed that only by building can you avoid lock-in. I have no patience for that argument: there’s always lock-in somewhere in the stack, the trick is to be aware and clear eyed about it.

Configure over Customize​

Put another way, prefer software that permits configuration to achieve your goals vs using APIs for custom development. I’ve seen more than one ERP version upgrade fail because of tight external customization that a new version can no longer support. Vendors have a far greater incentive to ensure that configurations running within their software survives upgrades.

SaaS over On Prem​

This should be a no-brainer at this point. The interests of customer and supplier in subscription based software are far more closely aligned than traditional software sales. Plus, you’re not spending your time keeping SaaS software running.

API over File transfer​

If two products are sufficiently similar in features, security and price, we’ll choose the one with an API. CSV really is a lousy way to transfer data between machines: no types, (typically) no schema, often lousy security. Yuck.

Commodity over Niche

Another way of saying choose horizontal over vertical: better price, security, scalability and development.

There will always be times when we have to bend on these values. Sometimes, we have to develop software, or do CSV over SFTP. The point of these values is to prompt the discussion, not halt forward progress.

Values will mutate over time: the SaaS one would have been far more risky fifteen years ago, not so much today. Further, different companies will have different values based on their philosphy, size and product: that’s to be expected. What are your architectural values?