What is an Architect?

Technology Architects and Strategic Planners may be the most confused roles in the IT industry. Depending upon whom you ask or where you look, the definition varies dramatically.

While the industry has struggled with defining the role of an Architect, an alternate label has also come into common use, which is the Strategic Planner. Of course, this also is poorly defined. From my perspective, an effective Information Technology Architect and a Strategic Planner both fill the same role. For the sake of simplifying the conversation, I will use the term Architect.

Some common perceptions of an Architect are:

• A lead developer or engineer.
• Somebody who understands the overall technology systems of a business and knows where each part fits.
• Somebody who designs software systems and can program well.
• Somebody who wrestles with the challenges of how a system works and designs a usable system.
  Somebody who changes technology, or an “agent of change.”
• Somebody who dictates technology standards, but often without understanding the needs.
• Somebody who designs a new technology infrastructure or software implementation for a business.
• Somebody who is difficult to work with.

None of these roles directly addresses relationships and mitigating fear in relationships. In many cases, the relationship with an Architect is considered in the negative context—that they are difficult to work with.

Because of the fear everybody holds about the rate of change for technology, we all want to have somebody else worry about the big picture. But at the same time, we want to control the smaller part that affects us, without somebody else meddling in it. This is a catch-22 scenario and is likely why the role of Architect is so confused. We understand the need for somebody else to recognize the big picture, but we aren't comfortable with defining what an Architect should do, besides just knowing the big picture.

An Architect is commonly perceived as a gatekeeper in this scenario. The dialog usually goes something like, “I want to do this thing, may I please do it?” and then cringing while waiting for a declarative reason the wanted feature will not work, or even a lengthy dissertation on how it flies in the face of everything ever considered for future strategies.

The question posed above defines the conventional Authoritarian role people consider an Architect to hold, and they resent it. This relationship is much more effective if the aspect of Design Thinking and planning is brought into the mix. An Architect placed in an organization with an Authoritative position instead of Authoritarian, along with the proper tools, can change the question in a beneficial manner. The simple way to keep these two concepts separate is to consider the word sounds themselves: Authoritative works in a consultative fashion, where Authoritarian tends to tear apart relationships.

The difference between the two is important, and it centers around fear and change. An Authoritarian role comes with force and inflexibility, where an Authoritative role is consultative and guiding. An Authoritative role creates a healthy relationship with each member of a team. Authoritative recognizes and understands the boundaries (strategies), but also recognizes that exigent circumstances come up and is willing to work out variances to facilitate progress.

In this context, the question posed above can be rephrased as, “I want to do this thing. Do you see any problems with it? And if so, can you help me work out a remediation effort?”

Considering these things, the role of an Effective Architect (Authoritative) can be described by four key elements:

• Relationships – The ability to empathize with both technical and non-technical audiences, understand their needs and fears, and be able to communicate with all in a language they understand.
• Analysis – The ability to decompose complex systems into digestible elements, and the capability of understanding the technological relationships among different needs.
• Planning – The ability to understand the business’s core needs, industry direction, partner road maps, and how to bring these together in concert to provide an effective solution.
• Execution – The ability to enact plans. What role does an Architect take during the different execution and control phases of a project?

A final consideration on Architects in an organization is the degree of technology ownership they hold. If they are the ultimate decision maker, it is more likely that they will slip into an Authoritarian role. However, if they exist in a role that empowers them to be a valuable reference asset, this enables them to be Authoritative.