The Role of an Architect Creating a Context for Success through Vision, Standards, and Trade offs

theArchitectRole

As noted designer, author, and artist Edwin Schlossberg said so wonderfully, “The skill of writing is to create a context in which other people can think.” Likewise, the skill of leading an organization, or creating an architecture, or creating a strategy, is structurally analogous: you are creating a context in which other people can succeed.

The job of the architect, CTO, technology manager, or strategist is to determine how to create a context—design a system—in which new concepts can erupt and evolve (they’re extensible) and people can do the best at what they do (they’re fit for purpose).

The outcome is the difference your output makes to a customer. Outcomes are the Why. They represent the benefits your customer gets.

The vision is a single sentence characterising the end state. If you don’t understand the problem you’re solving, or the desired outcome you would get at the end, you will just rearrange the deck chairs

Here’s my definition of an architect’s work: it comprises the set of strategic and technical models that create a context for position (capabilities), velocity (directness, ability to adjust), and potential (relations) to harmonize strategic business and technology goals.

Over my 20 years in this field, I’ve come to conclude that there are three primary concerns of the  architect:

Contain entropy: The architect defines standards, conventions, and toolsets for teams to use. These are common practices, and generally idiosyncratic to any given organization. As application or solution architects, they help within a system, within an ecosystem, and across an organization to create a common set of practices for developers that help things both go quicker and be more understandable and maintainable. This is a form of containing entropy. the architect works to ensure that there is alignment between the systems, yes, but also between those systems and the organization, and between the organization and its stated aims. The architect who is containing entropy is stating a vision around which to rally; showing a path in a roadmap; garnering support for that vision through communication of guidelines and standards; and creating clarity to ensure efficiency of execution and that you’re doing the right things and doing things right.

Specify the nonfunctional requirements: The nonfunctional requirements are properties of the system that do not necessarily appear directly to the user. They are typically described as the “-ilities.” The ones I focus on most are scalability, availability, maintainability, manageability, monitor ability, extensibility, interoperability, portability, security, and performance.

The architect is responsible for specifying how the system will realize the functional and nonfunctional requirements in its construction. In order to do so, she must write a document that specifies how these will be realized.

Determine trade-offs: you’re never quite solving a problem. You’re only trading it for one that you’d rather have.