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 %.

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.

2 people are a NOC

Posted in organizational, startup failures by opstakes on November 10, 2009

Despite the fact that people cost money you will never be able to run a commercial 24/7 site with just 2 people in a secure and safe 24/7 way. On the one hand side you burn your employeees on the other hand side you will potentially break local law regarding workers rights.

And, to be honest, If you want to run your application you have to think about what the work of an NOC will be, is it?

  • monitoring, remediation
  • reporting, escalations

or even?

  • application support
  • ops tool maintainance
  • tasks like backup, rollback
  • qa topics?

the more you think about the more you will come to the conclusion that an active NOC can be a major advantage for your organisation and business. So, if it is not built as a technical Call Center but moch more as the name claims an operations center, than you will gain major advantages. But his means, that you need a structure and the right people, not 2 potentially not hundreds. And you need time, a working NOC is not a matter of a bunch of definitions and nice mission statements. You need role separation (dev, sys engineering, ops, noc), technical clarification and setup of the NOC itself, including processes, space, people and resources.

So what does this mean for startups?

You should potentially think about a shared NOC or think about when the right point will be for thinking about a NOC. And believe me, there will be long time no potential need for getting such an or structure up and running. Try to work based on OnCall procedures as long as possible. NOC costs money, even if there is major benefit. And a NOC requires working structures and procedures. So only start building a NOC if you are already aware of processes.

%d bloggers like this: