I had a conversation earlier this month with a colleague, Marc. He is active in the Enterprise Architecture forums on LinkedIn. Marc asked me to review some material he had developed for a book he is writing. We had been corresponding for a while but we decided to conduct a call for a more free form discussion.
Marc’s work will fill a large void in the book of knowledge for EA. He is working towards definitions of Enterprise and for Enterprise Architecture. I applaud him for his efforts and respect him for the amount of grief he takes on trying to vet his ideas in a forum with worldwide reach. There are many people in the EA world who are too deep into the weeds to have a strategic view of the Enterprise, what it does, and how it should do it. Marc’s book will hopefully re-calibrate those discussions.
One thing became evident in our discussion. Marc and I have different views as to what architecture means. We both use the ideas of structure, architecture, and documentation when we discuss the domain of the Enterprise Architect. I use structure and architecture synonymously to describe the state of the enterprise. I believe the failings of EA to gain traction in many organizations is that the architects are always trying to define the end state while ignoring the current state. You will find more about my thoughts here. The bottom line is I think you need to completely understand your current state before you can move the enterprise to a new place. You gain that understanding from documentation.
Marc understands structure and architecture to be different concepts. Structure is the state. Architecture is the documentation. You can read his work on LinkedIn to get into his development of these ideas.
I don’t think either of us is wrong. I know that our approaches are different. As the buyer of EA services, it is incumbent on you to understand what the practitioner is selling and how he will deliver his work products.