An architect is often seen as a generalist who needs to know a little about everything. Although this is technically true there are still some concepts every architect should master in every detail. So far I can list the following three, in order of importance (first being most important).
- Information – Behavior – Structure
- Systems Thinking
Abstraction lies at the core of almost every single method, tactic or model an architect deploys. The vast majority of issues I encounter with architectures are directly related to insufficient understanding of abstraction. I am not talking about just “leaving out details”, I am talking about a deep understanding of what abstraction really is: generalization-specialization, idealization-realization, composition-decomposition and the large influence it has on everything we do as an architect.
For a good introduction to the subject I recommend Graham Berrisford’s site (“Library” and “Methodology” sections). I deliberatly don’t deep-link so you’ll have the benefit of wading through all his material, highly recommended. But realize that this is even just the tip of the iceberg!
Information – Behavior – Structure
Closely related to the third topic (Systems Thinking) is the distinction between information, behavior and structure. A concept that is known since at least the 70’s in information analysis and lies at the heart of most methods we use today. Structured analysis and design is the mother of most relevant methods and modeling we know today, itself it is a continuation of general systems thinking and cybernetics. More recently the ArchiMate notation has reintroduced these concepts for the masses.
Again, I am not talking about merely knowing the difference but about the impact it has on our daily work. Applying abstraction to the concepts of information, behavior and structure is one of the key elements needed for true mastery of architecture.
Finally my (so far) last “fundamental” is (general) systems thinking and it’s children like cybernetics. This fundamental is probably more relevant for enterprise architects. Solution and application architects are more often dealing with systems that can be modeled using mechanistic views or simple deterministic or animate systems (see Russell L. Ackoff and Jamshid Gharajedaghi, “On the mismatch between systems and their models“). Nevertheless all architects benefit at least some from a deeper knowledge of systems thinking. Even though I may be haunted for saying this, but most SOA architecturs fail at least because the systems-aspect has been neglected.
What do you think, is this list too short? Are there any fundamentals missing? Leave a comment!