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

This morning Jon Ayre (@EnterprisingA) tweeted:

#EAMantra (11) Failing to deliver perfection is not a crime. Failing to deliver is.

Something I totally agree with, especially if you have been following my blog and the theme of building an EA practice that delivers value using a virtual team.

Tyler Gooch (@tylergooch) then sent a response (Thank you Tyler!!) about The Cult of the Done by Bre Pettis and Kio Stark.  This is very cool stuff!  Here are the 13 statements:

The Cult of Done Manifesto

1. There are three states of being. Not knowing, action and completion.
2. Accept that everything is a draft. It helps to get it done.
3. There is no editing stage.
4. Pretending you know what you’re doing is almost the same as knowing what you are doing, so just accept that you know what you’re doing even if you don’t and do it.
5. Banish procrastination. If you wait more than a week to get an idea done, abandon it.
6. The point of being done is not to finish but to get other things done.
7. Once you’re done you can throw it away.
8. Laugh at perfection. It’s boring and keeps you from being done.
9. People without dirty hands are wrong. Doing something makes you right.
10. Failure counts as done. So do mistakes.
11. Destruction is a variant of done.
12. If you have an idea and publish it on the internet, that counts as a ghost of done.
13. Done is the engine of more.

Brilliant stuff! I will be sharing this with my applications team tomorrow.

In my previous post, I suggested that integrating Kevin Kelly’s 8 “generatives” will help EA adoption (please read Kevin’s excellent article Better than Free for the details on each):

• Immediacy
• Personalization
• Interpretation
• Authenticity
• Accessibility
• Embodiment
• Patronage
• Findability

This really got me thinking about how we approach introducing and maturing enterprise architecture in our organizations. How many of you made attempts to introduce EA practices and struggled in your organizations?  What  attracts clients to your EA service? Do you use a carrot or a stick? Why would people in your organization come to you for services? What makes your service better than free?

Can we take Kevin’s “generatives” and apply them as principles of our EA practice? This post describes how we can apply Kevin’s “generatives” as influencing guiding principles for delivering Enterprise Architecture.

Immediacy – Does your EA practice provide immediacy to facilitate solution delivery in your organization? Can your EA serve to deliver solutions quicker and in a supported, sustainable manner?  If your EA process takes weeks or months or even years, there is no immediacy for your clients and they will go elsewhere even if it costs them more. If we design our EA services to address the immediacy demand of our clients, we can deliver the immediacy generative. Applying our EA Guiding Principle “Reuse-Acquire-Create” will help.

Personalization – Does your EA practice address the requirements of your client’s specific needs? Communication is a key role for an Enterprise Architect. Building relationships and creating value for your clients by understanding their needs and enabling solutions tailored to their business challenges. This creates “stickiness” between the business and your EA practice. Both parties collaboratively build a relationship which is a generative asset that they are invested in. To me this is a great way of thinking about technology services becoming a trusted partner to the business and delivering the personalization generative.

Interpretation- Can your EA practice be the interpreter and bridge between easily accessible technology solutions and real business requirements?  How many times do business units in your organization buy a technology to address their current pain point ,only to find that the technology is cheap to acquire but costly to implement and difficult to  integrate? If we as EA’s, can help our business partners make better choices by guiding them with standard solution architectures that integrate into our overall enterprise architecture, we meet the interpretation generative.  Read more...