Architect as Advocate of the Business

Architecture is “an instrument whose central function is to intervene in man’s favor”

James M Fitch, 1972

As an architect, one of our most important responsibilities is working with the business stakeholders to understand their objectives and help ensure an effective solution. What's more, we typically need to understand the problem domain (or learn it very quickly) so we can help define those requirements and develop the solution strategy.

The following quote from WWISA does a good job of capturing this responsibility:

"Architects spend the lion’s share of their time up front: listening to clients, understanding the totality of their needs and resources, scrutinizing feasibility, forming a practical vision of a structure, and creating a blueprint. As the structure is built, the architect intervenes in the client’s favor, ensuring compliance to the plan and guiding the vision through the tempest of design changes, crises and ambiguities. Client advocacy is the cornerstone of the architect’s role." (http://www.wwisa.org/wwisamain/role.htm)

The role of advocacy is exhibited in many activities (negotiation, scope management, corporate politics, risk management, prioritization, etc.), but let's quickly highlight just two that revolve around the principle of understanding the problem domain.

Product Definition

The architect's awareness and appreciation of the business domain is essential to the best definition of a software-systems capabilities. The architect is able to understand likely requirements and encourage penetrating assessment of key product areas. I like to think about this in terms of how understanding the "solution space" has influence over the understanding of the "problem space". It's true we want to maintain separation of our models and abstractions between these domains, but it's critical that the solution side have a deliberate and calculated influence on the problem side.

In my classes, I like to use the example of buying a new car. While this is a low-level example, I think it illustrates the topic well (and it's easy to personally relate to). With a few essential "market needs" in mind (e.g., 4 door because it'll be too hard to get the car seat in and out of the coupe when the new baby is born, 6 cylinder because this 4-banger isn't cutting it in Atlanta traffic, and candy-apple red because, well, just because), we head out into the "solution space" (wandering lots, reading brochures, taking test drives, talking to friends, reading Consumer Reports, etc) and begin to evaluate our options. The available options immediately begin to influence our understanding of the most suitable feature set - the best balance of needs and solutions - and we ultimately arrive at the best "product."

The architect is most effective at helping to arrive at this "perfect balance" when he or she has a practical understanding of the business domain - the "problem space".

Product Evolution

The architecture of a system is subject to the tides of change within the business environment being served, reinforcing that the architect should be familiar with the business domain. In this regard, the architect needs to anticipate future changes to the architecture, and integrate styles that lead to the most valuable types of flexibility, a challenge more readily met with an appreciation of the business domain. For example, architects of today's payments-related systems should be keenly aware of the industry trends towards payments convergence - the collapsing of disparate payments channels into fewer products with greater compatibility and higher-value capabilities. Likewise, regulatory changes in the financial services space are shifting the landscape and encouraging the overlap of banking, insurance, and health care services. Business factors such as these industry and government trends must be taken into account in the design of effective architectures.

Let's sum this up with a quote from Wikipedia. This is actually in reference to structural architects, but it seems fitting nonetheless:

"The practice of architecture is a business, in which technical knowledge, management skills, and an understanding of good business practice are as important as creative design." (http://en.wikipedia.org/wiki/Architect)

And I'll leave you with the following WWISA story reinforcing the close relationship between the business and the Architect. :-)

"The architect and client meet when it is all over and reminisce about the trials and triumphs. They hold a big party at a Mexican restaurant, complete with Mariachi Band, for all the builders, employees, and customers involved with the project. Those nay-sayers who whined incessantly and said it couldn't be done now stand mute, sipping their margaritas. (http://www.wwisa.org/wwisamain/role.htm)"

Anyone hear the music?