Category: Software Architect

Effective software architects understand not only technology but also the business domain of a problem space. Without business domain knowledge, it is difficult to understand the business problem, goals, and requirements, and therefore difficult to design an effective architecture to meet the requirements of the business.

It is the role of the software architect to understand the business problem, business goals, and business requirements and translate those requirements into a technical architecture solution capable of meeting those requirements. Knowing the business domain helps an architect decide which patterns to apply, how to plan for future extensibility, and how to prepare for ongoing industry trends. For example, some business domains (e.g., Insurance) lend themselves well to a Service-oriented architecture approach where as other business domains (e.g. Financial Markets) lend themselves more towards a workflow-based architecture approach. Knowing the domain helps you decide which architecture pattern may work best to satisfy the specific needs of the organization.

Knowing the industry trends of a specific domain can also help a software architect in designing an effective architecture. For example, in the insurance domain, there is an increasing trend towards “on-demand” auto insurance, where you only pay for auto insurance when you actually drive your car. This type of insurance is great if you park your car at the airport on Monday morning, fly off to your work destination, and return Friday to drive back home. Understanding such industry trends enable you as a software architect to plan for these trends in the architecture, even if the company you are working with hasn’t planned for them yet as part of their business model.

Understanding the specific goals of the business also helps you design an effective architecture. For example, do the goals of the particular business you are working for include non-organic growth through heavy mergers and acquisitions? The answer to this question may influence the type of architecture you design. If the answer is yes, the architecture might include many layers of abstraction to facilitate the merging of business components. If the goals of the business include increased market share through a heavy online presence, then high availability is most likely going to be a very important attribute. As a software architect, always understand the goals of the company you are working with, and validate that the architecture can support these goals.

The most successful architects I know are those who have broad hands-on technical knowledge coupled with a strong knowledge of a particular domain. These software architects are able to communicate with C-level executives and business users using the domain language that these folks know and understand. This in turn creates a strong level of confidence that the software architect knows what he or she is doing. Knowing the business domain allows a software architect to better understand the problems, issues, goals, data, and processes, which are all key factors when designing an effective enterprise architecture.

Creating an application requires many decisions to be made. Some might involve choosing a framework or library while others revolve around the use of specific design patterns. In either case the responsibility for the decision generally lies with the architect on the team. A stereotypical architect might gather all the information that can be gathered, then mull over it for a while, and finally decree the solution from the ivory tower for it to be implemented by the developers. Not surprisingly there is a better way.

In their work on lean development Mary and Tom Poppendieck describe a technique for making decisions. They argue that we should delay commitment until the last responsible moment, that is the moment at which, if the team does not make a decision, it is made for them; when inaction results in an outcome that is not (easily) reversible. This is prudent because the later a decision is made the more information is available on which to base the decision. However, in many cases more information is not the same as enough information, and we also know that the best decisions are made in hindsight. What does this mean for the good architect?

The architect should constantly be on the look out for decisions that will have to be made soon. Provided the team has more than a handful of developers and practices collective code ownership the architect can, when such a decision point approaches, ask several developers to come up with a solution to the problem and go with it for a while. As the last responsible moment arrives the team gets together and assesses the benefits and drawbacks of the different soutions. Usually, now with the benefit of hindsight, the best solution to the problem is apparent to everybody. The architect does not have to make the decision, he or she merely orchestrates the decision making process.

This approach works for small decisions as well as for large ones. It can allow a team to figure out whether or not to use the Hibernate templates provided by the Spring framework but it can equally answer the question of which JavaScript framework to use. The duration for which the different approaches evolve is obviously very dependent on the complexity of the decision.

Trying two or even more approaches to the same problem requires more effort than making a decision upfront and then just implementing one. However, chances are that an upfront decision leads to a solution that is later recognized to be sub-optimal, leaving the architect with a dilemma: either the team rolls back the current implementation or they live with the consequences, both of which result in wasted effort. Even worse, it is entirely possible that nobody on the team recognizes that the approach chosen is not the best one, because none of the alternatives were explored. In this case effort is wasted without any chance of addressing the waste. After all, trying multiple approaches might be the least expensive option.