Last week, John Gotze (@gotze) sent me a call to action by tweeting:

Finnish universities adopt #entarch, and look for international inspiration and collaboration. Who’s doing EA for universities? @leodesousa?
My first reply to John was the Twitter handles of practicing Enterprise Architects in higher education as well as the Educause group ITANA.  Educause also has a reference section for Enterprise Architecture. http://www.educause.edu/Resources/Browse/EnterpriseArchitecture/17214

@gotze there is an @educause group called #itana chaired by @jimphelps. Some others @pauldhobson @EAinHE @ricphillips many others and me @leodesousa

This got me thinking that a quick post with some links to enterprise architecture resources in higher education might be worthwhile.  So here goes in no particular order:
In Australia and New Zealand, The Council of Australian University Directors of IT sponsored the annual Enterprise Architecture Symposium.  I had the privilege to be one of the guest keynote speakers at the inaugural conference organized by my friend and colleague David Bedwell at Charles Sturt University in November 2006. David’s leadership and vision has resulted in the conference becoming a “must attend” annual event.  I presented at the second and third conferences via Skype video conference and was curious where the group has gone since I last participated.

Summary of CAUDIT EA Symposium Links – with presentations resources

In the US,  Marina Arseniev from the University of California, Irvine has a very mature EA practice and her work definitely should be considered.  https://apps.adcom.uci.edu/EnterpriseArch/index.html.  Brian Cameron, at Penn State has founded and leads the Center for Enterprise Architecture.  MIT has an outstanding site that also proved very valuable to helping me along in developing our EA practice http://web.mit.edu/itag/eag/.

In the UK, JISC (Joint Information Systems Committee) has conducted pilot projects and published papers that are very worthwhile reading and provide insights on ways to adopt EA into higher education.

From Canada, there is my blog Enterprise Architecture in Higher Education that I have been writing since 2007.

I am sure I missed many excellent sources of EA practices in our higher education and apologize in advance to my colleagues.  Hopefully, this gives you a good start.

 

I wrote a post titled How Would You Reorganize an Application Service Delivery Model? in March 2010 and thought it was time to update you on the changes we made to our Application team.

At that time, my team was structured by role:  DBAs, Developers, Application Administrators, Email Administrators, etc.  Over that time, we had some successes with the structure and some challenges.

Some challenges with the role based structure included:

  • separation of developers and DBAs – resulted in delays, rework when developers did not meet coding standards expected by DBAs, and disconnected teams
  • separation of services that had tight integration like our portal environment from the ERP platform
  • mixture of platform skills that caused service support issues when service recovery work crossed team boundaries
  • challenges in providing minimum staffing coverage and training when support spanned team boundaries such as Identity Management, Project Management and Business Analysis work

In September 2010, we had an opportunity to reorganize our team.  After consulting with our team members and team leaders, we changed the structure to suit the two main architectures that our team supports – Microsoft and Oracle.  Essentially, we moved the developers to the platforms they predominately worked in and realigned the services that required tight integration.

Comparison of Role Based Structure to Platform Based Structure for Application Services

Role Based Structure Platform Based Structure
Support Team Oracle DBA Oracle Team Oracle DBA
Document Management Business Intelligence
Business Intelligence Document Management
Project Management Enterprise Portal
Business Analysis ERP Administration
Identity Management Java/Web Services Developers
Oracle Developers
Email and Collaboration Team Email Administration Identity Management
Calendaring Business Analysis
Instant Messaging Project Management
Collaboration Platforms Microsoft Team
SQL Server DBA Email Administration
Microsoft Applications Calendaring
Enterprise Portal Instant Messaging
Collaboration Platforms
Developer Team Java/Web Services Developers SQL Server DBA
Microsoft Developers Lotus Domino Developers
Oracle Developers Microsoft Applications
Microsoft Developers
Identity Management
Business Analysis
Project Management

We have been running with the structure for almost a year now and are seeing the benefits of aligning our Application Services team with our main support platforms.  I will revisit this structure annually to ensure that our team is organized to best serve our client community.

 

Nick Malik wrote a great post titled The Rule of EA Governance that hits to the core of EA and IT governance. It is a must read and I highly recommend it. Nick asserts that:

All Enterprise Architecture will be implemented according to the structure of ownership and governance that exists in the enterprise.

Next Nick explains why this is important by using an example of a CRM implementation in an organization.  He specifically states that:

If you have two business customers who both want a CRM solution, and you have one governance body, you will end up with one CRM system.  If you have two governance bodies, you will end up with two CRM systems.  If you have four business units who want CRM, and you have three governance bodies, you will end up with three CRM systems.

This rule plays out repeatedly.  I’ve never seen it fail.

The failure to recognize “The Rule of EA Governance” is one of the causes for the failure of an EA program.

I too have seen this throughout my career and my work with multiple organizations to introduce enterprise architecture practices.  We have seen many reports and stories about how EA programs have failed and I completely agree that a lack of ownership and governance contributed to the failure.

Now I want to suggest a practical approach to help your EA practice make “The Rule of EA Governance” tangible.   Build an application/service portfolio and ensure that you associate an Executive Sponsor and a Business Owner to each item in the portfolio.

Once you have done this, start showing it to people … it is amazing when people see their names or their departments associated to a particular thing how interested they get!  Nick had a good quote:

The business doesn’t care about nice drawings and great designs.  They care about “stuff they own” and “stuff they don’t own.”

If people never see what they own, how can we expect them to govern usage especially when it is a shared service?  Nick ended with an approach to help all of us move our Enterprise Architecture practices forward:

So if you want to know if your Enterprise Architecture can be implemented, count the “things” in it.  Then count the number of those things with exactly one owner (and clear governance).  Those are the things that will be implemented just the way you describe it.  Everything else is a free for all.

Simple and brilliant – thanks Nick!

© 2007-2012 Enterprise Architecture in Higher Education - Leo de Sousa Creative Commons License
Enterprise Architecture in Higher Education by Leo de Sousa is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 3.0 Unported License.
Based on a work at leodesousa.ca.
Suffusion theme by Sayontan Sinha

Switch to our mobile site