Enterprise Architecture in Higher Education

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:  Read more...

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.

Mike Kavis‘ got me thinking about EA frameworks with his Twitter posts about the E2AF.

The Zachman Framework was my first introduction to an EA framework in 2004 and it continues to be a significant reference model for how I think about EA. Here is a slide of the Zachman Framework Version 2.  The geometry of Zachman sits in one and two dimensions. For example, creating lists for cells in ZF Row 1 results in one dimensional, primitives. Next, creating matrices between the Row 1 lists results in two dimensional, composites. There is no third dimension to overlay or underpin the artifacts in this model. So how are governance, security and risk management articulated?

Mike is looking at leveraging the Extended Enterprise Architecture Framework.  Here is a slide with their model – Extended Enterprise Architecture Framework (E2AF).  This framework slightly modified Zachman components like the column interrogatives to: Why? With Who? What? How? With What? When?  (Note: John Zachman has always maintained that there is no precident order to the columns in his framework). The rows have been simplified from 6 to 4 : Business, Information, Information – Systems, Technology – Infrastructure. This results in the same geometry as the Zachman Framework but the E2AF model goes a further step and introduces “Viewpoints” : Privacy, Governance, Security and Other Viewpoints are identified. These viewpoints introduce a critical third dimension and allow the framework to be view from specific stakeholder’s perspectives. Here is a link to the article that explains viewpoints in this framework.  Read more...

Two years ago, Dave Cresswell and I came up with a graphic to represent Enterprise Architecture @ BCIT. We needed a simple graphic to communicate EA and also knew that showing our senior Executive the Zachman Framework was too complex. Here is first draft EA model:

and Version 1 :

At that point, I was just getting introduced to the Information Technology Infrastructure Library (ITIL) and did not have a clear sense of how it fit within the bigger realm of Enterprise Architecture. We were also just beginning our work on developing IT Governance (ITG) and again I did not have a clear sense of how it fit with EA.

Here is Version 2:

I want to share with you my new thinking on how to represent the relationship between EA, ITG and ITIL. The new EA Taxonomy graphic now shows that BCIT will use ITIL Service Delivery and Service Support as a backplane to guide our IT Service Management work. ITG fits in the first backplane with Strategy and Policy and ensures alignment to BCIT’s strategy and vision.

Looking forward to your thoughts on this.