ITIL Foundations Training - Day 2

So I've figured out a few things about ITIL so far. There is a function called Service Desk that is a single point of contact for all tactical IT needs. There is a group of processes called Service Response primarily responsible for Incident, Problem, Change, Configuration, and Release Management. There is a group of what I consider second level ITIL processes called Service Delivery. These services include Service Level, Financial, Availability, Capacity, and IT Service Continuity Management. Both the function of Service Desk and the processes around Service Response and Service Delivery sit firmly on top of data contained in a configuration management data base CMDB. From the Enterprise Architecture (EA) side of things I'm really excited about how applications can be designed to plug directly into the Service Response side. Application architects need to look closely at ITIL and determine how you can introduce non-functional requirements into your application for the benefit of the entire IT operation. Sometimes this is integrating things like QuickCounters in your applications, sometimes it might be using robust error handling and logging capabilities to create incidents in the Service Desk. There is a control side of me that really looks at financial management and would like to get my head around what it costs to provide IT services to one group over another. I think you could claim in our organization we spend three times more on one group than we do on any other. Being able to back that up with numbers could get you the leverage you need when budget times come around.

I'm not sure how much I'm going to get into ITIL at this point. I see myself primarily focused in on release management and how that overlays with the environment and deployment disciplines in RUP. I do see a significant value in having a CMDB track changes to the development environments and being able to compare the state of a test environment against the state of the test and production environments.

How release management could have gone better

One of the challanges I find in bringing a new application online is having the new application support compared with the old applicaiton support. We may be replacing a 20 year old system where the Service Desk has no visibility into what the AS/400 is actually doing, but they have had 20 years of experience to figure out things by intuition at this point. In contrast I'm bringing online a brand new shiny (shiny is key for executive buy in) high performance monster with over 600 CIs (Configuration Items). This new monster uses the latest and greatest development methods, methodology, and we have performance tested the heck out of it. Through observing users activity during testing we have determined that they will be able to accomplish their tasks twice as fast as on the previous system. In fact there is such a buzz around the product that instead of resisting the change, people are beginning to stop IT people and ask them when this software will be available for them to use. The system rolls out and we have one of those mid-morning parties with pastries and congratulate the project team.

Meanwhile the operations folks are scrambling to figure out why some users are experiencing slow response times, and others can't access the application at all. The problems seem remote and not even connected, then the APB comes out, all IT staff must put down thier pastries and go to the big conference room to figure out why this rollout is going so poorly. Apparently there is widespread panic among the user base that we shoudl rollback to the old system and spend another few years until this system is right. We scramble for a few days and detemrine that there were four users affected. One was a VP who had installed something on his machine that was conflicting with the new software. One was a user who's hard drive was full of family photos and MP3s and the software didn't fully install properly. Two users had reset their passwords earlier that day and needed to reboot their computer. It was some cached credentials thing with workstations and Active Directory.

As it turns out the problems were all very managable, but the application suffered some significant loss of face due to circumstances we never tried in test. Because the release plan didn't have a solid Service Desk behind it with a single point of contact for users with issues, we were unable to bring in calls in a uniform manner and deal with them in a meaningful way.

Bottom line here is that if we had a CMDB with auto discovery we would have know that the VP had something on his desktop that conflicted with the application. We would have known about the hard drive running out of space. Then we could work on the reboot your machine and all will be fine issues. Not only that but we would look like we know what we're doing and provide customers with increased uptime.

ITIL Foundations Training - Day 1

I went to my first day of ITIL foundations training as part of attempting to bridge the gap between AppDev and our operations folks. We've got a custom implementation of RUP that I'm really excited about, and I'm not sure how AppDev really works within the ITIL process.

I can't say that I really know the answer, but from an Enterprise Architect perspective I'm beginning to get really excited about the prospect of a CMDB and seeing how to lay out for folks the impact of change.

Up until now, things have made a lot of sense to me. You've got your basic web site calling a few SOA like web services, tied into back end databases and external providers, some over VPN and some using the WS-* stuff. Most of the time we use enteprise library June 2005, but sometimes we use the January 2006 stuff if we are using the new Common logging libraries that drop into our Enterprise Exception handling process tied into ProIT and our new TFS server. I mean how hard can this be?

I mean I've got pictures, deployment diagrams, and even provide operations with a set of MSI files that contain embedded configuration settings. In the event of a disaster all you have to do is go to the file share and double-click.

Maybe it's a training issue and our operations folks just don't get how to run Microsoft operating systems and .NET web applications. Maybe they just don't care.

Well as it turns out it's probably not a training issue at all. And when push comes to shove these guys (gender neutral guys of course) probably would go as far as I would for the organization.

Maybe the stuff I'm packaging up and sending over abstacts them from the issues they are likely to deal with in production.

There is one key take away for me at this training. When AppDev shoves things over the wall to operations I think we'll need to be more considerate of integrating our systems with our ITIL Service Desk and Issue management system, especially around filtering and avoiding a DOS attack on the Service Desk.

SubSonic as a new LLBL

On a project I did a few years ago we used the 1.1 version of LLBLGen to crank out a DAL. Once I converted the project over to .NET 2.0 yesterday I discovered that there was a significant amount of search and replace on the code generated out of LLBL.

It's really too bad. We really liked LLBL. We had investigated a LLBL replacement and after pinging a few friends I was given NHibernate and SubSonic as two options. I had also used DLinq on one of my VMs before but I didn't want to write too much code around a preview release. (Although it delivers most of what we're looking for)

I downloaded NHibernate and took a look at it. It wasn't as intuitive as I would have hoped and decided to keep looking. Then I took a look at SubSonic. It was pretty much spit simple and best of all it came with a sample that worked for me. As I was trying to communicate with others in my group how it could be used, I sent out a link to the 20 minute video podcast which we are calling our training materials for the tool.

We are replacing our current LLBL stuff this week with SubSonic stuff and we'll see how it goes. It's looking promising.