Enterprise Architecture in Higher Education

Andy Blumenthal wrote a great post “Adaptive Leaders Rule the Day“. In his post, Andy reviewed a Harvard Business Review July 2009 article “Leadership in a (Permanent) Crisis” and commented on the article’s insights on adaptive leadership.

I really liked Andy’s quote “Leaders need a proverbial “toolkit” of successful behaviors to succeed and even more so be able to adapt and create innovative new tools to meet new unchartered situations.”

Andy listed some of the successful behaviours in the “toolkit”.  I recommend you read the full article to get all of Andy’s insights. 

Here is the list of successful behaviours:

• “Foster adaptation”
• Stabilize, then solve
• Experiment
• “Embrace disequilibrium”
• Make people safe to question
• Leverage diversity

Taking a similar approach to my previous post on Generative EA Principles, I will explore and share how Andy’s list of behaviours fit with our EA practice (and maybe yours).  We have a long way to go to fully leverage the successful behaviours but having some clear names for what we have accomplished helps.  Thanks Andy!  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:  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...

Tomorrow, I will be asking my peers in the Internet2 ITANA – IT Architects in Academia to do a peer review of a Technology Lifecycle taxonomy that we use at BCIT. As we developed our Enterprise Architecture, we needed a way to communicate not only the lifecycle of initiatives and technology but also their viability.

Here is what we use:

Here are the definitions that we use:

Watching:
- includes initiatives and technologies that are being watched for maturity in industry

Researching:
- includes initiatives and technologies that are currently under consideration, investigation or evaluation for future implementation

Investing:
- includes initiatives and technologies that are the target of resources including financial investments and/or investments in human resources

Sustaining:
- includes initiatives and technologies that deliver services identified in the Core Services Catalogue or in Service Level Agreements

Containing:
- includes initiatives that have been completed and technologies that are in the process of being phased out

End of Life:
- includes initiatives and technologies that are being retired from service

While this is a life cycle, it is not mandatory that an initiative of technology follows through every step.  Read more...

First, thanks to everyone who contributed via the Shared Insights EANetwork. I originally posted this on September 16, 2007. I got swamped and did not post my list so here it is:

Trends and Impacts  Read more...

1. Trend – More stakeholders are connecting EA thinking (alignment of technology to support strategic goals) with business innovation and investments in change.
   Impact – EA will become embedded into the planning, procurement, implementation and delivery of services.
2. Trend – Enterprise Architects more rare that IT architects. Growing your own EA might prove to be more successful than recruiting one
   Impact – Coaching, mentoring and training of internal staff to become IT strategic thinkers will help grow Enterprise Architects. Is there a path? Project Technical Lead to IT Domain Architect to IT Solutions Architect to Enterprise Architect to Chief Architect?
3. Trend – More acquisition of COTS (Commercial Off the Shelf) technologies that are build for configuration and integration instead of requiring customization
   Impact – Configurable technology allows more time for upfront Business Analysis to gather the right requirements and simpler, more manageable ongoing support and maintenance.

I have the honour to speak to the International Institute of Business Analysis (Vancouver, BC, Canada Chapter) tomorrow at a Lunch and Learn session.

I will be speaking about how we built a Strategic Practice group that uses EA as the framework to guide other practices like Security, Program Management and of course Business Analysis.  I will use the EA Model, I talked about in an older post to position how EA and BA fit for our organization.

Since we are still early in our development of these horizontal methodologies, I will be talking about how BAs’ requirements gathering become the source for our solutions architecture work. Over time, I hope we can grow our Business Analysis practice into a Business Architecture practice.

So if you had a chance to talk to a captive audience of BA’s, what would you say?

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.

Here is the taxonomy I use for categorizing the EA artifacts we create. Comments?

Enterprise Architecture Taxonomy (Element-Domain-Component-Artifact)

Architecture Element
The high level architectural description for Applications, Business, Business Continuity, Data, Infrastructure, Presentation and Security containing Architecture Domains. (i.e. An element contains domains)

Architecture Domain
The summary level of architecture describing the models used for each Architecture Element. (i.e. A domain contains components)

Architecture Component
The detailed level of architecture describing the components of an Architecture Domain. (i.e. A component is represented by one or more artifacts)

Architecture Artifact
The populated models representing the current and target architecture for Architecture Components.