Tom Graves writes about whole-of-enterprise architecture, where the enterprise is far greater than any single organisation or even individual markets. Similarly, whole-of-enterprise architecture concerns go far beyond the technology domain.
When working at the scope of individual systems, I have realised that we can benefit from taking a similarly whole perspective: I suggest thinking in terms of whole-of-system architecture can be useful and, in my work, necessary. Software systems certainly play an important role in my work, but people play vastly more important roles. As do relationships between people, groups of people and various forms of organisations. Furthermore, we need to talk about processes and data. The list goes on an on.
Even when thinking only about the technology aspects of such whole-of-system architectures, we usually have to consider runtime (or deployment) architecture concerns, development-time concerns (form, function and structure of code) as well as the tools and processes for helping us to build, deploy and manage the technology components of the system.
Thinking about this further, we might consider a system in this broad sense to be a fractal element of a larger enterprise, and therefore, perhaps, a small enterprise in itself. Consequently, whole-of-enterprise architecture insights may well apply. If so, whole-of-system architecture can then be understood as a specific type of whole-of-enterprise architecture (i.e. one tied to the system scope).
Having gotten the above out of my system, I can now start to sort it out. Would you care to help?
Bob Marshall “didn’t sign up for all this people shit“. Neither did I. But like Bob — and Tom and Stuart and Ruth and Chris and Dave and so many others before me — I’ve come to realise that talking about the architecture of software-intensive systems might be distracting me from the core of the problem of building and running effective systems (although they haven’t phrased it in exactly these terms). Focusing on people and their needs might be a more effective approach. This is tough, at least for me, and I can fail at this in the most spectacular ways.
If a classification seems necessary, thinking of the architecture of people-intensive systems might be more useful to me than thinking of the architecture of software-intensive systems.
I’ve been struggling with the architecture of people-intensive systems more concretely:
In Lean Architecture for Agile Software Development, Getrud and Cope describe a system’s architecture in terms of what the system does (function) and what the system is (form).
(As a side note, their work includes the only substantial discussion of form (as distinguished from structure) of software systems I have come across so far.)
But what about the information managed by the system? Wouldn’t we also want to discuss what the system knows (in a casual sense of the word)?
Architecture descriptions (at least most of the ones I’ve seen) tend to discuss relevant data or information models in the context of a system’s structure (i.e. its major building blocks), but that never felt quite right to me. Or is discussing what the systems knows unnecessary because we could include data capture, storage and retrieval in the context of a system’s function?
I’d love to hear your views on this topic.
2014-04-06: Function & information: a useful duality? might be relevant in this context.
2014-03-16: Clarified that I used “what the system knows” in a casual sense. This may not have been a good idea — see the comments below.
2014-03-15: Correction: Form describes what the system is in this book, not structure. Also added “major building blocks” to somewhat clarify what I meant with “a system’s structure” in the last paragraph.