If there is one thing that I have seen people arguing about is what’s an Enterprise Architect? Many of my peer will mention one role or another for EA, some will say it is evolution to the a solution architect. And other will say you try to grab most information about your enterprise IT and ensure the consistency and efficiently of the available resources. Now this is among my peers, but when searching for the concept you will find it was first mentioned by John Zachman when working for IBM during the 80s and was largely focused on the what he called “Information Systems Architecture”.
And to be frank I still couldn’t fully distinguish the role of an EA for the enterprise, even with TOGAF the concept is still abstract for me. Yes it is true that TOGAF is the industry standard and as they always state you can tailor it toward your needs, but it didn’t help me that I felt it was focusing too much on the IT as a building ground for the enterprise architecture. Just look at the ADM and how much of its work is focused on the information system and the technology architecture. Heck, they even treat the business in the business architecture as a service provided by the IT.
While just browsing through the topic I found an interesting ebook by Tom Graves. Now Tom has many many years of experience, in the field since the 70’s, and his prospective around the Enterprise Architecture is rather fresh breath on EA in general. He is meshing up the strategy and the available EA tools to construct a better practice to actually architect an enterprise!
So lets define EA in TOGAF terms:
“By being inclusive with all other management frameworks, EA is a discipline that helps the Enterprise define , develop and exploit the boundaryless information flow (BIF*) capabilities in order to achieve the Enterprise’s Strategic Intent.”
Here the focus for the TOGAF is exploit and make use of the BIF which is relatively in accordance with Zachman’s notion of EA; it is all about the information. In the other side Graves’s definition about EA goes around one idea:
“Things work better when they work together, with clarity, with elegance, on purpose.”
Specifically the roles of an architecture within the EA are:
- it’s a body of knowledge about structure and purpose.
- it’s used in decision-making throughout the enterprise.
- it’s used to guide designs, of any type, that would contribute in practical and effective ways towards the aims of the organization and enterprise.
The definition and the roles or an architecture evolve around a mashup between the enterprise strategy and EA tools to tight things better together. Indeed this is how author see himself, or as he explain himself “My professional field is mainly in what’s known as ‘enterprise architecture’, but with an emphasis on strategy and futures, on complexity and sense-making, on relationships between organization, extended-enterprise and market, and on integrating IT with the rest of the business”.
Now what fascinates me in this book aside from the fresh breath into the domain is the toolset that author has developed during all of his professional years. These tools are merely an extensions to some already well defined and established frameworks. So, Zachman’s framework has been extended to what he defines as extended-Zachman framework where the rows and columns have been redefined and another layer, or dimension, was added to relate the intersections of the rows and columns to the enterprise, like the mapping is related to something physical or virtual within the enterprise.
Another tool that author has explained in his post is the context-space mapping which is directly derived from the Cynefin framework. If there is one thing you will surely understand by reading this book is how useful this tool for developing sense-making skills, detecting the problems, and even decision-making skills, finding the appropriate solution, through an extensive examples and justifications to use this tool.
In addition you got the five key principles from systems-theory and the five-elements of concurrent-lifecycle business processes added into this toolset.
But is that all you need for practicing EA? As the author mentions this toolset is primarily concerned with practicing an agile-style EA that practice the system theory supplemented with the well defined artifacts provided by your favorite EA framework, weather TOGAF, FEA, or even Zachman. The author goes into demonstrating the theory and practice by getting involved in a ten day EA project for a failing bank and how we can start EA before wasting so much time in “tailoring” your favorite EA framework and concluding by presenting the findings and artifacts to the bank.
So from my limited experience this book will guide you through interesting and confusing concepts that elevate your thinking of how the enterprise actually work. Or as it is mentioned earlier “Things work better when they work together, with clarity, with elegance, on purpose”. And much like TOGAF you won’t be an architect by reading this book, or practicing the architecture in one or two years. And ad Graves stated, the architects start to master their domain once their head is prevailed by gray or hair or no hair is left there.
All credits to Everyday Enterprise Architecture book.