Category Archives: it governance

Do you need to create an As-Is State?

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”:

EA Archivist or Activist? Delivering Value is the Key

Todd Biske posted a summary of a conversation he had with Mike RollingsBrenda Michelson, Chris Bird and others. They were discussing the future of Enterprise Architecture. A theme that emerged from their talks focused on whether your practice is defined by being an archivist (passive) or an activist (active).  Here is the conversation (from Todd’s post) that got the ball rolling:

Near the end of the conversation, Chris asked the question, “Are Enterprise Architects really Enterprise Archivists?” Brenda responded that we really need Enterprise Activists focused on action, delivery, ideation, and evangelism.

Building credibility in your organization by delivering on value will get you to the place where you can be the “enterprise activist”.   Those of us who had very limited budgets and very small teams are well aware that showing value by making a positive contribution to our organizations is the way to earn the right to be “activists”.

Again from Todd’s post, here are Brenda Michelson’s four attributes for an “enterprise activist”:

  • Action: The action is engagement. Talk to the people that have the ability to make change happen. Using the activism analogy, the EA is the lobbyist. Engage the stakeholders, and make your case.
  • Delivery: Deliver the strategic architecture, and then work with the project teams to make sure the architecture is realized properly. If you’re only cataloging what other people have done, you’re an archivist.
  • Ideation: Think about the future. James McGovern (@mcgoverntheory), a fellow EA, had posted once that EA’s need to have time to think. This is where the ideas come from, and then can get turned into the strategic architecture. They’re not the exclusive source of ideas, but EA’s are supposed to be your senior level thinkers, so innovative ideas should be expected of them.
  • Evangelism: How can you be an activist without being active? Make the cause known. If the cause isn’t heard, work to understand why, and tweak the message accordingly.

I like the broader range of attributes that Brenda presents as they provide guidance for any size, shape or structure of enterprise architecture practices in any organization.  I don’t think I am overstating things by saying these are “timeless” attributes.

I wrote a post in July 2007 titled, Enterprise Architecture Roles or ‘What do you do??.  In the post, I talked about the roles that we fulfill in our EA practice at BCIT.

SGHE Summit – An Efficient Means for IT Planning

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