I just saw a post by Adrian Grigoriu responding to Gartner’s Philip Allega’s post Applying EA to Your Life .  Within the post about how EA might be able to help plan our lives, Philip then brings up an regular EA debate “Do you start with the Current State?”  Actually, Philip says don’t do it.

If you have started your EA program and your first activity is to document the current state, STOP NOW. Refocus your team on analysis of the business strategy and development of the future state architecture.

Current-state analysis done first limits your ability to see future possibilities.  Developing future state first will constrain the level of detail required for current state.

I have a problem with Philip’s directive on stopping work on EA Current State. When introducing EA approaches to an organization, especially if you are doing this as an internal initiative, you MUST demonstrate a clear understanding of the issues and challenges to your senior sponsors.  No one will invite you to make comment or participate in strategic planning activities if your own house is not in order (or at least you have a plan in place). As you will see later in the post, creating our current state was essential to build our future state.

Adrian’s response is much more in line of how we delivered out our EA practice.  In particular, Adrian’s point about establishing a future state is exactly right.  You must understand the economics and practicalities of building the future and this is done by understanding the current state.

I hope this piece of advice was not meant to be taken literally. Imagine going to your CIO or senior manager telling him  that you have to stop the current state documentation work, now.

The target architecture cannot be established based on Vision alone. It is not practical or economically viable to start from tabula rasa each and every time you implement a new strategy. Competitors would be delighted though.

In 2007, we took our EA discipline and practices and used them as a basis for building a Technology Plan for our organization.  Here was the approach we took in order to get buy-in from our senior executive.  We had made attempts at strategic technology plans in the past but nothing of this magnitude or disciplined approach.  We call this diagram our “plan on a page”:  Read more...

An Efficient Means for IT Planning – Aims College

Andria Brabo – andria.brabo@aims.edu, Dr Gary Bardsley gary.bardsley@aims.edu

• used project portfolio planning process – using Word Docs and a Wiki to coordinate projects across a small IT shop of 26 people.

Challenges

• lack of communication
• staff turnover
• project managers making promises without checking with implementers
• cross platform – Mac vs PC

Approach

• create a PPP document that articulates the dependencies and deliverables required from each area to make the project a success
• looks to me like a blend of project plan and project charter
• the PPP held the teams accountable
• if the project requires more than one dept then you need to create a PPP

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:

Building an EA Practice

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).