Tom Peruzzi's thoughts on digital, innovation, IT and operations

Ops Predictions 2011

Posted in general failures, ITSM, organizational, startup failures by opstakes on December 21, 2010

End of year is coming, time for review and predictions …

What we have seen this year is the emerging trend to try to move to the cloud. Why say try? Cause a lot of different lacks did delay decisions: lack of experience, lack of manageability, lack of security, lack of commodity, lack of portability and much more but the train cannot be stopped anymore. We will continue to see different diverse ways to the cloud, the aggressive one (we just do it), the one’s moving via private virtualization, the one’s doing outtasking to the cloud and the one’s not knowing that they are already in the cloud.

So what’s next? According to the analysts cloud is directly on the way to the phase of desilusion. Sounds bad but isn’t so. We now reach the working scene, the marketing whow is over and we can start working on a deep and permanent way. So think about it: cloud will become commodity in 2011, we will stop talking about who’s in the cloud or not, we will start just using it.

This leads to another trend for 2011: cloud operations. We did central operations, decentral operations, virtual operations, outsourced operations, outtasking and whatever, next is cloud operations. Maybe you will not take care on it but potentially you will have to think about how to operate your IT then parts of your IT are somewhere (you do not even know exactly the location, just the name/identifier of the cloud).

This leads to tons of aspects in terms of all ITSM processes, especially change mgmt (do you still own your cloud virtual environment … how to combine those releases …), incident, event and problem mgmt. (who manages what?), SL management and all others, with special focus on IT financials.

Next trend, partly invoked by ideas like DevOps is agile operations. The more agile the company, the more agile development the more event driven the IT. This leads to agile operations for the IT ops department. So how to do so?

Agility means being very flexible and self responsible within a certain frame/border. Agile operations mean being very reactive, fast and flexible within a fixed set of frameworks/standards to deliver prompt IT resources on a very $$based approach.

So agile operations relies on cloud operations and vice versa. In my understanding and strong believe the trend per se for 2011 should then be called

agile Ops operations

So what does this mean for you? Think about strong boundaries and frameworks married with a high level of ops automation. This superset is then offered to your company / development enabling them to use ops resources on demand and cost sensitive. You as the ops entity do all the cloud stuff either private, hybrid or public within your defined subset to deliver on a regular and flexible bases predictable IT.
For me this sounds reasonable good. Remember, I’m an ops man … doing agile ops operations even means you create your ops platform (DevOps), you keep the releases within your responsibility but you stop from reacting and being the holy grail nobody knows about within your company. Ops get’s public, viable and business enabling to the company! This is our all time goal and this must be the goal for all of us.

We will see what happens exactly in 2011, hopefully my predictions comes to truth by 80 %.

Advertisements

SLA Mania

Posted in general failures, ITSM, organizational by opstakes on January 21, 2010

Even if processes do not or only fragmented exist, people start writing weird SLAs with implicit and explicit definitions of services without any service catalogue, portfolio or even without any understanding of what differs between infrastructure, app and a service …

What happens then? They start to build their opinion like “Hey, we have an SLA framework … ” or “Hey, we have a service catalogue ..” Asking them about how services are defined, build, maintained, monitored and reported results in answers like “this ist still done on a manual and on demand basis … ” or “… we are working on that topic …” or “hey dude, we still have to go a long way, keep on waiting …”

To be clear, thinking about SLAs is quite important to the organization and defining a structured aproach (aka SLA framework) is a really good way to go but:

  • if your service support is still foggy, a major SLA part will be foggy too
  • if your ownerships are not defined, a major SLA part will be undefined
  • if you do not have any process about what and why is an offered service, you will define either customers wishlist or a very technical perspective

We will be able to list 100 or more additional blamings, but it is not our goal to do so. The goal should be the answer on what’s a better or more appropriate way?

I would suggest the following:

  • Know your Service Support processes
  • Get an Service Responsible/Representative in
  • Know what you will be able to monitor and report
  • Define your Service level internally, know what you are able to deliver (aka OLA)
  • If possible show numbers, eco values mostly help by talking to your (even internal) customer
  • Only define achievable goals/metrices
  • Only define countable goals/metrices, at best they should be monitored and reported automatically by systems/machines

Start by defining the most valuable (business) processes for you customer and always think in terms of your customer and his potential end-2-end view. And  – maybe the essential point – communicate the SLA to all engineers which are needed to run the service. Defining is step1, running is 2 and running is king!

You can use frameworks like ITIL, CobiT and others to get an understanding of what and how you should define within an SLA and how the process can look like (how to come to a service portfolio, catalogue and the associated SLAs) but potentially this will be pretty to much at first step and business pressure will not allow you to run a one-year-project just for a bunch of SLAs.

So keep in mind, go as defined as possible, know what you can deliver and how to measure, agree on internally first, know your support processes, escalations and at last go to your customer. Assure, that your customer is familiar with those processes too and start defining the mutual understanding of the service (the SLA). At end communicate the results to your IT department and start implementing. And don’t forget to monitor not only the values, monitor the SLA too… (is it still valid, useful, anything to define better …)

All the best with your SLAs!

We know it better

Posted in BCM, ISMS, ITSM, KnowHow, Skill, startup failures, technical by opstakes on November 17, 2009

Potentially yes, but how to be sure? It is of tremendous importance that a growing organization knows what it is able to deliver and how to get additional knowhow/expertise/resource on board. This is not a prayer for externals but:

  • understaffed organizations fail on a long term view
  • there is no more space for innovation, thus you stop developing you, your employees, your organization
  • Peaks should be offloaded, innovation stream not be broken
  • you cannot know everything the way the market does

So keep in mind, that you should only run your strategic stuff and if you start innovation, bring the market experience in. This does not mean that external partners do all the work. Where necessary, they should support, assist, coach you, but you are the one who knows your business best and if you bring in externals, do not forget to manage them. They are just people, maybe good ones with special expertise, but they are people like your employees are, the need order, direction and management. An uncontrolled external is a potential high risk for your organization as he is seen as a special knohow carrier and he can not only break your project, he can damage your organization too.

So to summit, two things to say: Bring in external partners where necessary, nobody expects you and your org to know everything better than the market. And last manage partners to deliver successful and in-time projects.

%d bloggers like this: