Context carries tremendous importance in disambiguation of meanings as well as in understanding of the actual meaning of words. The word “architecture” is exemplary in this regard.
So first I will focus on the contexts in which the word “architecture” is being used. Without understanding the different contexts, there is no clear road to a defining story. For the moment, I will just ignore the enterprise, the domain of prime interest. It is just about “architecture” in general as there must be a reason that the word is used across widely diverse domains.
So then, what are the different contexts? One fact is clear. Dictionaries offer only limited assistance as they show little formal recognition of those contexts.
The start is a quote from Grady Booch (@Grady_Booch) that intuitively feels right:
“All architecture is design but not all design is architecture.”
With a little further help of dictionaries, one can already discover different usages:
- design / architecture as a noun (state): a design / an architecture
- design / architecture as practice of doing design / architecture, thus a verb (action): to design / to architect
Without yet trying to determine the difference between architecture and the remainder of design, it feels right to state that, both design and architecture represent arrangement or structure.
With that in mind I have come up with a first revision of a model in an attempt to capture all arrangement- or structure-related concerns:
Centre piece is concrete structure (A), the actual state of structure (states are boxes) as it exists in the reality of a building, a city, a software-intensive system or a social system (for example an enterprise); any object or system really. Concrete structure is often not really static, thus not a state but in order to get to understanding it is conceived as an image being taken thereby capturing the moment and so turning it into something static (The same recipe is applied for the other states for which the notion of a baseline is common practice). Mostly, the dynamic aspects of especially architecture over a small period of time are of limited concern anyway. There are reasons why, that I will tackle later.
An immediate question that arises from above notion, is how concrete structure comes into existence, an actual action to structure (actions are arrows). Another quote from Grady Booch provides some further clues here:
“Most architectures are accidental, some are intentional.”
In other words, concrete structure either emerges (1), is engineered, or is a mixture of both. Engineering is a composite action; it consists out of several other.
A key means in an engineering effort of any concrete structure is a structure plan (E), either a mental plan or a material plan that, by addressing necessary action and targeted concrete structure, assists in the realization (3).
The conception (7, 2) of any structure plan seems to be either based on something that has been proven to be wrong, hence the negative outcome of structure assessment (C) or to be right, the structure template (D).
Structure templates are structure styles, patterns and/or tactics, or combinations of those in the form of reference models, with both structure as state and as action, that have been recognized (6) as proven to be right for specific purposes based on the positive outcome of structure assessment. Typical examples of structure templates in building architecture, styles in fact, are Romanesque architecture, Gothic architecture, etc.
Of course there is the action of selecting proper and/or recognizing improper structure templates and properly (re-)combining for the now targeted concrete structure, the conception (2, 7) of the structure plan. Hence it is in this action that the purpose of the targeted concrete structure is to be taken in account.
Concrete structure is often difficult to understand, especially when it is at least in part result of emergence for which obviously no structure plan can be available. Hence, it is appropriate to analyse (4) concrete structure in order to build an understanding through the creation of a structure model (B). Structure plan and structure model can show similarity only when the concrete structure is highly engineered. Anyhow, the structure model will only offer a representation based on specific concerns, a simplification for the further purpose of either single or comparative assessment (5). Single assessment can lead to re-engineering so to better align structure with purpose. Comparative assessment can lead to the recognition (6) of structure templates.
The words design and architecture are used as being all of the above, as the concrete structure, the structure plan, the structure model, the structure assessment and the structure template, as well as the practice of conceiving, realizing, analysing, assessing and recognizing.
The path from thought to the 'dry', 'sec' essence 
Indeed, context (enterprise) is very important! But just as with all journeys, if you take a wrong turn at the start of it, you will end up nowhere near your goal. And with the constructed hypothesis that “both design and architecture represent arrangement or structure” the very difference that Gooch eluded to is missed. Every man made material object is designed indeed and yes, even concepts, such as UML, are. But we all intuitively understand the core difference between say a hammer and a painting. The usual hammer is designed with different goals in mind then the painting! That is the core of the difference: the goal of the end-product’s effect on humans. And that is why “all architecture is design but not all design is architecture”. Design aims at the objective and practical end result, as does architecture, but only in part. Architecture aims at subjective perception..!
The word ‘structure’ is used 38 (!) times in this post which suggests to me that the article confuses architecture with engineering. This ‘confusion’ is also enforced since the very word ‘engineering’ is used six times from the middle down in the article, and in such a way that it either seems to imply that architecture = engineering, or even that this article is really about… engineering.
Taken this article in the broader context of Enterprise it must be evident that, even though structure and engineering are part of an Enterprise, these are not ‘the’ Enterprise, not even the core of it… Engineered structure does not cover “the total end result [of architecture] that reflects functional, technical, social, and aesthetic considerations”, not by a long shot.
For all these reasons I even advise against the use of the word Architecture as a noun, other then maybe to refer to the effect that the end result of the Architecture process subjectively has on people. See my previous post on definition for further understanding of where I am coming from.
Thanks a lot Paul, for sharing your thoughts. It may not seem obvious and is unfortunate but your comment is kind of what I feared as a response as I mostly agree with it. I share many of your concerns and will address them, but will do so from quite a different angle. First I need a build-up to arrive there.
Indeed structure is key in my reasoning – that apparently became clear – but you seem to miss my point that I see enterprise structure primarily as “emergent”, not engineered. Moreover, a lack of structure, or an apparent lack of structure, is also a state of concrete structure. I have barely touched upon that so far so I would prefer that conclusions are not made too fast. Those are the so-called loose ends that I was already warning for. Anyhow you are keeping me aware.
Many of the conclusions that you associate with the post aren’t really mine so apparently I also need to work on further clarification…
Hi Kris,
Just a thought. Is it a smart idea to tell about concepts used in building design when the concept that you try to describe has nothing to do with buildings in the first place?
I have seen the usage of the explanation of the noun “architecture” in many books on Enterprise Architecture. Usually it is used to introduce the reader the concept of EA, but it rarely makes sense due to most people who are studying EA hasn’t experience with “construction and architecture” at a construction site.
Perhaps a better analogy has to be used to communicating the process of designing the desired state for the enterprise’s architecture. It is just a thought.
Nevertheless I think it is an interesting blog post you’ve written.
Best wishes,
Peter Flemming Teunissen Sjoelin
CoherencyArchitect.com
Hi Peter,
Thanks for your interest and tweeting a link to this post. Nevertheless I think you misunderstood. Maybe my fault of not being clear enough. It was definitely meant to be about architecture in general, especially about architecture in general, not limited to one specific domain, neither building nor enterprise architecture. I just used examples of different domains to clarify.
Today the word “architecture” is used in pretty different domains. Apparently many intuitively use the same word for “something” accross domains despite many perceived dissimilarities between those domains, and many continue to do so. I believe intuition is not misleading here, but that it is far from easy to capture the common essence clearly. I see it as a challenge to build the case, as a story, that the usage of the word across different domains is really justified. That is absolutely not to say that I believe that all architecture can be engineered, far from that. Designing the desired state for the enterprise’s architecture sounds a lot like engineering.
I admit it will take far more than this post alone to reach that end.
Anyhow I am not completely happy with this post in its first revision. Nevertheless I believe I am on the way of capturing something I have not seen well explained yet. I have been working on a new revision and publication will hopefully be not too long away.
Thanks again, any feedback is really welcome as it helps me in getting things sharp(er). I would definitely be interested in your further thoughts.
Hi Kris,
Thanks for your reply. I’ve misunderstood your intentions with the blog post. I assumed it dealt with the concept of Enterprise Architecture (as in Enterprise Engineering).
In cases of Enterprise Architecture theory and books, the concept of the “construction site” or “building architecture” is used. As I see it, it is rarely a good analogy, since it is presented to people (including myself) who have never taken part in the construction of a building, and as such many theorists and authors spend a lot of energy comparing one form of architecture to another to give the readers an understanding of what Enterprise Architecture is all about with no apparent results. In many cases they waste their resources and effort due to the assumed audience don’t know much or anything about the building architecture and as such fails to recognize the “synergies” of the comparison of the different forms of architecture. E.g., Zachman does exactly this in one of his initial papers on Enterprise (IT) Architecture, despite his good intentions with the comparisons of architecture, it only makes sense to engineers, builders or (building) architects and not to those people who takes the decisions in the enterprises (CXOs, economists, administrators etc.).
As I see it is important for theorists within the field of Enterprise Architecture to spend more resources and effort to explain what it means in order of organizing the organization (meetings, groups and business psychology) to gain the benefits of a structured approach to enterprise governance that in turn adapting the various standards, principles and ideas that is centered around the concept of Enterprise Architecture and Enterprise IT Architecture (as in Enterprise Engineering). It seems to me that quite a few of the theorists within the field of Enterprise Architecture and Enterprise IT Architecture thinks that the enterprises are like machines or buildings, when they in reality have to deal with people and their behavior, as such they should view the enterprise as something like a hybrid between machine and organism.
Perhaps the scope has to be on ontology and behavior instead of engineering and architecture? But then again it is just an idea of mine.
Best Regards,
Peter Flemming Teunissen Sjoelin
CoherencyArchitect.com