Thanks to @jadkins for the colorful ending to that cliched saying, which really got me thinking. Sometimes we just make certain aspects of architecture too difficult for no reason. Good design is important and can have significant financial impact if done incorrectly, but chances are the negative impact comes into play during the engineering effort, not during the architecture. To clarify my point, one must first understand what architecture is really focused on and how that differentiates from engineering.

For example, if we’re designing a solution for financial services products. I can choose to take a framework approach to architecture in which we identify the common financial services components, such as securities and instruments and expose the manipulation of these components through the framework. Then we can continually add new algorithms to manipulate these same components in a modular fashion. Yet, another approach might be to examine things from the perspective of the buyer and the seller and allow each financial product to implement it’s own representation of securities and instruments and orchestrate the process of selling and buying.

Either of the aforementioned scenarios is a viable architecture. In the former scenario, we can develop new computational models very quickly as long as we don’t change the definition of the semantic elements. However, it can be a bit rigid since all new products must be able to define the components of its product based on these definitions. Also, sharing these products across trading partners becomes more complex.

In the latter scenario, we have a more service-oriented approach, focusing on the consumers and less on the definition of the products themselves. Hence, each service is unique, and may produce redundancy in defining the elements used to create a product, but we can orchestrate buying and selling across products in a common fashion. This approach facilitates incorporation of a much wider community since agreement is not required for the representation of elements to create a new derivatives product.

Which architectural approach is better? Well, as any good consultant will tell you it depends on your goals. If your goal is to allow your big brains to develop new models quickly to identify market making opportunities, then the first approach sounds ideal. If your goal is to enable a new derivative product to be treated as a single instrument even though it’s comprised of securities that are bought and sold across a variety of exchanges, then the latter approach will probably suit your needs better than the former.

Neither scenario is optimal or guaranteed, but they both represent a means of simplifying the system enough to extend it over time without considerable re-work efforts.

When complete a design goes through an engineering effort where a software engineer will take this design and “press” it into software. During this effort, decisions are made about platform, programming language, external libraries, software development methodology, etc. Any one of these decisions, or a combination of them, may lead to the undoing of the great abstract architecture designed. For example, if the system cannot scale to the volume of financial services transactions, then that would be one major flaw. Using an open source library that ends up having a major security flaw is another potential flaw.

These scenarios are not very different than design and engineering in any other industry. The architects can design the most awesome car or impressive building, but if the engineers select the wrong parts or use inferior materials, the resulting product will never allow the architecture’s brilliance to shine through. Note, manufacturers put significant effort into ensuring that their designs will work by building prototypes and testing against known environments that the product will have to operate under. Thus, from this perspective, architecture is responsible for putting forth a design that is credible before engineering commences.