Myth: An architecture can be sold by it’s quality attributes & trade-offs.

An architect has the responsibility to sell her architecture. This could happen in reviews with peers, reviews with stakeholders, reviews with developers, or reviews with operational managers.

Certain things can be learnt by the architect from the patterns and practices of the sales discipline. There are two key practices in sales.

1. Value based selling. In this art form, the sales person describes and re-inforces the value of the product that she is selling; some key quality attribute e.g. brand, reliability, best-seller, discounted only for the month, etc.
2. Solution based selling. In this art form, the sales person understands the customers pain points; and creates a basket of products/services that address the pain points. The outcome is a personal solution to the pain points.

I have seen that good architects, can be perceived as great; if they can adapt to the various stakeholders – peers, developers, users, managers, etc. i.e. adopt solution selling.

The general practice in architecture is to collect requirements from different stakeholders, do some industry research, apply some brain power and experience, and come out with an architecture that could meet the needs of various stakeholders. The architect is proud of the architecture that she has developed, and would like the stakeholders to accept the proposal; and seeks to sell the value proposition of the architecture produced…i.e. the guarantees of best-in-class and latest technologies, the quality of data stored, etc.

However, for most stakeholders, it’s really about

1. “What’s in it for me?” and
2. “How is my need met?”

For a peer architect, usually coming in from a very specific perspective, it’s about making sure a certain quality attribute is done well. E.g. dependent API’s.

For a developer, it’s usually about the technology used to build and ease+comfort of developing the product.

For a user, it’s usually about meeting the primary functional and non-functional goals.

For an operational manager, it’s usually about having an architecture defined that is generally accepted; and knowing the potential structure she needs to setup to execute the plan; and knowing what risks need to be tracked.

So, when an architecture is described using – logical view, deployment view, security perspective, etc; the stakeholders of the architecture (users, developers, managers, peers)  are not specifically addressed.

In my experience, an architecture view is very personal to a stakeholder, and must be created to meet the needs of the stakeholder (i.e. solution selling). It’s important to understand the pain point of the stakeholder, and sell the architecture in context of the pain points.

Bottomline, an architecture description should be minimal enough to sell the architecture to various stakeholders. A comprehensive data view is great for the architect to get the BIG picture, but not a great selling proposition for users, developers, managers, or peers.

Specific and customised selling helps to improve and iterate on architecture. A good architect, is a great architect, when she can sell the architecture successfully. Capitalism!