In my last post, “Locking Down the Prisoners: Control, Conflict and Compliance for Organizations”, I returned to a topic that I’ve been touching on periodically over the last year, organizations as systems, which overlaps significantly with the topic of enterprise architecture (not to be confused with enterprise IT architecture of which EA is a superset). While I do not pretend to be an expert on the subject, the fractal nature of the environment I work within as a software architect makes it difficult (perhaps even dangerous) to ignore.
Systems reside within ecosystems, which being systems themselves, reside within an ecosystem of their own. Both systems and ecosystems are mutually influencing and that influence must be understood to the extent possible and accounted for, both upstream and down. Where this fails to happen, coherence between information systems and social systems breaks down. Significantly, issues in systems at higher levels of granularity can negate positive aspects of the systems that comprise them.
This is probably a good place to point out that my use of terms like “social system” is not meant to remove the human aspect. On the contrary, social systems are intensely human in nature. Where those systems are dysfunctional, it is individuals that ultimately pay the price. The intent, is to point out the inter-relationships that make up our environment.
Consider the hypothetical systems outlined in “Making and Taming Monoliths”. Assuming all of the systems involved were modular enough and technically capable of interoperation, it would not be enough. Considerations of data architecture (starting with, which system is authoritative?) could spike the effort, or at least seriously delay it. Organizational structure (aka Conway’s Law), behavior (management, governance, process), and psychology/culture could all either impel or impede. A perfect example of this concept is the near requirement that DevOps be in place where microservices are used – it may be possible to develop and deploy microservices in other process models, but it will involve far more difficulty.
“Alignment” is a term that is often mentioned in terms of IT. However, even if an organization’s IT systems are perfectly aligned with the business units they support, it will do little good if those units are working at cross purposes. Just as the full stack of an application requires coherent, intentional design to work well, so too does an enterprise. This does not, however, imply that a rigid, top-down mode of operation is needed; it’s actually quite the opposite.
In “Auftragstaktik and fingerspitzengefühl”, Tom Graves described the UK’s World War II air defense system as an example of an effective enterprise. The two German words refer to the concepts of situational awareness (fingerspitzengefühl) and mission tactics (Auftragstaktik), which underlay the success of the system. In essence, situational awareness at each level was enabled by the flow of information up and down the hierarchy, while decisions appropriate to each level were made at that level informed by understanding of the situation and the commander’s intent. This is not just a matter of process. As Tom noted:
Another key element is organisational-culture – whether the culture invites or dissuades individual judgement within real-time action (auftragstaktik), elicitation and capture of real-world subtleties (for fingerspitzengefühl) and/or whistleblower-type algedonic responses.
An organization must not only be structured so as to achieve its aims, the drive to do so must be part of its DNA. Even when some components of the organization may have remits that conflict with others (think audit, accounting, InfoSec, etc.), the ultimate direction of all parts should harmonize. Structuring a system so as to resolve conflicts is an architectural practice, regardless of the type of system.
3 thoughts on “Full Stack Enterprises (Who Needs Architects?)”
Pingback: Inflection Points and the Ingredients of Innovation | Form Follows Function
Pingback: Organizations and Innovation – Swim or Die! | Form Follows Function
Pingback: Monolithic Applications and Enterprise Gravel | Form Follows Function