Author’s note: this post is part of a longer series intended to generate discussion around the evolving demands a modern marketplace places on the tenets of “traditional” Enterprise Architecture. Parts one two of this series can be found in my profile.
In previous entries, we’ve posited that disciplined application of principle-driven strategic decision-making can help counteract unbridled complexity. Where this process is best positioned organizationally will vary based upon the culture and structure of a given firm; however, the discipline will only succeed if expressly assigned to accountable and empowered individuals.
The work of managing technology complexity is not transactional. It is not a one-time effort that, once completed, is forever done. Rather, to address the continuous appearance of technological entropy in an organization, there must exist an equally continuous will and effort to manage it. Contrary to the hopes and dreams of many IT executive leaders, there is no single consulting engagement or process that can forever banish the erosive effects of entropy from a company’s technology. It is rather a commitment to applying human attention and work through dedicated assignments that help an organization steadily pull the weeds from their IT garden. This role requires executive commitment, strategic insight, courage, and an ability to communicate complicated realities in clear and understandable terms to facilitate decisions and action.
This role of systemically understanding, tracking, and countering complexity is traditionally that of an Enterprise Architect. How is it that an architect is responsible for work focused on Complexity Management? Using this title is admittedly a concession to the culture and history of IT. The role of architect exists in many forms in many organizations but is intuitively understood across the industry as being the most senior and influential technologist with a given scope. Although there is poor standardization of precisely how the role of an architect is different from many other engineering roles, there is a qualitative differentiation in most settings that place the architect as the ultimate technology decision maker within their scope of concern.
This contemplation of the role of an architect cannot be separated from the work of architecture itself. As we have already seen, the work of managing technological entropy at enterprise scale is the careful and consistent application of principles with the goal of establishing strategic consensus anchoring ongoing technology decision-making. The traditional analogy of a building architect breaks down under a body of work centered on continuous reduction of complexity. However, in their standard 1471, the Institute of Electrical and Electronics Engineers (IEEE) offer a helpful definition of architecture as “[t]he fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution.”
This definition connects this role of architect (i.e “[t]he person, team, or organization responsible for designing systems architecture”) and the need to manage complexity. The critical part of the IEEE definition is the anchor into the rationale and logic guiding the engineering and implementation of an Information System.
Architects steward the motivation and rationale behind specific design and engineering decisions. They bear the responsibility for determining, articulating, communicating, and enforcing this logic. In other words, Architects apply principles. Managing enterprise technological complexity is enabled through the application of principle to technology decision-making. Working from these definitions, it follows that Architects (per IEEE) would be the parties responsible for this work.
This definition not only clarifies architecture’s purpose within the enterprise but also clears some of the confusion typically surrounding the title of “Architect.” An Architect’s role isn’t “architecting” but stewarding the responsibility for applying principles within a given scope of concern. This scope in turn results from an apportionment of the fabric of Information Systems into non-overlapping domains, but it is the question of staffing accountability that sharpens the need for such a domain portioning in the first place. The massive, interconnected scope of the enterprise technology landscape is too vast a body of work for one human to effectively manage. This drives the need to allocate the various domains to multiple architects to successfully manage the work. How this is done can vary greatly from one enterprise to the next. Devoting proper attention to this process will better enable the organization to counteract technological entropy. We will explore this process in greater detail in upcoming posts.
Back to INSIGHTS