the missing IT and Ops strategy
It often sounds like operators – or in specific IT operators – just operate on a day2day basis independent of what’s coming from the business and where the business is going to.
In fact this is bullshit. You cannot act as an operator if you do not know where your company is willing to go to! And even you cannot operate if your IT and your IT Ops department don’t knows how to answer on the business challenge and on how to challenge the own IT department. There is difference between “headless” and strategy less. We often see organisations with strong management in terms of discipline, procedures and routines but they still fail. The reason why is not bad engineering … it is a lack of understanding that beside discipline and processes you need 2 more factors (I would not call them soft or whatever and I will not write about culture!)
- a strategy showing people there to go to
- challenge from the market
It is quite interesting to see that the less IT strategy exists the more you hear something like “we are so extra complex and not comparable to market … we have superior engineering on board …. we cannot compare to market as we have special self written applications …. the market will not understand our demand …. ” Potentially we will be able to name tons more of those bullshit arguments.
I worked a serious long time as a systems engineer with potential the same “ideas” regarding our rocket science ops platform ;-). Once I went to the CTO as he asked me to have a look at a special solution being on the market. I told him the pros and cons for about an hour and explained why this is shit. At the end he pointed out that if 1000 people think this is good solution and I think this is shit …. who will be the right one? The funny thing behind …. we used that solution and were quite happy, it was near market standards and we started to build our special ops platform market conform and got tons of more possibilities; on the economic and on the tech value!
Why this is important? The CTO had the strategy to be as market compliant as possible but staying rocket science in the business related tasks, processes and programmes. He showed us that this strategy is able to work and how the company benefits from the strategy (he did not mention in detail that engineers are easier to exchange if you use market standard hardware and software 😉 )
Next thing is that if you do not be on your own on both, organisational and technical, than you can take part on market innovation and inspiration. Mostly market will be much faster and innovative than you are, especially this should help you in the security environment. Keep an eye on being as secure as the market allows you to be. The most innovative internal solution will not help if you cannot participate in security development speed!
Let’s summarize: Have a strategy, give your people a mission, a scope and an idea of how to go forward, don’t forget to check the market and do not hesitate to accept that market is faster and more innovative than you and your department, nothing to shame on, only if you think you can be much faster as the rest of the world. Hopefully or potentially you will be able to exactly tell the “I’m the fastest” story to your business than talking about core processes, metrics and IT/business behaviour!
Ops and Movie
This post is inspired by Rita’s blogpost showing an interdependency between Coppola’s view on movie sets and organizations and how a startup or company looks like. According to Rita Coppola’s code of ethic is:
- Write and direct original screenplays
- Make them with the most modern technology available, and
- Self-finance them.
Thinking about that as a company sounds like plenty of work, quite easy and like day2day task (strategy, methodology/technology, money) thinking about that in regards to (IT)Ops looks quite harder, but think about IT Ops as a self driven (self financing) organization brings you to 100% the same situation:
1.) Write and direct original screenplays
What’s the vision of your IT Ops department, what’s the mission, which scope and borders do you have to take care? As IT Ops is an Service Fulfillment “company” think about who your (internal) customers are … and how to best reach them?
2.) Make them with the most modern technology available, and
Which technology, ops methodology and process frameworks do you need to fulfill your companies and your customers needs, compliance and security belongings? Not more, not less, within SLAs, not oversized, hypersecured or whatever, but “on the edge”, create a platform for your Ops Environment and keep on developing (use methods like DevOps to secure ongoing Ops Platform Development). Keep your system, your eco-system and your development up and running, always think about customer success and customer value than investigating in technology. Sounds easy, isn’t it. Ops business is people and stress driven “keep alive”, mostly you have no time and/or money to keep your ecosystem up and running. Step back, think about your mission and why you are there as an Ops ? The worse the situation the more pressure will be. Pressure to improve and pressure to outsource. The worse you do the more will stand up and ask why your company does operations on their own… Is it key value to the company?
3.) Self-finance them.
Mainly not your problem, you get the money you get out of your budget, some percentage of overall budget and that’s it, but: Think like a company will do… How do you want to use your money? Just to keep licensing up and running? Just to bring in 2 new e-gadgets per year to fulfill your admins needs of “the new hardware”? Can you do some strategic investment in potentially interesting trends (like trying all those beautiful clouds before your customer wants you to use the cloud?)? Even if you have your fixed budget act as a company, do IT controlling and understand, where your money goes to and whether it creates value or not. If you control and understand your finance structure you will be able to start reflecting your organization and your investment strategy. And beside that: If you know and understand your cost structure you will be in a much better for the upcoming budgets! If you can talk to an economist at his level he will understand and respect you. A Firewall will be no longer “another expensive electric toy for IT”, it will be a risk-reduction investment to secure the company’s IP and business flow…
Thinking about, Coppola can be used for both, company and standalone Ops.
Ops Predictions 2011
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 %.
External help
External help is always good … you were named as being worth getting support, you get external expertise and more work power and effort … Really? As I do external support for years I have one thing to say: If an organization cannot manage my external help than I’m not worth being paid for. An external might have additional knowledge, he might have deep market insights, he might have extraordinary experience but he/she is still a person with human belongings, acceptance, communication and coordination.
So before bringing in external support ask yourself a question:
- Is my organization ready to use them?
- How will we manage them?
- Do we have the proper security framework in place to share information and desktop with them?
- Which capabilities do we grant?
- Is it a task, a project, an interims job and how to cover?
- Do we have the proper legal framework?
If you can answer those easily than feel free to start using externals, if not think about how to best work with.
Next question is how to best find the correct partner of choice? Is it the fabulous 4 which best fit to your StartUp organization or should there an equal size between you and the external consultant company? Do you need expertise, market research or real working forces? Do you want to support your organization or stress your organization?
There are tons of external consultants out there, all of them will show you that they are the correct ones, with exactly the experience you are looking for and with tons of currently free consultants perfectly fitting into your organization and with the exact requested skill level. Isn’t it amazing?
To be honest .. yes. We often fail if we cannot deliver the right person within right time, but we have never pimped CVs to get into a company. We often – and that is the funny part – see companies failing because time is much more important than trust. If you are under pressure, why will the wrong people be the better choice? Is it a matter of hope that the person will get better during the project? Or is it a mutual failing as you were the one who decided to work with?
Another risk often seen: you start with one consulting company, you are satisfied, the company too. Your orga changes, new people take over responsibility and they bring in new (their) externals. From that on the former external party gets the looser image, everything is proven twice and people stop routing important infos to the former consultant so there is no longer a chance to work properly. A quarter later the former consultant company is out of contract and the new (buddied) one is the big star, they haven’t changed anything but they had the stronger buddy.
Think about the following: you always meet twice!
The last external help, the interims with hidden agenda. You often get asked as external to do the bad staff, firing people, reorg things like that. The longer you do the more you start reacting and healing open wounds than acting and going forward. This is what I kall the “no prisoner” mode. Nobody likes this except the one who gave you the order. But same again here: You always meet twice!
There are plenty of reasons to not use externals (costs, culture ….) and plenty of reasons to use them (additional resources, market knowhow, expertise). Always think about whether it is a permanent issue (internal) or an additional (external) one. And stay fair to you, your organization and the external partner – you always meet twice!
Paradigms change – and you?
Paradigms intend to change after a (long) while and if so it may be disruptive. Disruptive … today this is a synonym for cloud computing? Anybody out there still willing to hear that word cloud? As we know from market research we have reached the peak of the cloud hype and will go over to the desillusion phase. As we know from market, this phase is the one there business is going over from hype to business-as-usual, concepts are already on the market, early-adopters are on the solution and more than “first experience” is reached by the company. This is a very important phase because
- market has learned the working concepts
- marketing is up and running in a very efficient way
- business knows wording and more or less understands main USPs
So everybody out there knows what’s going on despite your IT organization? No, they even heard the word but for them, cloud computing is not “just another machine” it is 100% new way of working, especially for operations!
Doing so we often get the question on how to make that change happen? There is no real answer, maybe it is more a technical issue, more an organizational, more a cultural one but all time a mixture of all of them. And don’t underestimate the power of politics within the organization. Maybe some of the business-guys like to see how internal operations is loosing more and more of their former “importance”?!
What we see right now is that you – as operations – need some special phases:
- Phase 1: Know your enemy: Understand the concepts, understand their pros and cons and how to best interact and interface with those methodologies
- Phase 2: Architect YOUR solution based on your enemies one: Build your operational framework upon those solutions, make yourself (major and/or important) part of that concept and drive that concept, act as a driver, not a defender!
- Phase 3: Here we go!: You have reached your goal, business supports you, you are a brave man/woman being able to change, you are now a challenger, not a defender, you are on the edge of technology. Now do the change and make it happen
- Phase 4: Keep on running!: After the change is before the change. You did your project very good now it is time to let things run the way you want them to be. But: Market is much larger than you and your department so keep on staying on the market and on trends. You don’t need to be an early-adopter, you need to be an early-understander! Whenever the models change, your mindset should change too.
This 4 Phase methodology is neither new nor high intellectual brainwork but it can help you staying on the market, acting as a real business value driver within your organization and it potentially helps you to get the ability to reflect your organization and act based on that findings.
Paradigms changing is all time hard to understand, to oversee and to properly react. Stay informed and accept that parts of your organization may not follow you. Not all people are right for all the time and phases of an organization, this is normal business living. You should communicate very often and act very transparent to help your organization going with you, potentially this is your personal paradigm change?
The art of Ops projects
During my article about DevOps I started thinking about the way Ops projects work or should work. By doing so I came to the end that it is quite worth having a deeper look on it. In general you can differ between 3 types of projects within Ops:
- Business Projects delivering new functionality, driven and owned within Business
- Internal Ops projects, mostly new / adapted platforms, new ops or management platforms
- External Projects driven by Hardware or Software Updates, Security Upgrades and others
Doing so let’s have a look on how those projects work and what you need to deliver best:
Business Projects are – focussing on Ops – more Project Controlling and Coordination tasks than real Project Management, scope, timeline … is mostly driven by Business even if Ops had the chance to plug into that project very early. Thinking so it is very useful to have one person acting as a project coordination instance, triggering people, timelines … within ops, but not doing full Project Management, as this will fail. Thinking on that you will recognise that the Project Coordination Instance is cross functional over all departments of IT Operations, each department has to agree on time of their people being used and managed/coordinated by the Ops Project Coordinator. But it will help the Ops Manager, all his/her Head Ofs and the overall organization as projects will pass through more successfully being coordinated by one instance than being managed by the engineer itself.
Internal Ops Projects are mostly hard to cover as they are managed by engineers and, much worser, mostly don’t fit into focus of the company. To get this sorted the Ops Manager has to talk to the companies’ Steering Comitee (if existing) or communicate very early and clear the goal of the project to all related stakeholders. Remember: goal should not be the “much better” Firewall, it should be countable business value. If you are a lucky guy you will get a PM resource from another department or you have a very skilled engnineer within your department … but always keep in mind: Engineering is a skill, PM is a skill too, a very good PM engineer isn’t met that often and secondly your organization has to be able to support a PM entity (lot of you think you do but tbh PM means day2day transparency and most of us don’t like it in that detail, we often feel too genious to submit tasks and end dates and how and why we will reach that date …)
External driven projects seem to be driven easily but there is one major conflict that the release date from external will not fit within the maintenance window calendar of your organization and – much worser – the features which change don’t fit into your orga either or they potentially threaten exactly the one you use most … So keep in mind that even it looks like easy to cover you need to communicate very early and distinct to avoid later pain. Who’s doing that? In my personal view this is the only project an engineer can cover beside/within his normal operations tasks as it is mainly the most technical approach of changes within the IT landscape.
Thinking so the result is the following:
- get a project coordination instance in for all IT ops disciplines
- use internal/external PM help for larger IT ops projects if you have no extra skilled resources
- use your engineers for updating/patching if feasible and affordable by workload
Potentially you can keep on discussing and what I don’t want to mention in that article is the question about the right PM methodology for each flavour of projects or whether one would fit for all (most organizations tend to think so knowing that they all differ by > 80% …)
DevOps as the solution?
I got more and more info regarding DevOps and how good it is within the last weeks. I even started posting at some of their blogs and during my first steps I really liked it, it looked like being a good approach to keep on driving the idea of an operational platform. Nothing new, but another good driver for bringing Operations as a discipline of operating and engineering upfront.
The more I think on that the more I believe that this is just another approach and it will take a much longer time and much more approaches like DevOps to convert Operations from a barrier to a driver within tons of organizations.
You disagree? See why: In the past we have seen some very interesting scenarios. One – very long supported by all departments within companies – was to see IT operators as the barrier of truth. Whoever and however you survived talking to them ,you were a hero. Introducing new functionality was more or less incredible and they – the IT Operators – always believed that they save business’ live by acting as a barrier for innovation. Even keeping things slow was king to them.
The other typical operations department was a little bit more open as they were seen as the IT engineers unable to write code. So those 3rd class employees needed work and why not acting on the simple infrastructure basis? They really did not like Development and you know why … they developed their own style, their own culture and propably this was not the intention of the business. They tried to establish themselve as the better IT within the IT …
Those 2 artefacts really need DevOps or alternatives like our Platform Engineering, dialects of ITIL or others. The question is how to transform from barrier thinking to business enabling.
If you understand operations as the fundament of business than you definitely need strong, accepted and rich of engineers operations, not barrier minded, not 3rd class developers, not people stopping invention during mainframe area. Those will neither accept DevOps nor anything else, everything was already there and they know when and why …
Beside DevOps think more not on the tool (DevOps may be one), think on how you can transform your IT opps organization to a living one, being well accepted with good and strong communications, transparent operations and KPI willingness. By starting the cultural change you potentially will result in DevOps, but DevOps itself will not result your organization in good communications, transparen ops …
cloud reloaded
I had the chance to present some general thoughts on cloud computing on an aicooma and Microsoft event yesterday.
While being in general a pro cloud geek especially for operations I got some more hints to cover:
- scrum & cloud really cooperate well on a very high level (aicooma will present some whitepaper regarding that topic soon)
- the deeper you look at all potential hidden costs the less interesting a cloud offer looks like in the first, but keep in mind that you always have to take care on a service lifecycle perspective
- Moving from Managed Services to a real cloud offering is quite hard, on the one hand side for the moving organization to get an understanding and feeling for the cloud, on the other hand side for the partner, right now nearly all major outsourcing parties claim to offer cloud but the contract looks quite different afterwards …
- Even cloud vendors now tell the truth: a cloud will never ever fit into each setup
Dealing with that topics it shows that there is still some FUD in regarding how cloud computing could help me, my department my organization and whether it fits or not. A quite good way would be like I do in general:
- Get your service catalogue and your service portfolio up
- Include lifecycle infos into portfolio (time of reinvest …)
- take the 5 out where reinvest should occur within next 18 months
- have a very deep look (organizational, technical, financial) on those 5
- find a potential cloud substitute
- compare in depth
After doing this once or twice it’s getting quite easy to deal with, it is not that much work as it looks like in the beginning but it offers you a very transparent view on your portfolio and on the potential of cloud offerings being out and stable right now, more or less it demystifies cloud offerings and makes them compareable to your internal or external managed services like comparing apples with apples, and that’s the goal, nothing about emotions, coolness or hype, realistic and transparent decision taking is king.
I do not like requirements engineering
What’s the worst? An organization not keeping in sync. Means that if you make a decision it should be a viable and livable decision supported by you and the management and it should not be the opposite by tomorrow.
Organizations not relying on their own decisions tend to implement requirement engineering as a method to support their day-changing decision flipflops. This leads to not usable requirements supporting the political situation of today, not the strategic or tactical direction the company should go to.
If you believe in decisions and if you believe in requirements you will have a good, feasible and cost/usage driven process.
Next you will have enough management support to get good requirements out of your organization. I would strongly recommend to either differ between functional and non-functional requirements, sort them by company, division, deparmental interests and ask whether they are requirements, needs or expectations and whether those are valid for now or for 12 or 24 months.
If doing so you start moving your organization from a decision driven (“we need a new datacenter”) to a requirements driven (“we need additional space based on the current capacity plan and current architecture”).
A last short tip for your beginning: Start with KO criterias only, nothing more and if you start with those and if it is established you will be able to get into deeper requirements processing soon.
The Agility stuff
Whenever we hear terms like agility, scrum, XP, KanBan or whatever most people think like “This is cool development and innovation stuff, ops doesn’t have to care on that” NOT TRUE!!!
Whenever you hear something about a new development methodology, framework or anything else be prepared, changing developments life will change your interfaces hence your operational life too!
And better to act on interfaces than reacting. We currently do a lot of investigation on cloud, agile and how it changes our ops life but to be honest, agility drives the operational need for clouds.
Think about the following: You best act with scrum teams if you show them your boarders and limitations (aka frameworks, standards, tec. recommendations) and act as an active stakeholder with and within the scrum team. The better the teams will be, the more they will need agile resources from your ops department. Flexibility or agility can be achieved by a bunch of technologies and with different investment scenarios but one which probably fits best is reacting with cloud computing resources or highly available virtual resources (hence highly automated and “near cloud”) and provide proper feedback to the agile teams.
Doing so you will get a very high throughput within your IT organization, tons of congratulations as you were one of the very rare operators thinking in business terms and needs and you will get a very effective and efficient ops team with strict and accepted boarders. The better and clearer they are, the better your automatisation is, the better agility is supported and the better feedback will be.
If not, do what you have to do with such developers 😉
I will keep on writing about agility and cloud operations as I personally believe this is the way we will operate the next years long.
Tom Peruzzi's thoughts on digital, innovation, IT and operations 
6 comments