How deep do you go?

by | April 7, 2009

Nick Malik just posted about All the questions fit to answer

“Make sure you write down the questions that the business wants the Enterprise Architecture team to answer.  Then collect only the information that you need to collect in order to answer them.”

… and it triggered something that I have been thinking about for a long time.

How deep do you go in capturing your Enterprise Architecture? At what depth of detail (or abstraction), do you go to ensure that you have enough to support Strategic Planning (like Nick talks about) and IT Governance? At what point have you gone too deep, making your EA practice into a resource sucking documentation exercise?

During our lunch last week, Nick talked about Business Capabilities as an abstraction layer. I am sure Nick is going to blog about this in the future. We are putting together a Institutional new strategic plan in the next few months and I plan on writing down those business questions.  We should then be able to look at our EA artifacts like our Application Portfolio and see the gaps.  More importantly, we should be able to determine data we are capturing that do not provide value or help in answering the questions.

I have been working on a strategic planning exercise with our Human Resources department.  I am taking an approach that my friend David Bedwell developed at Charles Sturt University in Australia to build out their Enterprise Architecture. I started with a discussion about the basics of EA – think Zachman interrogatives:

  • What = Data
  • How = Process
  • Where = Systems
  • Who = People
  • When = Events
  • Why = Strategy

 Thinking about these primatives Process is change resistant.  For example, if the HR department replaced employee recruitment services with facilities management services, would this group still be an HR organization?

Here is the diagram showed our HR folks to introduce the concept that process is the centre:


By using Process as our base foundation, we can layer onto it Strategy, People, Events, Data and Systems.  I tried this with Systems as a test with the HR team and it was very apparent that our current Application Portfolio does not support all the key processes delivered by HR. By showing this on a diagram, we can articulate “roadmap” projects to close the gap in function/capability in our systems.  I will write more about this process as we work our way through it. 

I will also work on articulating “how deep do you go.” I am very interested if you have a set of standard questions you get from your business folks and hope you will share them.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.