Building an EA Practice – what is your process?

by | November 26, 2009

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

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

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

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
Implement Governance 2 7
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?

10 thoughts on “Building an EA Practice – what is your process?

  1. Jon H Ayre (The Enterprising Architect)

    Interesting post Leo. I am particularly interested in your final summary table. It would appear that we have a reasonable level of agreement their, both our methods focusing on the same top four items. The 5, 6 & 7 in your model are mentioned in my blog, but for me the order is less important but I can see no real problem with the order you define.

    The key point is that the final four items in your table are for me (and for you) the most important to get right at the very beginning, and all relate to becoming useful to others and adding value as soon as possible. The remaining three items are the cherry on the cake, so to speak.

    I do think that engaging with projects right at the beginning before you have anything to offer is very dangerous, and although I can see your reasoning, I would see this as a compromise.

    So what order would I propose based on your summary?

    In an ideal but still pragmatic situation (which is what we are trying to get to) I would put Build a team and Establish work practice first (in either order or combined), then Build Architecture starting before (and then overlapping with) engaging with projects.

    I would then put EA framework next (as cherry pick and learn from EA Frameworks), followed by Implement Governance and Establish Guiding Principles as part of continuous improvement activities.

    The Enterprising Architect

  2. Martin Howitt

    Great post Leo. We’ve been going nearly 2 years now and we did it in this order:
    0. Build a team
    1. Pick a framework
    2. Implement (some) governance (board level)
    3. Create future state model (we had a strategic plan but it wasn’t detailed enough)
    4. create principles
    5. create some programmes
    6. Build a team
    7. refine communications plan
    8. establish work practice
    9. engage with projects

    It looks a bit random from above! I think that, if there had been just one person in the team, it might have looked better …but been less effective. Our team was picked to comprise people with a range of views, some strong, and we had to negotiate a lot of politics: but things are settling and our initial future state model is proving very strong.

  3. Martin Howitt

    @Jon H Ayre (The Enterprising Architect)
    I do think that engaging with projects right at the beginning before you have anything to offer is very dangerous, and although I can see your reasoning, I would see this as a compromise.

    If you have a future state then you can engage straight away surely? For us this is one of the most powerful ways to show added value.

    I’m not sure what we mean by “build architecture” in this context: do we mean the actual projects that deliver the future state or do we mean a model of the future state?

  4. John Polgreen

    When I add the steps I actually performed but didn’t include in my post (build a team, engage with projects), my list is almost exactly the same as yours. I understand Jon’s issues with defining principles, governance and frameworks up front. In an organization new to EA, resistance to spending time on these issues may make them candidates for downplaying to key stakeholders. In the case of the health care provider I wrote about, the EA practice was sponsored by the CEO, so we felt some confidence in proceeding with this work. It appears that actual ratification of these by stakeholders may take some time. It only took a week to establish principles, governance framework and EA framework (TOGAF has templates and examples for these – it speeds up work considerably. Even if the team keeps these in their back pockets through the first project, the work won’t be wasted.

  5. Malcolm Lowe

    Interesting discussion. From my perspective and experience a linear approach is always a little risky. Until you start engaging projects and showing value and making a difference it is all a little academic. There is a danger that you will never get to engaging projects and show the value you can deliver.

    There is also a danger of engaging projects when you don’t have any collateral for them to follow.

    I would counsel trying to do most of these in parallel with engaging with projects starting with explaining what you are trying to achieve, why and how and then at step 1.5 actually starting to use the EA in anger.

  6. Pingback: links for 2009-11-26 « On IT-business alignment and related things

  7. Tom Graves

    Catching up with this one a little late – apologies.

    The sequence I’ve used (see my book “Doing Enterprise Architecture”, ) is kind of a cross between Leo’s and John’s, mainly because in an agile-type context every one of those stages happens multiple times.

    My usual role is to set up the EA capability as an external consultant, building towards a full handover to an internal team (which in some cases may well be just one person, as in Leo’s story – but the important point is that to me it _must_ be an internal team, not an external ‘develop and walk away’).

    Typical steps include:
    – establish preliminary business-case and preliminary funding
    – establish relations with internal project teams and other key stakeholders
    – identify an appropriate _initial_ framework, methodology and governance (see e.g. extended-Zachman and simplified-TOGAF )
    – develop first-cut very-high-level architecture (preferably to-be rather than as-is, and usually a Functional Business Model – see – and key architecture-entities map as per framework) to get a preliminary picture of ‘enterprise on a page’
    – use the ‘enterprise on a page’ models as conversation-starters to identify key architectural concerns (could be anything, not just TOGAF-style IT)
    – use the results of those conversations to establish formal business-case and funding as an ongoing capability rather than a project
    – review / revise / reselect framework, methodology, governance etc
    – develop appropriate architectures and change-maps, as per identified architecture-priorities, engaging with respective individual projects (e.g. as per simplified-TOGAF methodology Phases A-D)
    – engage with project implementations (e.g. as per simplified-TOGAF methodology Phases E-H)
    – complete handover to internal team
    – extend and repeat indefinitely using internal team

    Although a ‘complete’ architecture of the enterprise will take years – or rather, is an ongoing process that should never actually end – this agile-type approach makes it possible to start delivering real business value within weeks or even days.

    One of the key success-criteria is establishing, and using right from the start, a framework that covers the full enterprise scope (rather than only small subsets of the enterprise, as per standard-Zachman or the TOGAF-9 repository). In this context ‘the enterprise’ is at least three steps larger than the organisation – i.e. includes partners, suppliers and service-providers (Step 1: interfaces and common standards, transaction-economy etc), clients and prospects (Step 2: attention-economy, relations-as-assets etc), and non-clients/’anti-clients’, government and the broader community (trust/reputation-economy, legislation/compliance, regulations and information-interfaces etc). The use of a whole-of-enterprise framework makes it possible for _every_ architecture activity to contribute to and draw from the dynamic ‘hologram’ of information about enterprise structure and purpose.

  8. Ray Bordogna

    Good discussion. Apologies for also arriving late to the party. Leo had some good comments a recent post of mine*, so I figured I’d check out what others had to say about EA approaches.


    After reading the comments, I agree with many of you. In particular, I’m also a fan of an “agile” approach to EA. However, I think our profession suffers from a bit of a marketing problem. We promote ‘architecture’ to the business but it’s been difficult for that community to grasp the benefits. And, it’s frustrating because is seems all too obvious to technology-savvy strategists.

    I’ve had some success with the concept of “enterprise optimization.” It goes a bit beyond traditional EA, integrating more recognizable business-oriented frameworks such as Norton’s Balanced Scorecard.

    Has anyone else tried promoting EA by removing the “architecture” label?

  9. Pingback: Adding Toyota’s A3 Report Process to your EA Toolkit | Leon Lewis JR

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.