The IT community use the terms Business Architecture and Enterprise Architecture to describe the activity of “setting up” the business or the IT systems.   As a business strategist I have always found this language difficult.   I first came across it when asked to teach on a PA Consulting internal course called Business and Enterprise Architecture.  I was teaching organisation structure using ideas from my course Advanced Organisation Design.   I detected some discomfort about the name of the course, and after the first year, it was changed to Business Design.

Since then I have been in conversations about both Business Architecture and Enterprise Architecture with experts in both disciplines without really understanding what the term “architecture” refers to.   The building analogy is often used:  the “architect” produces the “blueprint” and external design.   But what is the equivalent in business terms.

In conversation with Peter Murchland, a business architect from Adelaide, he mentioned that Enterprise Architects are often referring to the “inanimate” when they think of architecture: the information architecture, the applications architecture and the infrastructure architecture, etc.

More recently I have been doing some thinking about different types of decisions.  Then it occurred to me that some decisions in business are “architectural”, meaning that they are hard to change and will influence other things for some period.  Other decisions are more day-to-day operational choices that impact the moment but do not constrain the choices that can be made tomorrow.

For example, where you locate is an architectural decision.  It has an impact on who you are likely to hire, and which customers you are likely to interact most easily with, and it is a decision that is not easy to change on a day-to-day basis.  So it is a “design” decision (or should I say “architectural” decision).   The organisation structure (whether to organise by country or by product line for example) is also a “design” decision because it has big knock on effects and is difficult to reverse.

In contrast, what job I give to Fred to do this afternoon is a day-to-day decision.  Which customer to visit tomorrow morning is a day-to-day decision.   Setting up a project team to discuss pay grades is a day-to-day decision: but, of course, the recommendation the project team makes about pay grades is a design or architectural decision.

So, my thought is this.   Some decisions need to be made in advance before an organisation can operate: what to do, where, with what equipment, with what kind of people, in what organisation structure, guided by which values, governed with what sort of processes, etc .  These are the design decisions or architecture of the organisation.  Once “set up” or “designed” most of the decisions that are then made are day-to-day.  But, if a subsequent decision is one that will be difficult to reverse or have significant knock on effects, it is a “design” decision and hence part of “architecture”.

Forgive me if this is all old hat – but I have found the distinction useful as I work on operating models.