One idea is that the intrinsic essence of an enterprise architect is to think about abstraction. (By the way, abstraction seems to be a category that can only be defined polythetically; it appears to have many characteristic features, but we seem to be unable to work out any defining features.)
Suppose that the use of an enterprise architect (if any) is to solve practical business problems. For this purpose, enterprise architects are interchangeable with systems thinkers, just as Jaffa Cakes are interchangeable with Fig Rolls. For a large tea party or enterprise transformation programme, we might have a plate containing Jaffa Cakes and Fig Rolls and various other cakes and biscuits.
But presumably that's not the only thing that an enterprise architect is good for.
So one theory-practice question is this. What are the essential things that an enterprise architect brings to solving practical problems? If it is abstraction, what special powers (if any) does this give to the practising enterprise architect? And what are the essential things that a systems thinker brings to solving practical problems?
Abstraction is associated with a number of myths and pitfalls
- The myth that radical structural and behavioural change can and should be driven by a few simple and powerful ideas. On the misuse of general principles (Jan 2012)
- Valuing abstraction and adaptability above everything else. Avoiding thinking about mundane technology when building pure business models. IT Innovation at Small Bakery (April 2009)
- The relationship between the general and the specific is poorly supported by the prevailing tools and methods, which often reduce the question to simplistic abstraction hierarchies. TOGAF 9 - Enterprise Continuum (Feb 2009). Instead of generalizing everything as much as possible, architects need to reason explicitly about system structure and dynamics - cohesion and coupling, composition and decomposition, change and emergence. They need to understand granularity and stratification as active choices, rather than text-book patterns. Architecture and Abstraction (May 2004)
- Mainstream EA frameworks typically appear as premature codifications of ungrounded abstractions. The attempted diffusion of these codified abstractions is then ineffectual, because these ungrounded categories lack any relevance to real business challenges. ... So instead of discussing concrete business problems, we find ourselves discussing generic categories of business problem. Towards Next Practice EA (May 2013)
See also
- Special Powers of the Architect - Getting The Big Picture (Dec 2010)
- Special Powers of the Architect - Judgment (January 2012)
Updated 26 October 2016
No comments:
Post a Comment