There is no right way (though there are plenty of wrong ones)

The idea of functional perfection is an intriguing concept. Would it not be wonderful if the things we use functioned perfectly? Well … it certainly would … but, then, what do we actually mean by perfectly? On the one hand we tend to consider functional perfection to be an obvious, if difficult, aim of the engineer’s and designer’s effort. But on the other hand we have a creeping suspicion that such an aim is hopelessly out of reach.

Jan Michl, “On the Rumor of Functional Perfection”

One of my pet peeves is being asked for the “right” way to do something. The word “right” only has meaning relative to your perception of the current state of your needs. Zero defects sounds like a great deal until the time and cost is accounted for. Ditto for “five nines” high availability. And eking out every little bit of performance will likely leave you with a system that is difficult to maintain. There is a reason that some drive Volvos, some Lamborghinis, and others Fords.

A major aspect of an architect’s job is to understand the trade-offs that go into design decisions and then with the customer’s wants and needs in mind, creating a solution that best meets those requirements. Where requirements are contradictory, resolutions must be negotiated. It is almost assured that what suffices for today will not be good enough tomorrow. It is equally likely that, despite your best efforts to anticipate future needs, something unexpected will come up. Therefore, the aim should not be for everlasting perfection, but for flexibility.

Aiming for some sort of illusory technical perfection loses sight of the customer’s needs. As difficult as it may be to process, the customer is not interested in your skill. The customer is interested in what your skill can do to improve their business. They are not interested in paying extra for work that does not address that goal. As Dan North noted:

There is a difference between the mindset of a master stonemason sculpting the expression on the face of a gargoyle and someone using the commodity blocks that make up a multi-storey car park. In the latter case the last thing I want is someone’s “personality” causing some of the blocks to be different sizes and no longer interchangeable, never mind the added expense of having someone manually hew the stone rather than using machine tools. In the former the stonemason’s attitude is indulgent. He is putting his signature (and his ego, and his reputation) into this magnificent representation of Hell’s best. If you just wanted an oil-pouring spout you could get one from a DIY store.

This does not, however, mean that the architect’s role is passive. Understanding the costs and benefits associated with design decisions places the architect in a position of responsibility for communicating the trade-offs to the customer. As stated by Rebecca Parsons:

From a business context, the business has a debt that it may or may not have made a conscious decision to take on. It is the responsibility of the development team to make sure the business understands if they are compromising the long-term costs and value of the code by taking a particular decision in the short term.

It is the architect’s job to help guide the customer in choosing a path that provides the optimum system for their needs now and in the future. This is where the architect provides value.

After all, at the end of the day, if there were only one right way to design a system, would anyone need an architect?