Recently, there has been several blog posts discussing what should and should not be done when building an EA practice. I thought I would review how we built our EA practice in our higher education organization and compare it to some of the other approaches. I have yet to see one definintive approach for all organizations. EA is a cultural thing and needs to be implemented in the context and culture of an enterprise.
We started thinking about Enterprise Architecture when the Institute developed a strategic initiative to leverage technology to transform, enhance and support teaching, learning, research and business at the British Columbia Institute of Technology. As we put together the business case for the initiative, the consultants helping us suggested we adopt an EA approach. Four staff members (including me) were selected to spend a week with John Zachman and Stan Locke taking Zachman’s EA Fundamentals course. Right away, I was hooked. When we returned, the Institute created an Enterprise Architect position to help plan and architect the strategic initiative. After a selection process, I was selected as our first Enterprise Architect.
Now comes the How … to build an EA practice with a team of 1 (me)! I put a project plan together to build the EA Office and presented it to the IT Services management team. In the plan, I called for building our EA using a virtual team (I specifically asked for individuals from the various technology and business analysis areas and asked for a set amount of time per month). I started by integrating EA into some key processes – Project Management and Change Management. By sitting as part of our Project Advisory and Change Advisory Boards, I was able to show the value of EA on a regular basis and I was able to start the capture of our current state. Our future state (at a high level) was already articulated in out strategic initiative plan. Here is a WBS from our plan in 2005:
From there, I recruited Technology Watchers (domain architects) to give our virtual EA team 1 day of effort per month. We started to build an Application Portfolio and Technology Matrixes that looked at our investments today and forward 3 years into the future. This required us to develop a Technology Lifecycle framework and a main guiding principle (Reuse-Acquire-Create Reusable).
In the past couple of weeks, there has been discussions on Twitter as well as excellent blog posts on the do’s and don’ts of building an Enterprise Architecture Practice. Here are links to two posts that I found interesting – particularly because they are so different:
- John Polgreen (@JohnPolgreen) – http://gtra.org/blogs/john-polgreen/setting-ea-practice-health-care-case-study
- Jon Ayre (@EnterprisingA) – http://theenterprisingarchitect.blogspot.com/2009/11/ea-quick-start-guide-part-1-how-to-set.html
John and Jon have approaches that are almost opposite to each other. The table below shows the order of the steps (1, 2, 3 … n) for each author and our approach (note: I am only going by the two blogs – I am sure John and Jon will correct any of my mistakes!)
|Action||John Polgreen||Jon Ayre||Leo de Sousa|
|Create Guiding Principles||1||5|
|Pick an EA Framework||3||6|
|Engage with Projects||4||1|
|Build a Team||1||3|
|Establish Work Practice||4||2||2|
|Build your Architecture||3||4|
What was your approach? Is there something consistent that we can turn into a standard practice for EA?