Consistency in Technology Solution Delivery

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:

  • Network
  • Server
  • Storage
  • Application Development – LAMP
  • Application Development – Oracle
  • Application Development – Microsoft
  • Business Analysis
  • Presentation – Web Design and User Experience
  • ITSM – Service Desk
  • IT Security
  • Enterprise Architecture
  • IT Services Management

Solution Architecture background:

  • emerged from Enterprise Architecture as a discipline to guide to support a client’s short term business needs
  • applies EA Guiding Principles to solution recommendations – “Reuse – Acquire – Create”
  • ensure “best fit” recommendations that best suit our client and IT Services with consistent, supportable solutions to academic and business needs

Desired outcomes from a Solutions Architecture practice:

  • improved credibility of IT Services in our community
  • establish a consistent process to determine technology solutions for client requests – our clients get the same answer every time
  • increased agility and responsiveness to our community
  • reduce time lost to fruitless technology religious wars
  • leverage EA guiding principles of managing complexity by reuse

Solution Council Mandate:

  • charged with finding solutions that fit our clients, IT Services and BCIT
  • equipped to determine the level of analysis required to assess a particular need and ultimately make a technology recommendation based on that information
  • recommendations will be firmly grounded in the principles of Enterprise Architecture
  • meet weekly to provide timely solutions recommendations to our community

What is reviewed?

  • non-operational work = a service request (not an incident)
  • new requests that require technology to enable the solution
  • some requests have an obvious solution that already exists in our enterprise architecture – take the “reuse” route – assign the work to the technology manager responsible for the solution architecture = “Just do it!”
  • less obvious solutions will need some degree of business analysis to define and refine the client’s request
  • solutions that require new budget and/or a significant investment of people resources are routed to our IT Governance committee for ranking

I hope this gives you a sense of how we are working to deliver consistency in technology solution delivery.  I will post another blog about the types of service request our Solutions Council has evaluated and the solution architecture recommended.