Can I be a [Something] Architect too?

I started thinking of myself as a Business Architect in 2009. It was after finishing a project where I had worked alongside someone who referred to them-self as one. 

I had done the same kind of work: I'd had similar discussions with similar people and produced similar outputs (e.g. documents, models, schematics, presentations, etc.). Moreover, I much preferred the title to that of a Senior Business Analyst or Business Process Designer or Service Design Lead or such-like. For reasons I couldn't quite explain, 'Business Architect' sounded more professional, more successful, and reassuringly more expensive! 

And anyway, lots of other people were becoming architects of some denomination or other - enterprise architects, solution architects, IT infrastructure architects, IT application architects, data architects, security architects, programme architects - why couldn't I jump on the architect bandwagon? 

Competence vs qualifications 

Most of the (frequently self-titled) Business Architects I knew were good analysts and good designers, i.e. they were good at framing, understanding and designing solutions to big, complex problems. Most were methodical and organised and good at managing work. Many also had consulting experience, presented well, were commercially astute, and were good at 'managing' clients ... 

However, very few were accredited to any institution or professional body; few had been on the same training courses or read the same books; and most used the same terms in different ways or to mean different things. No two practitioners described either what they did nor how they did it using the same vocabulary. 

Opinions & dogmatism

For a long time, I watched from the sidelines as online communities of business and enterprise architects debated various concepts and definitions of the very nature of the discipline, the role, its methods, outputs, interfaces and value. 

In fairly equal measures; I nodded, guffawed, scratched my head, and rolled my eyes. But I soaked it all in. 

After a while, I started 'liking' comments on online forums that resonated with my way of thinking; began following similarly-minded contributors; and carefully ventured the odd opinion of my own. I broadened my understanding and refined my thinking. And I realised that there will be people whose opinions and beliefs will not change - not even in the face of reasoned argument. 

Broad consensus on many aspects of Business Architecture (i.e. that what Business Architects do) - across geographical, industry and organisational boundaries - seemed a long, long way away. So I looked at more established architectural disciplines for answers, inspiration and enlightenment. 

What is an architect? 

Even traditional/building architects struggle to accurately describe what they do and how they do it. And they've had hundreds of years to come up with an universally accepted definition! 

• Doug Patt's YouTube channel talks extensively about the theory and practicalities of how to architect here. 
• The NSW Architects Registration Board (Australia) describes what an architect does here. 
• The American Institute of Architects (AIA) provides an informative video of what architects do here. 
• Enoch Sears provides an excellent description of the different facets of the role of an architect here. 

But my favourite description is by John Whitten, who describes the role as: 

... a professional babysitter that works on really big group art projects with a bunch of kids that may or may not play well together. We provide the vision, organize the chaos, and stop the bickering and make sure there is something at the end to show the parents.

... which sounds strangely familiar. 

Defining characteristics 

Having researched various architectural domains, it struck me that:

An architect is someone that uses an architectural method. Just like a scientist is someone that uses the scientific method. 

It also struck me that, regardless of domain, architects tend to possess the ability to:

• Build and maintain good relationships with clients and their representatives 
• Identify, develop and maintain effective relationships with consultants, contractors and regulators 
• Maintain a depth of knowledge across their domain 
• Maintain a breadth of knowledge across related domains 
• Quickly and clearly communicate ideas and concepts 
• Develop and apply design principles, frameworks, patterns and themes 
• Sketch and model (i.e. abstract and simplify) 
• See something from multiple perspectives and levels of details 
• Identify, understand and frame problems 
• Know when and how to resolve ambiguity 
• Identify and assess risk and criticality 
• Manage and adapt to change 
• Challenge (constructively) 
• Negotiate and compromise 
• Motivate and inspire 
• Be inspired, experiment and innovate 

And whilst this list of abilities is neither exhaustive nor authoritative, it does describe a skill-set that sets architects apart from other roles that are common to multiple domains, e.g. designers, planners, project managers, programme managers. I'd even go so far as to question whether a 'something' architect that doesn't demonstrate these abilities isn't actually performing a different role. 

Many 'something' architects seem to spend more time designing than framing and governing the design process. 

Architecture is not design 

[Building] Architecture is not 'building design'. Nor is it 'design of the built environment' or 'design of complex structures and spaces' or other such. 

At its most abstract, architecture is the governance of design. It assures the quality of the design process which, subsequently, assures the quality of what gets (planned and) built, i.e. realised. 

Architecture is a means not an end. It is the means by which the desires and ideas - the ‘vision’ - of the Client are considered and developed within the context of environmental, socio-cultural, political, economic, legal, philosophical and technological concepts, trends, and constraints. And it is the translation of the vision into an integrated, coherent set of design artefacts (e.g. sketches, models, blueprints, schematics, etc) that enable the vision to be fully realised. It guides, constrains and challenges the design process. But it is not ‘design’. Design is design. Architecture is architecture.

When is an architect not an architect? 

Answer: when they're actually an (experienced) analyst/surveyor, a (senior) designer, a (lead) developer/builder or subject matter expert. When they don't apply architectural methods to a given scheme, project or commission. When they don't demonstrate an architectural mindset. When they don't secure or use the authority required by the very nature of the role. 

All architects are designers. But few designers are architects. 

----------

Ben writes for Guild Consulting - creators of simple, scalable systems for small businesses. They help remove unnecessary complexity, anxiety, frustration and spreadsheets from business operations. They help make small businesses run like clockwork.

You can read his other posts here, including: 'Why beehives aren't the size of sheds', 'Your goal isn't to make money' and 'Do I need a Business Architect?'.