Our Articles

A Monthly Article from our Speakers

Current Article of the month

Articles of 2020

Articles of 2019

Articles of 2018

Articles of 2017

Articles of 2016

Articles of 2015

Articles of 2014

Articles of 2013

Articles of 2012

Articles of 2011

Articles of 2010

Articles of 2009

Articles of 2008

Articles of 2007

Articles of 2006

Articles of 2005

Articles of 2004

Articles of 2003

Articles of 2002

Mike Rosen Are you doing Architecture?

by Mike Rosen

January 2013

 

In a recent conversation with a client, I was reviewing the activities that their architects were performing. As you can imagine, those activities ranged from following procedures, organizing meeting, investigating issues or technologies, performing reviews, writing documents, creating models, mapping strategies, and so on.

One of the challenges with defining architecture and particularly enterprise architecture is that an architect has many different roles. But one question we don’t often ask is should they be performing those roles, or put another way, what roles should architects be performing? This led to another question: Are we doing architecture?

I propose that we are “doing architecture” if we are exercising architectural skills, applying an architectural method, creating architectural artifacts, or providing architectural value. There are probably other qualifiers, but that’s enough to start.

Architectural Skills, Methods, and Artifacts

So what are architectural skills? A few years ago I wrote an Executive Report called “Ten Things an Architect Does to Deliver Value” which elaborated on the list below:

1. Inquire – Get to the core of the problem, question assumptions, and solicit requirements.
2. Integrate – Put the problem at hand into a big picture view.
3. Analyze – Organize the collected information by answering three architectural questions: a) What are the key elements of the problem or solution? b) What are the relationships between them? and c) How do they combine together to provide value?
4. Conceptualize – Create a conceptual vision of the solution.
5. Abstract – Highlight the key concepts while suppressing irrelevant detail.
6. Visualize –Create visual renditions of the abstractions and viewpoints.
7. Formalize – Create an unambiguous specification of the details so that it can be implemented and verified.
8. Communicate – Explain / evangelize the solution, as well as its importance and value.
9. Enable –Make the architecture easy to use for the target audience.
10. Assist – Consult to stakeholders or projects.

This set of activities also describes (at a high level) an architectural method. Some other characteristics of an architectural method are the application of principles, conformance to standards, and integration of patterns and other best practices. If the activities that your architects are doing are some combination of these, there’s a good chance that they’re doing architecture. It seems fairly straightforward that creating architectural artifacts involves doing architecture, but we might want to require a certain level of quality and conformance to methods, principles, and standards before we actually call it architecture.

Architectural Value

What is architectural value? That’s a question that has been debated for decades, and will continue to be argued for years to come (at least until we are consistent in delivering value with architecture). I don’t have a mathematical formula for calculating it (although I recently saw a PHD thesis that had pages of such formulas for the value of solution architecture), so for me it’s more ‘I know it when I see it’, and when I see it, it has some or all of these characteristics.

• The incremental specification, provisioning and utilization of ‘assets’ that provide value across projects and initiatives. ‘One way to do one thing’. ‘One place to get specific data’.
• Risk mitigation, cost avoidance, and strategic alignment.
• Faster time to market, higher quality, improved consistency, increased Return On Assets (ROA), and greater agility and flexibility, from the reuse of business, information and IT capabilities.

So, if the activities that your architects are doing are resulting in the creation or utilization of reusable asset and architectural value, they’re probably doing architecture.

Having somewhat answered the question “What does it mean to be doing architecture”, we might want to turn back to the question of what roles our architects should be filling. Of course not all of the roles that they perform need to be doing architecture, but probably the majority of them should. Otherwise, are you wasting a valuable, and probably rare resource in your organization?

Another important question is: are any of the roles that your architects are filling undermining their ability (or credibility) to do architecture? Do the roles require them to take a particular point of view or position that is contradictory to architectural principles? Are there roles where they are not following standards, while at the same time their other roles involve creating and enforcing standards? Perhaps it’s time to take a look at what your architects are doing.