Enterprise Architecture in Higher Education

This is my review of this morning’s Architecture & Governance magazine webinar ”The State of EA: Is 2010 the Transformational Year?”

Presenters:

• George Paras, Editor-in-Chief, A&G, Managing Director, EAdirections – gparas@EAdirections.com
• Alex Cullen, Vice President, Research Director, Enterprise Architecture, Forrester Research – acullen@forrester.com

1. What is the current state of EA? Forrester conducted a survey of 416 IT professionals and found the following:  Read more...

• Increasing awareness and acceptance of EA – this is change in that there is much more broad support for EA as a discipline in organizations
• EA teams are part of senior IT management – more focus at a senior level instead of a tactical level in IT (* true in my case moving from a staff EA position to a management EA position)
• Primary drivers for EA programs 1) better strategic planning 2) consolidation of technology 3) improve business agility4) enable business-IT alignment
• Infrastructure, Security and Application architectures are the most complete, next Integration and Information architecture are underway and business architecture is the least complete
• Where to architecture groups spend their time 1/2 time spent on non-project activities – supporting enterprise planning, strategic planning, collaborating with business and governance

Last week, I presented the accomplishments of my applications team in 2009. I was blown away by the number and the scope of the projects my team delivered to our community. I firmly believe that the separation of our operational duties from our project work enabled us to be so productive. While most people would celebrate the project teams |(and we do!), I want to acknowledge the key enabler of this success – our Duty Analyst role.

I blogged previously about our Duty Analyst role here.

Implementing a duty analyst role minimizes the operational interruptions to our team members working on projects. Providing project members focused time to work on project challenges and meeting milestones becomes easier without operational interruptions.

I am proud to say my team delivered on our operational responsibilities and completed 43 projects in 2009.

Here is the breakdown of projects my team delivered:  Read more...

• Projects by Size : Small = 19, Medium = 14, Large = 10
• Projects by Governance : BCIT Executive = 3, IT Governance Team = 14, Business Applications Committee = 5, Departmental = 11, Operational = 10

Last Thursday Nov 6, 2009, I spent a valuable day at the Forrester Western Canadian IT Summit.  The day began and ended with  keynotes and in between there were 3 breakout tracks – CIO, EA and IT Ops.  This post covers a keynote by Bobby Cameron on Marketing IT.  I will write a separate post on Jeff Scott’s (@logicalleap) two sessions.

Morning Keynote – Driving IT Realization: The Marketing of IT – Bobby Cameron, VP and Principal Analyst, Serving CIOs

Here is my summary of Bobby’s presentation highlighting the 3 key points:

1. What key factors improve the perception that the IT organization is aligned to the business?

Bobby provided 3 pieces of research  and a summary of key factors that keep IT a cost centre.

First, “CEOs – 75% are happy with IT overall – but they don’t expect IT to deliver much“.  IT is not seen by CIO’s as a source of innovation or a source of process improvement. We even struggle being seen as capable of managing the people and assets under our control. (Me: we do not have the reliability of a utility yet)  Read more...

I am writing about a topic that came up this week when working with my colleagues at the University of Alaska Office of IT. A common challenge all IT Service teams face delivering projects when there are huge operational demands.  Here is the approach we took to address this critical and ongoing challenge in my Business Application Services team in IT Services, BCIT.

In Sept 2007, I took over as the Manager, Business Application Services at BCIT. For the first 4 months, I took a  meet, listen and ask approach. I held one-on-one interviews with each of my team members (23 systems analysts in 3 teams).  I setup regular meetings with all our key client stakeholders (Registrar’s Office, Finance, HR, Financial Aid, Student Services, Facilities, Alumni and others) around BCIT. I needed to hear from my team and our clients about the challenges they faced and their perceptions of our effectiveness in meeting commitments.

In all the meetings and interviews, I heard a common theme from…  Read more...

• My team: “We have too much to do and can not keep up with the demand from our clients.”
• Our clients: “Your team is working hard but we have important projects that are not getting done on time.”

I am back at the University of Alaska Fairbanks this week to collaborate on IT Service Management with a focus on:

• service definition
• service delivery
• service catalogue.

I will also be a presenter at Univeristy of Alaska Office of Information Technology 3rd Annual Techfest 2009 talking about BCIT’s Technology Enabled Knowledge (TEK) strategic initiative that wrapped up this spring. I has been just over a year since my first visit and I am keen to work with my colleagues again. Will blog more later in the week.

In my conversation with Gene Leganza, Forrester VP Research last week ( @gleganza), we spoke about how to address delivering technology in a consistent manner. It inspired me to write this post about our Solutions Council. Here goes:

How do you handle service requests in your IT organization?

Have you adopted an IT Service Management approach?

Can you confidently articulate standard solution architectures for commonly requested services?

In the past, we struggled with a lack of consistency in our technology solution delivery.  Even though we are a centralized IT department, clients received different solutions and services depending on who they contacted.  Imagine how confusing it was for our clients; they could get application solutions from one of LAMP, Oracle, Microsoft, and Lotus Domino application platforms.  Two clients with similar requests could get two different solutions based on which developer they talked to. This further added to the complexity of the application portfolio we manage – meaning more time spent on “keeping the lights on” and less on delivering new solutions.  Read more...

On August 11th, Gartner announced a “new approach for enterprise architecture” that they labelled “Emergent Architecture”.  I got a chance to read some responses from Todd Biske, Mike Rollings, and Dion Hinchcliffe.  Thanks for the great insights and commentary.

In the press release, Bruce Robertson, Gartner Research VP states the two characteristics of “Emergent EA”:

1. “Architect the lines, not the boxes – which means managing the connections between the different parts of the business rather than the actual parts of the business themselves.”
2. “It models all relationships as interactions via some set of interfaces, which can be informal and manual”

On characteristic 1. is if you only look at the connections between parts of the business, how can you look for opportunities to reduce complexity, increase efficiency and implement reusability? I believe enterprise architecture is about the whole organization and its environment, not just pieces of it. As an example, our EA practice encompasses IT Service Management (ITIL), Business Analysis (BA) and Program Management (PMO).

On characteristic 2. , again all this says to me is to take a “user experience” approach to describing the architecture. This is nothing new as far as I can tell … perhaps I am missing something?  Read more...

Andy Blumenthal wrote a great post “Adaptive Leaders Rule the Day“. In his post, Andy reviewed a Harvard Business Review July 2009 article “Leadership in a (Permanent) Crisis” and commented on the article’s insights on adaptive leadership.

I really liked Andy’s quote “Leaders need a proverbial “toolkit” of successful behaviors to succeed and even more so be able to adapt and create innovative new tools to meet new unchartered situations.”

Andy listed some of the successful behaviours in the “toolkit”.  I recommend you read the full article to get all of Andy’s insights. 

Here is the list of successful behaviours:

• “Foster adaptation”
• Stabilize, then solve
• Experiment
• “Embrace disequilibrium”
• Make people safe to question
• Leverage diversity

Taking a similar approach to my previous post on Generative EA Principles, I will explore and share how Andy’s list of behaviours fit with our EA practice (and maybe yours).  We have a long way to go to fully leverage the successful behaviours but having some clear names for what we have accomplished helps.  Thanks Andy!  Read more...

Mike Kavis posted another great piece on why we should use Enterprise Architecture. As always, Mike has some real gems in his post.  Here are a some:

• “It sounds to me like people have a technical solution and are now looking for a problem to solve with it.  It needs to work the other way around!”
• “Well, coming to the business with technical solutions asking for help to justify them with business drivers is not alignment.”
• “At this point the ROI should be much easier, because the solutions were driven by the problem statement(s), not the other way around.”
• “Without this alignment, IT will constantly struggle to sell technical solutions to the business and come up with appealing ROIs.”

With the recent economic situation, business leaders are looking more and more to IT leaders to help enable cost savings and business performance. In my regular meetings with my business colleagues, this is becoming a consistent theme. The only way this will happen is for IT leaders to sit with business leaders and understand their issues and problems.  Once this problem is understood, then the  IT leader can bring to bear the appropriate technology solution.  The ROI is put back on the business (where it belongs) and how the problem is solved not on the technology that enables the problem solving.  Read more...

This post is in response to a question from Nick Malik about my thinking of how EA and ITIL relate to each other. In my post on the EA Model I use to help communicate with our community, I added IT Service Management (ITIL) into the V2 graphic. I was not clear about the relationships between ITSM and EA.

This spring I created a presentation for the University of Alaska EA and PM Workshop I was invited to speak and teach at. Instead of just posting the PowerPoint, I thought I would turn it into a post.  

I am not going to give you all the definitions of IT Service Management or the history of ITIL (IT Infrastructure Library).  I want to focus on how EA and ITIL work together in our organization. Note I have not had a chance to investigate all the ITIL V3 changes so this discussion is about ITIL V2.

In ITIL V2 there are two main categories of services under the IT Service Management umbrella – 1) Service Support and 2) Service Delivery.

Looking at Service Support, I will focus on Incident, Problem, Configuration and Change Management.    Read more...