My friend Nick Malik wrote a post - Zachman’s Fatal Flaw: No Row for Customer.  Here is my response …

Do I believe that Zachman’s Framework is fatally flawed?  No. It all depends on your perspective and that to me is defined by your EA maturity.  How we view and evaluate models and frameworks depends on how much time we have spent working on Enterprise Architecture.

Here is a simplistic example of what I mean. Think of our understanding of astronomy that we have at various stages of our education.  As an elementary school student, we learned about the solar system and the main celestial bodies.  As we progressed to secondary school, we learned about gravity and its influence on the solar system.  At a university level, even more depth and understanding of the physics adds to our understanding (and perspective) of the universe.  Would a graduate student use the grade school model to understand the solar system? No, but does that invalidate the elementary model used to introduce astronomy to grade schoolers? No it does not.

What Nick observes is that our view of  the Zachman Framework has changed, due to the growth in our EA maturity.  Most organizations that embarked on establishing Enterprise Architecture practices focused internally first.  We did this to understand what we had and what it cost to deliver the technology services required by our companies.  EA also started primarily in the IT departments and slowly began to grow outwards to assist in business and strategic planning. If we start with an internal view focused on IT what would you expect? An internal focus – think of it as getting our house in order.  This is a very “Inside-Out” perspective and the Zachman Framework served may organizations well over the past decade. That is why so much EA writing uses the “IT” and its relationship to “the Business”  model. Here is Nick’s quote about the flaw:

What is the fatal flaw?  As you can tell from the title of the post, the flaw is an “Inside-Out” perspective on the enterprise.

We are maturing our EA profession from being focused on our internal processes and complexity and moving to a customer centric focus. Now that we have a better handle on our internal house using an EA approach, the next logical place for EA to focus and show value is in strategic planning.  Nick’s quote about the customer is particularly important here:  Read more...

Alan Inglis posted about What good looks like from a solutions architecture perspective.  How do you create a solution for a new project without creating architecture that already exists or making the same mistakes that previous projects made? This is a must read post and I recommend it.

Alan described 10 artefacts that he would expect a solutions architect to leave behind from a project implementation. They are:

1. Project Background
2. Terminology
3. Key Drivers, Principles, Standards and Constraints
4. Business Problem
5. Information View
6. Risk View
7. Application View
8. Data View
9. Integration View
10. Infrastructure View

I have some questions for Alan on this:

• How big a project would require this level of artefact creation? For small and possibly medium projects, the work to do the architecture may be more than delivering the project.
• Is there a subset of these artefacts that would be sufficient for small and medium projects?
• How would the next solutions architect find and assess the artefacts created?  Need a searchable, secured repository – wiki?, blog?, SharePoint?, network file share?, knowledge base?

We, Enterprise Architects, regular trumpet the value of having an archictecture and learning from it.  Some of the key factors for me would be:

• ensuring that there is time for solution architects and enterprise architects to work together to do peer reviews: 1) pre-project, 2) technical reviews in a project and 3) post-project
• communication of agreed upon standards and principles is essential to build a common language
• negotiating with functional managers to ensure time is allocated to every project for architecture
• regularly demonstrating value to the organization by taking an enterprise, long term view

My EA colleague Mike Kavis posted a “Free E2AF Cheat Sheet” for all of us to leverage. Thanks Mike!

For those of you who don’t know Mike has been leveraging the E2AF to build out the enterprise architecture of his startup company.  Following Mike in his journey using a  ”learning lab” for EA has been insightful and a great educational experience for me.  For me, the huge value of this post and the template is that Mike’s document is field tested as part of his company’s EA development.

I am looking forward into digging into Mike’s document, seeing what we can apply in our EA practice and will definitely share back any observations and modifications that I come up with.