Enterprise Architecture in Higher Education

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.  Read more...

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  Read more...

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.

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.  Read more...

JP Rangaswami wrote an interesting post titled Mother of Invention. In it he discusses, Frank Zappa and piracy and as usual, he expands my understanding on this contentious topic. Thank you JP!

What really caught my eye was JP’s reference to Kevin Kelly’s article Better than Free. Kevin talks about the Internet being a super-distribution system where once a copy is introduced it flows freely forever.  So when everything is free or as close to free as possible, how do we make money? Kevin’s solution is pretty simple …

“When copies are super abundant, they become worthless.
When copies are super abundant, stuff which can’t be copied becomes scarce and valuable.

When copies are free, you need to sell things which can not be copied.”

Next Kevin talks about “generatives”.  Here is his definition:

“A generative value is a quality or attribute that must be generated, grown, cultivated, nurtured. A generative thing can not be copied, cloned, faked, replicated, counterfeited, or reproduced. It is generated uniquely, in place, over time.”

Kevin proposes 8 “generatives” listed below (please read Kevin’s article for the details on each):  Read more...

• Immediacy
• Personalization
• Interpretation
• Authenticity
• Accessibility

Alan Inglis posted about What good looks like from a solutions architecture perspective.  How do you create a solution for a new project without creating architecture that already exists or making the same mistakes that previous projects made? This is a must read post and I recommend it.

Alan described 10 artefacts that he would expect a solutions architect to leave behind from a project implementation. They are:

1. Project Background
2. Terminology
3. Key Drivers, Principles, Standards and Constraints
4. Business Problem
5. Information View
6. Risk View
7. Application View
8. Data View
9. Integration View
10. Infrastructure View

I have some questions for Alan on this:

• How big a project would require this level of artefact creation? For small and possibly medium projects, the work to do the architecture may be more than delivering the project.
• Is there a subset of these artefacts that would be sufficient for small and medium projects?
• How would the next solutions architect find and assess the artefacts created?  Need a searchable, secured repository – wiki?, blog?, SharePoint?, network file share?, knowledge base?

We, Enterprise Architects, regular trumpet the value of having an archictecture and learning from it.  Some of the key factors for me would be:  Read more...

First, thanks to everyone who contributed via the Shared Insights EANetwork. I originally posted this on September 16, 2007. I got swamped and did not post my list so here it is:

Trends and Impacts  Read more...

1. Trend – More stakeholders are connecting EA thinking (alignment of technology to support strategic goals) with business innovation and investments in change.
   Impact – EA will become embedded into the planning, procurement, implementation and delivery of services.
2. Trend – Enterprise Architects more rare that IT architects. Growing your own EA might prove to be more successful than recruiting one
   Impact – Coaching, mentoring and training of internal staff to become IT strategic thinkers will help grow Enterprise Architects. Is there a path? Project Technical Lead to IT Domain Architect to IT Solutions Architect to Enterprise Architect to Chief Architect?
3. Trend – More acquisition of COTS (Commercial Off the Shelf) technologies that are build for configuration and integration instead of requiring customization
   Impact – Configurable technology allows more time for upfront Business Analysis to gather the right requirements and simpler, more manageable ongoing support and maintenance.

JP Rangaswami posted an interesting entry on Build versus Buy versus Opensource.  In it he states:

“And the way I think of it is this:

For common problems use Opensource.
For rare problems use Buy.
For unique problems use Build. ”

Not bad but I really think he missed a fundamental part of this discussion.  Reuse should always come first. Look at what you have in people and their skills  and technology already deployed that could deliver the solution.  I think my post on EA Guiding Principles  better addresses the need for reuse.

Thoughts?