At our most recent internal conference, Tim Ewald gave us a passionate talk on the topic of architecture and design. He said that a successful solution must deliver features, while exhibiting certain desirable properties and meeting constraints. Features are the things it should do: send email, display cat photos, and display notifications. Properties are the less visible characteristics, sometimes called "non-functional requirements." Constraints are the boundaries that the solution cannot exceed.

In a contrived example: For structures, the force of gravity is a constraint. Standing for the next 50 years is a property. An auditorium for performances is a feature.

While features are the simplest things to identify, they are not what determines how successful a solution is.

For example, there must be thousands of ways to place a "registration form" on the Web. Custom coded in dozens of languages, countless SaaS sites, platforms like Google docs, the number of possible solutions to this problem goes on and on. You could write a CGI perl script to run on a Raspberry Pi plugged in to a covert power outlet in your neighborhood coffee shop, running on free wifi.

All of these solutions provide the necessary features. So what makes one solution a better fit than another? How do you choose among the array of possibilities? You eliminate the solutions that won't exhibit the necessary properties. Then choose among the remainder.

For instance, does your registration form need high availability? Scalability? Is it OK to miss a few people here and there? Is it OK if the entire list gets revealed? Or are there lives on the line?

Among these properties, I think the most important ones are those that affect the financial success of the system. We tend to relegate all money matters to project managers. However, I think architects are the people who have the right skills to answer the trade-offs inherent in these questions:

• Can it be built cost-effectively?
• Can we profit from it, or will operational costs overwhelm us?
• Will it be available and responsive enough to win customers?
• Can we support an economically interesting user base?
• Is it going to be so hard to defend that we end up losing customer data or spending a fortune on security?

All of these questions sit at the intersection of time, cost, and functionality. The architecture skill set helps a team balance these concerns and guide the system to the most positive possible outcome. Viewed this way, architecture is about creating positive financial outcomes.