On Friday February 19, 2010, I underwent laser eye surgery (Intralase Sub-Bowman’s Keratomileusis) to correct my short sightedness. I have worn glasses since I was 6 years old and contact lenses since I was 16. Over the past 15 years, I developed an allergic reaction to the protein buildup on the contact lenses and had to restrict my use to sports only.  This is a quantum leap forward for me and I am floored by the results – no more glasses!  Thank you to my surgeon, Dr. Suren Sanmugasunderam, FRCS (C) and his team at London Eye Centre.

The evolution from squinting to see, to having thick, then thin lens glasses to contact lenses and now to laser eye surgery led me to think more about several topics:

Problem Management – as described by IT Infrastructure Library (ITIL):

A `problem’ is an unknown underlying cause of one or more incidents, and a `known error’ is a problem that is successfully diagnosed and for which either a work-around or a permanent resolution has been identified.

As a child, I squinted because I did not know that I needed vision correction (unknown underlying cause).  My opthamologist successfully diagnosed that I was short sighted with astigmatism.  The workaround he prescribed were prescription glasses.  Now glasses helped modify the root cause of my vision problem but did not fix it.  Contact lenses were the next evolution of glasses but still did not address the root cause.  Finally, my laser eye surgery procedure modified my eyes by vapourizing microns of cornea cells to correct the root cause providing a permanent resolution.

How often do we consider a work around good enough? Once the work around is in place do we just get used to the added complexity without attacking the root cause?  Do we take the time to really look for a root cause and think of ways to permanently resolve it.  Enterprise Architecture and ITIL together provide the framework and processes for us to travel this road. Making time to review what we have done in the past is important so that we can move our enterprises forward with a solid foundation.

Manage Complexity – Complexity as described by Roger Sessions (@RSessions):

I use the word “complex” to mean an entity that has more “complexity” than needed to do what it is intended to do. By “complexity” I mean the number of internal states.  Read more...

Tonight, I had the privilege of being a guest lecturer on Enterprise Architecture for a class at the British Columbia Institute of Technology. My colleague Brian Hosier invited me to give an overview of EA for his students.

I had to do some serious chopping of my 2 hour workshop to get things down to a manageable timeframe. Even then, I felt extremely rushed and barely skimmed the surface of all that Enterprise Architecture is.  The class went well and I got great questions from the students.  I hope this short introduction to EA helped some of them think about the big picture.

As I was presenting, I realized how much our EA practices are IT influenced. This is a natural thing being that we grew EA out of IT and IT is where it primarily resides. As I presented some of the artifacts we developed, it became apparent that I need to rethink how to present EA to newbies. After a bit of theory and overview, I presented how EA can be applied strategically, tactically and then a bit on business architecture.  The problem was that for each area except Business Architecture, my examples were very technology focused.

I will make time to review my course material to see how to restructure it to better communicate the complete breadth of Enterprise Architecture.  Perhaps reviewing my notes from the Carnegie Mellon Certified Enterprise Architect program I completed in 2009 will help.  I need to find more examples of artifacts that are more people and process oriented.  In today’s fiscal climate, perhaps more focus on cost savings by focusing on managing complexity and its impact on organizations.

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.

Fortunately, we laid a foundation to address this ongoing challenge. First, we implemented ITIL Incident Management and the Service Desk function allowing for a single channel for all IT incidents and service requests. Next we built an Application Portfolio and did some analysis discovering how many application delivery solutions we already had in place.  Third, we built a Business Analysis practice to assist our clients in articulating their requests especially those that might require a technology solution.

We made several attempts to get our application developers into the same room to think about and articulate standard solution architectures.  Unfortunately, all this did was further enflame existing technology religious wars.  In one meeting, a developer go so angry that he stomped out of the room and refused to participate in future discussions. Now this could be my lack of facilitation skills but some technologists are more change resistant than others; especially when it comes to their “favourite” technology.

In the fall of 2008, we established our Solutions Council to address our lack of consistency in solution delivery.  The solution council is chaired by a Solutions Architect and hase experts from the following architecture layers:  Read more...

• Network
• Server
• Storage
• Application Development – LAMP
• Application Development – Oracle
• Application Development – Microsoft
• Business Analysis
• Presentation – Web Design and User Experience