Architecture The Practice vs. The Noun
I had the pleasure today of working today with Novak Ratkovic on a project related to architect education. Novak is a brilliant guy who asks tough questions. Exactly the type that I like the most. His question today was based on the 1 day Enterprise Architect Mindset class we will be launching shortly. His question revolved around the Iasa definition for architecture. I kept describing the definition of architecture as a practice and he wanted to understand more about architecture as a noun.
Iasa Architecture Definition
- The art and science and science of designing and delivering valuable technology strategy.
- A business technology strategy; any document which describes a technology strategy which creates measured value for a customer, client or employer.
- The architect profession.
First, you might notice that the definition is, in fact, three definitions, though I will continue to use it in the singular as in the definition of the term medicine. This definition (set of definitions) was not arrived at lightly, and while it is reasonably simple, it is complex in both nuance, implementations and relationships. In fact, you will find that it completely flies in the face of both standards and much of common (not best) practice.
The Iasa definition combats the notion that architecture is simply design of a system (based on systems theory where system is more than technology) and does so for very specific reasons, most of which I will not address in this post but will do so later. The international standard definition for information and technology related architecture is captured in ISO 42010.
ISO 42010 Architecture Definition
“(The) fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution”
As you can see there are some serious differences between that definition and the Iasa definition. But if you look in practice and in depth, you will find that the Iasa definition provides signficantly more clarity for practicing architects as well as signficantly more depth of practice over time. Effectively the Iasa definition is better for us as a profession and more accurately reflects a fundamental principle of our beliefs, that the architect profession is distinct (from engineering and other roles) in its ability to create true architectures. It also lays a foundation for the practice of architecture including specializations such as business and information architecture.
How is this true? First, and please pardon me for saying it, but the ISO definition does not solve a problem that is societal or distinct from other fields. We see professionals because they do something for us that is important. We see a doctor because they ‘cure’ us. We see a lawyer to ‘represent’ us. We see a building architect to ‘build’ for us. Each of these is a problem that we cannot solve for ourselves. At Iasa we have made that problem/solution relationship clear. Engineers are fully capable of designing the properties of a system in its environment. But do they create business technology strategy? In rare instances, yes. But on the whole they create systems engineering designs which fulfil the ISO definition but not the Iasa definition. This is absolutely critical in definiing the value of employing architects AND engineers/developers on a software system or the equivalent on a operations, infrastructure or information system, but it has the FURTHER benefit of retaining it’s value when including business and enterprise architects!
Years ago we created a reference model which only made it to alpha draft status. This included many practicioners and thought leaders of the time. But at the core of the model was a critical difference, that makes all the difference for architects as a profession. Here is a relevant portion of that model (note: this is neither complete or rigorous as I just started moving it to lucidchart for the purpose of this blog). The FRM will be rolled into the ITABoK effort and will provide a significantly more comprehensive model than the ISO standard.
It also enables the architect to interact with the entire life-cycle of an idea all the way through exploit (commit, build, run, exploit) and provides a common interaction point from strategy through change management.
https://www.lucidchart.com/documents/embeddedchart/e7f3d1f0-89aa-4672-ae02-bdbda97cdd22
As you can see, the connections based on architecture being a strategy as apposed to an attribute of a system means that an architecture is what an architect creates to describe a strategy. A good architecture is one where that strategy has been executed and measured and value has been created.
As I said, simple, yet nuanced. But extremely powerful in defining a baseline for a valuable profession as opposed to a role.
