What’s the most important question for an architect?
There is a Taoist story of an old farmer who had worked his crops for many years. One day his horse ran away. Upon hearing the news, his neighbors came to visit. “Such bad luck,” they said sympathetically. “May be,” the farmer replied. The next morning the horse returned, bringing with it three other wild horses. “How wonderful,” the neighbors exclaimed. “May be,” replied the old man. The following day, his son tried to ride one of the untamed horses, was thrown, and broke his leg. The neighbors again came to offer their sympathy on his misfortune. “May be,” answered the farmer. The day after, military officials came to the village to draft young men into the army. Seeing that the son’s leg was broken, they passed him by. The neighbors congratulated the farmer on how well things had turned out. “May be,” said the farmer.
(“Maybe” from Zen Stories to Tell Your Neighbors)
The story of the old farmer illustrates an extremely important point for architects: nothing is absolute. There is no universally “right” technique or process. Everything involves trade-offs, where benefits must be weighed against their associated costs. Evaluating those trade-offs and choosing according to the needs of the customer is a key responsibility of an architect.
The best teacher I had in graduate school spent the whole semester destroying any beliefs we had about computing. He was a real iconoclast. He happened to be a genius, so we took it. At the end of the course, we were free because we didn’t believe in anything. We had to learn everything, but then he destroyed it. He wanted us to understand what had been done, but he didn’t want us to believe in it.
Clinging to mantra’s like “the simplest thing that could possibly work” or “never keep duplicate data” can easily fail you. Caching, for example, violates both of those strictures. Knowing why those guidelines exist is important. Knowing when to violate them is more so.
Likewise, basing design choices on the current fad technology (remember when everything had to be a service?) is unlikely to yield a robust architecture. Worst of all are designs that are implemented because the architect cannot admit that the risks outweigh the benefits. Delivering an unstable or insecure system, just to prove that you can make something “work”, borders on malpractice.
The most important question in architecture is “why”. When questioned about any aspect of the design, if you cannot justify the decision, you should revisit it. Being able to list outcomes, both good and bad, and explain the reasoning behind your choices will garner trust from both customers and colleagues. Most importantly, it should boost your own confidence in the design.