Startups vs.best practices... can't we all just get along?

Transitioning from CIO to CEO has been an interesting move for me.  This is not my first time as a CEO, but my role as CEO of Vigilant was short, and Vigilant was an IT services company, so it was still chief of IT services.  However, as much as I dog on ITIL, CObIT and other industry frameworks for being too esoteric and vague, I always have appreciated and applauded the principles and intents.  As SMAK has launched from thought to design to code to hardware, my experiences and training in lifecycly management has served me well.   Our Strategy phase quickly incorporated what our resources and capabilities could be, would be, and should be.  Since I have the unique opportunity to start this IT operations from scratch, I wanted to get our LifeCycle management clear and correct from the start.

Just because we are a lean startup doesn't mean we need to run in chaos.  I certainly am not going to cast all hard lessons learned in the trash.  I know that if a disparate development team is not given a solid and stable platform for code migration, our IT ops will be a mess.  My ITIL students and past clients have heard this expression a million times from me.  If you want to cleanse the pond, you must clean the streams that feed it.  In other words, if you want a clean IT operations platform, you must have solids standards and architectures in place for all involved to work from.  Breaking down the DEV/QA/UAT/Prod barriers is a challenge.  Typically it is based on rights and security.  Access control can be a nightmare and causes much of this angst.  By setting up boundaries and protocols up-front, the streams will stay clean and the pond will be a source of value.

So here is my strategy straight out of SMAKs operation guide on how I plan to allow autonomy and control co-exist.

User Setup and Configuration:

To secure the environment we will utilize a strategy of layered access to systems. Each environment will utilize the same set of layers with a name denoting their environment.

To gain physical access to systems (keyboard, SSH, Remote windows) there will be a user created.
Once physical access is gained you will need to change user or run-as a user with rights to access either system settings / application data (php, xml files / database settings / database information.
Access controls are organized in to functional groups based on assetts. Asset types fall into 5 categories:
Production – Production environment with real users and customers. Needs to exhibit high service warranty.
Demo – Production+ build version of our site with fake data that we will use for demonstration at events, webinars, and other marketing events. (Production+ means at least production vesion with potentially new features to demonstrate functionality)
UAT – User Acceptance Testing Environment– QA Build version signed off on by production release team for Security; Availability; Performance testing. Now awaiting user interaction; regression; usability and design; product marketing sign off.
QA – Quality Assurance Environment – Build version that has been signed off by development team and gone through integration testing. Testing in this environment will focus on Functionality; Security; Performance; Availability; Installation; Recovery. Training to production release team will happen at this build stage. Sign off by Product Management.
Dev – Development Environment – Dynamic build versions be created in this environment with 2 core focus areas

1. InnoDev - New product development focused on publishing new feature sets and requirements from Product Marketing team.
2. ProbDev – Problem Management environment focused on production snapshots for replicating issues found in production.

The following table lists the usernames:  {obviously cleansed and changed for security purposes}  Key here is to create naming conventions that make it ease for each lifcycle to be identified and controlled.  This will make it a lot easier with building RACI models in your CMS map.

User Type	Production User Name	Demo User Name	UAT User Name	QA User Name	Dev User Name
Group Name
Enterprise Cloud Administration
Access User
System Admin
Application Administration
Database Administration
Data Access User (can see datapoint for customer information)
Customer Service Access (access to configuration and registration info)

Dazed and Confused - Pink11 revelation

It's 6am Vegas time, and my head is spinning.  I am coming up on day 3 for me of one of my favorite conference venues Pink Elephant IT Service Management.  After years of studying, implementing, consulting and leading ITSM intitiatives and projects I woke feeling like someone had picked my pocket.

WHY IN THE WORLD DO NON-IT COMPANIES HAVE IT SERVICES?
THEY DON'T NEED THEM!
There I said it.  (actually' I've already tweeted it).

Why would I say this?  Me, after standing on soapboxes for so many years.
I don't know if it's the past year of doing the ITSM Weekly Podcast and listening to guests.  Having some gut wrenching discussion internally at Inforonics about our corporate strategy.  Maybe it has been reading the Universal Service Management Body of Knowledge (after reading this post Ian offered users a $50 discount. use Discount code "VigilantGuy" tx Ian) and meeting its author this week Ian Clayton.  I'm sure it's a  bit of all that, but's it's definitely 2 distinct events that have happened in sessions here at Pink.  Which is why this contiues to be one of my favorite venues.

Event #1) After a 45 minute panel discussion on Service Catalog (of which I had the pleasure of being on) the last question of the day was by a women who was frustrated by the inability to have services defined and asked "Besides Email, what are some other IT services".  I then hear each panelist rattle off System after system,  network, storage, etc..   It was clear this panel of Service Catalog (where you write down what the services are for the business) couldn't agree on what a Service is.

Event #2) In a panel discussion moderated by Rob England (aka The IT Skeptic) the topic was the elusive CMDB.  A source of consternation, frustration, and confusion throughout the ITSM industry.  The major point hit again and again: It has to be Service Aligned....  But wait, we can't define what a service is.
As I sat there and listened to the extremely passionate arguments, emotional lessons learned, and even one person honeslty begging for help.

We are trying to put Round Pegs in Square holes.  We are making up a layer that does not need to be there.  The IT Service layer is fabricated to fill a misconceived whole.  Well there is no whole.

Business Models are supported by Operational Models that are managed through systems and processes.  Business Services are the only services a business needs.  These can be supported through systems layer that correlates and integrates assets (technical or not).

Yet, that is not how ITSM community speaks and talks. In the ITSM community if my Business Model is about Hospitality, we still create this thing called Storage Area Network Services.  When did SAN Services become something people buy to get a hotel room.  They Don't!

So if I follow the current thinking on ITSM, I am supposed build and define the SAN Service, put it in a catalog, map it to a CMDB, and present its value to my CEO and ask him for a seat at the table.

If you were CEO, would ask me to sit down?

I can tell you what Captain Arbrashoff would say: "Beat it buddy"

Please tell me your comments or send me a tweet @vigilantguy  I would love to hear your response and thoughts on this.
On to day 3.

ITSM Weekly the Podcast (Week10)

Great content for CMDB discussions this week.
For my non-ITSM blog readers CMDB stands for Configuration Management Database.  It's where you store information about the technology and processes used to manage your technology systems.  I have blogged frequently on the topic, and have had a running theme of "Keep it pratical, keep it lean, keep it relevant."  So it was a real  joy for me to have an expert like  Glenn O'Donnell on the panel this week.

What's great about this topic, is Glen's perspective can be applied to many complex undertakings. We frequently use the expression don't boil the ocean, yet constantly people take on too much.  I think you will enjoy listening to Glen and his perspective of complexity and progress.

Show Notes by Chris dancy Here:  http://www.servicesphere.com/blog/2010/4/11/itsm-weekly-the-podcast-week-10.html


ITSM Weekly The Podcast (Week 10) from ServiceSphere on Vimeo.

Immediate value of a CMS - yes it's possible

Configuration Management Systems (CMS) = VALUE... not for most people.

In fact most IT shops I've spoken to over the past 6 months have abandoned their CMDB/CMS strategies. Why?  ‘No immediate value’ has been their biggest complaint.  They are not seeing the benefits of having the relationships of assets. 
The clear distinction, between the organizations that are moving forward with their CMDB and CMS strategies and those who have thrown in the towel, has been the ability to effectively tie in their visual operations to their CMS. 
These successful organizations are leveraging the relationship information to show which apps are running on which pieces of the infrastructure and are providing a view of this relationship to their 1st and 2nd tier support teams.  Empowered with this information they are finding their troubleshooting process of elimination faster and more efficient. 
As any of us in the support arena know, the work to get systems back on line consists of 80% finding the problem and 20% fixing it.  So armed with this visual aid to help root out and verify the components that are working, the practitioner is closer to finding the one that is not.

So here is my advice if you are on the verge of blowing up your CMDB: 
First: Verify that you have the right grouping.  If your CMDB is grouped by technology, then it will not help Tier1 and Tier2 teams, who are  getting complaints about applications. 
Second: Create a visual element for the application and show logical relationships to the systems that support it.  Link those elements to your existing CMDB for more current and accurately collected data.   

It's by no means the Nirvana that ITIL V3 pictures for us, but it will at least allow you to leverage the work that you have done, and to start making the data and information you have more meaningful and relevant.

Check out these tools for a quick start and easy deployment: 

OpenSource - OneCMDB or BizDiag

Commercial  - NI2or MS Viso

Of course, BSM tools can be leveraged, but they are not going to be quick and easy to deploy.

Special Note: I am doing a weekly Internet Radio show called "ITSM Weekly" with Chris Dancy (ServiceSphere) and Matt Beran (Service Desk Manager).  Please check it out. Would love to hear your feedback.

ITSM Weekly The Podcast Week 1 from ServiceSphere on Vimeo.

Next BLOG - Is ITIL losing its steam?  Seems like the process framework is losing ground in the US; what does that mean?  What will replace it? 

The Role of Configuration Management Systems within the Knowledgebase

If you have been sucked into the world of Twitter, like I, have then you have seen all the buzz that has been going on about "Configuration Management Systems". To sum it up, basically there are 3 camps with opinions on the concept:

Camp 1) Says CMSs don't exist and are fantastical.

Camp 2) Says they are fundamental to your IT Service Management strategy and it is impossible to live without them.

Then there is where I personally sit...

Camp 3) CMSs exist in every organization. Organizations that say they don't have one wouldn't know one if they saw it. Organizations that say they don't need one are already using it.

So for the newbies in my blog world, let's cover what a CMS is.

Simply put a CMS is a logical collection of information about business IT resources. Over the years they have matured, but pieces of the CMS are asset databases, system maps, network diagrams, software architecture diagrams, IP address lists, escalation procedures, etc...

As you can imagine, it is not easy to document the multi-dimensional relationships between hardware, software, locations, people, versions, ahh... my head is hurting.

And there you have it, the reason why there are so many people in either camp 1 or Camp2: People try to take in too much information and map it.

This is also the biggest reason CMDB implementations fail. (CMDB is a set of databases that hold specific configuration data. CMDB's link together to make the CMS.)

Be that as it may, unless your IT shop is super small or completely defunct, you most likely have quite a bit of information about your systems documented. The challenge, then, is how to find the info and make it usable.

Everyone wants a robust knowledgebase. They want this knowledgebase to tell them everything they need to know. How do we fix problems? Where is the equipment is located? Which systems support which users?

All of this is valuable information that is critical to supporting the business. However, like the system data, you may have it, but it is probably difficult to find and tough data to manage.

This is where a CMS comes in. A CMS simply is a utility to help relate documentation together for ease of use and finding. Many organizations turn their Wiki's or Intranets into a CMS. Of course you can leverage other powerful tools such as Visualization tools, discovery, monitoring integration to help give more context to data. Like any data source, it is important to remember Garbage In-Garbage Out. So it is critical to make sure you have a source control/change control on the content that is in your CMS.

When this information is brought together through one source, the Service Desk and others can utilize it to find the information to solve problems, to resolve outages, to analyze risk, etc...

Now that we have a clear picture of which systems depend on which, and what services they provide, can't we leverage this for better rules related to monitoring for pinpointing root-cause?

We sure can. Next month I'll take us down a path of leveraging the CMS relationships for automating dependency modeling within end-to-end monitoring tools.

Is now the time for a Service Management Initiative?

Yes, I'm still alive.

Very sorry I have not posted in a long time.(or as we say here in Boston " a wicked long time")

As many of you may have heard Vigilant was acquired by Inforonics in Littleton, MA. It's been a lot of work to get the acquisition accomplished, but we are excited about the new opportunities.

You can read more about that here: Inforonics Acquires Vigilant

Though I've delayed in posting for this particular topic, it may be a good thing.

I'll have to admit, that earlier in the year I may have written this quite a bit differently than I do today. It's been a wild ride here in the US with our economy, and the signs are still blinking as to our recovery. (imho). So my "If I were CIO" strategy is a bit different than in the past.

So what about the IT Service Management strategy that was so vigorously trumpeted in 2008?

From what I have seen there are 2 clear areas that every company needs to focus on, and they need to do it now.

Configuration and Problem Management.

(yes - I know, I didn't say Change, I'm shocked as well, but like I said this article has 9 months of my experiences behind it, so as opposed to the speculation I would have written about in January, I'm writing based on what I have seen.)

Why Configuration and Problem?

First off - the real issue is Problem Management. Companies are really bad at it! Thus when you are working on a problem, and making no progress, this means the business is suffering. Companies can not afford downtime and slowdowns from technology issues, ever - especially in this economy. They need to have systems up and running fast.

So what's the problem with their problem management?

Asset mapping and documentation. I've worked on several major performance and availability problems for clients this year. Serious revenue impacting issues! In each and every example the operational deficiency, and thus the reason to bring our team in, was a gap in understanding of how the technology really supported the business operation.

That is why if companies are going to invest anything in their Service Management initiatives this year, I truly believe it has to be in Configuration Management. Config Management is not just about the assets. It's about the business service, and how the asset's support them. If we (IT - the custodians of operational business technology assets) are going to add value to the business, we need to ensure that we have a handle on what the state of our operations truly is. We need to not only identify the asset relationship, we need to ensure that we can determine its health and its ability to perform on-going.

Yes, of course Change Management comes into play here. However, Change Management alone is not getting the job done. In each of the organizations I referred to above there was a CAB, RFC's, all that jazz. However, there was no record of truth or current health state of CI's. Changes were being made against assumed configurations, without any understanding of their current state of health. (in other words, no integration into event management) So changes were being made and requested against incorrect information and unstable CI's. Hence the problem kept getting worse, not better. (My analogy to the clients as "Stacking Cue Balls" each change caused another break - just like each ball stacked causes the lower ones to topple)

With a well thought out CMS strategy, including health monitoring and CI capacity analysis tools, Problem Management becomes a lot easier for organizations. A clear picture of the assets in relationship to each other helps the process of elimination, it provides a direct plan of attack to isolate root cause, and it also provides helpful information in getting the right people involved.

This is why companies struggle with Problem Management. They expect the PM process to give them root-cause. This will never happen if the proper data is not collected and managed in a meaningful way.

For my next posting I'm going to breakdown the Problem Management process we've used to isolate faults quickly. -I promise it won't take me 9 months to write it. :)