Cloud & Service Management blog
Branavan Ganesan 110000SGFR email@example.com Tags:  continuous-delivery devops vmworld agile 2 Comments 8,304 Visits
I am at VMWorld this week, in San Francisco CA where IBM is a platinum sponsor.
With the growing adoption of Cloud implementations, private, public and hybrid, there's clearly a desire in the clients exploring solutions here to optimize and exploit their environments rather than a maintenance and steady state approach. Therefore, it is timely that Bala Rajaraman and Pratik Gupta, two IBM Distinguished Engineers, are presenting a Collaborative DevOps session at VMWorld
The session is entitled: SPO 3304: Best Practices for Collaborative DevOps with Optimal Application Performance in VMware Environments
I sat with Pratik and Bala, and asked them what the impetus and motivation for developing this talk. The crux of the pitch, as Pratik explained to me, is that current conditions have created four drivers that a majority of customers are facing, that are making a DevOps approach an imperative.
At the heart is the desire in companies for agility. The desire in the Line of Business leaders to create value in their offerings is resulting in an urgent need for business agility. This in turn challenges the development organization to take an agile development approach. As more and more deployments move to a Cloud delivery model, it requires an operational discipline that is not always present. Add to this the human element. If you're in an enterprise shop, you know already that this is not purely solvable by software. Cultural gaps exist between the Line of Business sponsors, the developers and the Operations team. Notions of completion, priority and quality also are different.
Right now, companies are not getting this right. 50% of the applications released into production are rolled back. As much as 51% of projects are missing critical features. Quality and end user expectation delivery are clearly an issue.
Pratik and Bala will frame this problem space and then show how adopting a continuous delivery model can help address this.
Noah Kuttler 110000SVNJ firstname.lastname@example.org Tags:  cloud devops service-management apm innovate jazz storage edge 1 Comment 5,079 Visits
As I type this, so many of our customers, partners and my colleagues are in the "brutal" 88°F* weather learning more about storage and software & system innovation.
Since much of my focus is around product announcements, I wanted to point folks to the IBM Tivoli Storage Productivity Center V5.1 announcement that happened yesterday (Announcement Letter 212-189).
For content coming from the conference, a number of the marketing team are on the ground at Edge and tweeting. Be sure to follow Maria, Martha and Branavan (and of course, @ibmstorage) as well as the hashtag #ibmedge.
The Rational team have a number of exciting new announcements around Jazz and they will be talking quite a bit about mobile, cloud, industry solutions and a few other things including DevOps.
For us service management folks, DevOps translates into tangible benefits we can bring back to the business; like fewer errors and faster time to resolving errors if they do occur.
Of course, at Innovate there's a lot more to talk about with DevOps. Including the announcement from last week of IBM SmartCloud Application Performance Management 7.5 (Announcement Letter 212-143).
Along with IBM SmartCloud Control Desk and IBM SmartCloud Provisioning Manager (among others), it's about developers and testers having access to the same tools, data and information that operations uses and leveraging them to fix problems before they occur. And if problems do occur, the linkages with tools like Rational Application Developer and Rational Performance Tester allow the developers and testers to quickly resolve these issues as everyone and everything is connected.
As stated before, fewer errors and faster time to resolving errors if they do occur. This translates into using time to be productive and being innovative. Innovation is what provides value back to the business.
There's a good press release from yesterday, "IBM Expands Collaborative Software Development Solutions to Cloud, Mobile Technologies" that highlights some of the integrations and new solutions (including Application Performance Management).
The conference is being livestreamed (with video available right on the IBM Innovate home page) and be sure to follow the discussion on Twitter using the hashtag #ibminnovate and be sure to read the Invisible Thread blog for updates on what's happening on the floor.
* 88°F = 31°C.
ivor macfarlane 2700022KPS IVORMACF@uk.ibm.com Tags:  ivor itsmf devops service-management itsm itil ibm 3,440 Visits
A while back I wrote a blog just mentioning devops, and what a sensible idea it seemed – certainly the word ‘devops’ hit some bells and I got 3 times my normal hits in the first day. At the beginning of this year (2012 in case you got here late) I wrote a blog inspired by a discussion with a TOGAF fan; I felt we in parts of the IT world need to talk to our neighbours a lot more.
I was reminded of these by seeing several devops write-ups recently (separate articles in itSMF UK and US magazines in the same month). Both are encouraging and make the unavoidable point: what devops suggests as a matter of principle is clearly something to be supported like the proverbial apple pie. It is just so obvious, it has to be right - why would you not use the people who built and know a new piece of software (or anything else for that matter) to get it in place and working, and as first point of call should anything not work as expected?
Both articles argue that ITSM people should embrace the ideas rather than rush to defend their empires. Devops is not the only example, but it seems to me that what we might be faced with is set of approaches all driven from disparate firm foundations in our vast ocean of IT and services.
In fact the commonality between the approaches is massive, especially once you get past a temptation to overly rigorous application. It amazes me that the same IT people who would never dream of reading the instructions before using their new technology toys insist on applying every word of best practice.
If you want an example of how ITIL® overlaps the base devops concept look at section 6.7, page 236 of Stuart Rance’s Service Transition book in ITIL 2011.
The point I really wanted to make is that we need to get above the point of origin and see identification, creation delivery and operation of service as the real goal and the subject of some integrated guidance. Everything we have so far shows its origins.
I started my career helping organisations establish and improve services, I got sidetracked into IT and oft-times I miss that bigger image. I still find it hard to think only of IT aspects and solutions, but I find I am often talking with people – suppliers and customers – who are content to be restricted to IT aspects.
In the short term I think what we need is more selling of the neighbour’s ideas. I want to see devops being evangelised by someone from the ITSM community, and we need the converse too. Otherwise it can feel like the recommendations for apple pie are coming exclusively from the apple marketing board; doesn’t mean they are wrong but they can less than convincing, especially to a cynical audience or to one that has something they feel they must defend. Maybe I have stumbled onto my subject for next year’s conferences – anyone interested in inviting me?
 You call them methodologies, frameworks, revelations, best practices or whatever – I was searching for a generic term, if you have a better one let me know.
 In case you don't like what is there, I should point out the content of that section comes from the 2007 version, which was not written by Stuart. There is simple diagram here that makes the point, but it is Crown Copyright so I dare not use it here, so please o look if you are interested.
ivor macfarlane 2700022KPS IVORMACF@uk.ibm.com Tags:  ibm service-management itil itsmf devops ivor 1 Comment 2,644 Visits
Over the recent Christmas break, I found myself at lunch with an Enterprise Architect and the conversation turned – as it does - to the future of the IT industry. we agreed on the topic of what IT jobs and attitudes should be over the next 10 years – others at the table disagreed with us – but that’s a topic for another blog another day.
Now I live in a Service Management space, and so clearly I know that everything – at least everything about creating and delivering IT services – is wholly contained within a complete picture of service management: because everything flows from the need for the service – in terms of value conceived, engineered and then delivered to the customer.
So, imagine my surprise when the enterprise architect (let’s call him Kevin J) came out with the phrase – introduced as though it were universally accepted knowledge – that everything is contained within the concept of enterprise architecture and all other things fit inside that. Well, you would think that one of us has to be wrong – but maybe not?
Seriously though, I do realise that each of us has a coloured view of the world. But even when you know you might be, if not actually biased, at least running along familiar tracks rather than striving for objectivity, it can still be a surprise when you run into what seems a different perspective.
Of course – in this instance it isn’t really a different perspective at all. Human Beings to tend to fit external matters into handy pigeon holes – and those pigeon holes are inside our own pigeon house – service for me, EA for Kevin.
Maybe we just need to get all these different perspectives in one room and get them to agree on which view is right? I suspect, however, that this has been tried – and failed. Because it isn’t conflicting theories we are dealing with here. Instead it is that familiar old chaos machine – people and perceptions. They are all right (and all wrong too of course, but this early in a new year let’s try and be optimistic).
Trying to look at the situation simplistically, it seems to me that we have had lots of good idea over the last 20 years or so that have been helpful – but we live in a complex interrelated world and each successful approach brings you to an edge or interface where you are dependent for further success on the neighbours. Human nature makes us jump to the conclusion that if the neighbours used my approach then they would do better. Maybe it’s true but maybe it’s not – maybe we have as much to learn from the neighbours as they have from us?
Let’s analogise that to real neighbourhoods. Is there anyone who doesn’t think things would be better if their neighbours behaved more like them and adopted their processes,and practices – especially things like where it is OK to park and when it is OK to be loud? But actually they have slightly different needs (maybe because of things we don’t have like kids and dogs or a job that requires shift working) and so they do need to do things differently. But still there is much to learn from each other; simple stuff like where did you get your fence fixed etc and more strategic stuff like comparing mortgage plans or discussing the best school options.
Within our IT/services/architecture kind of world we have the same chance to benefit from discussions with our neighbours. And just like with our domestic neighbours, the best way to get along and help each other is by accepting others’ perspectives as equally valid. It is good to see initiatives like devops starting to encourage this. My major familiarity over the past 20 years has been service management but I can see both lots to learn from our neighbours like EA and development and also lots we can help with too.
Have you spoke to your neighbours recently? And if so was it with a predisposition to teach or to learn?
 OK, I am joking a tiny bit here.
 That is a deliberate singular, not a typo!
 If you don’t know about devops – I mentioned it months back in this blog https://www-304.ibm.com/connections/blogs/59c1123b-0353-458e-a719-b002d84108d5/entry/devops_should_i_have_known_what_that_is1?lang=en_us
ivor macfarlane 2700022KPS IVORMACF@uk.ibm.com Tags:  ibm ivor itsm devops itil tivoli service-management 2,218 Visits
After my last blog – asking what devops was – the idea of collaboration across the whole life of service has been in the forefront of my mind. From that wider perspective I was musing around one of my frequent topics – how we fail to get the service right because we don't understand how it is being used, or what the customer really cares about.
Actually the simple picture of supplier and customer doesn’t really describe the world most of us have to live in. If we go with the ITIL concept of a customer (someone who has financial influence or authority) then we also need to worry about what our users think. In other frameworks you might hear a more general concern about taking the whole range of stakeholders into consideration. Doesn’t matter which recipe you follow – does matter that you see the complexity.
Some of the problems come from being so close to how things are done (rather than why they are being done), and by being so close to what you think matters that you don't spot what matters to those receiving the service. Sometime it is the silliest things that make the customers and users unhappy and reject a service. Maybe that is an example of the ‘One Bad Apple’ syndrome – something firmly embedded in the human condition seems to be our ability to allow one bad aspect to overbalance a dozen good things.
I had my own version this week, when I found myself refusing to continue with an online application for a new bank account because the software insisted on spelling my name incorrectly. (For reasons I cannot fathom, it seems to have decided that any name starting with ‘Mac’ must have a capital afterwards – so it turns ‘Macfarlane’ to ‘MacFarlane’ without giving me the chance to turn it back.) I didn’t stay around to see what else the service offered, I just closed the web page and got my new account somewhere else that will let me spell my name properly.
But there is also the positive face of the same coin – the power of ‘cool’. Imagine you have found the perfect shoes for your child – scientifically designed to protect their feet while supporting their bones and they are even waterproof. As a caring parent these are the only pair of shoes you want your child to be running about in (see IKB later in this blog). As it happens your dreams have come true because your child loves them. Is it because they are good for them, and will help their feet develop properly – no, they agree to wear them because the heels light up with each step. They will wear them – and save their feet – but only because they are ‘cool’ – according to rules you will never understand. By the way, don’t think the illogical ‘cool’ factor only applies to children, it is there in just about every service you deliver or use – at work or at home. If you look for it then you will see it. I don’t want to make this posting too long or I could list dozens – but just imagine trying to sell powerful and effective software products against others with less relevant features at higher cost – but with a fancy graphical interface – sound familiar to anyone?
If you think about these two situations – where apparently less important elements disproportionately affect decisions - I am sure you will find many examples of the two extremes; like the fast-food restaurant that you still avoid because of one bad burger or one element of bad service, hundreds of miles away and several years back.
Those issues tend to come from how the service is delivered, yet the same problem can easily come from how it is built (like my name issue). But one of the differences is getting the message back to where it might make a difference, because at best the complaints go to the operations side of the house, and this does not get fed back, maybe because it is dismissed as trivial – because it doesn’t seem important to whoever received the message.
It isn’t just about hiding complaints though, we also have the ability not to pass the cool factors back. Do we always find out why people really like something? It seems to me that we don’t often ask the right people the right questions. And it also seems there are simple reasons why we do that:
Both of these situations are understandable – after all, we are human so of course we see things first and best from our own perspective, and without being forced out into another’s environment then why should we have the ability to understand people we have never met? The second is also inevitable in the complicated amalgams of customers, users, services and suppliers we exist within. Never mind the neat little service chain pictures you get in the books – it doesn’t really look that simple, it looks complicated, and mostly because it is complicated.
We can do something about these difficulties – but they require addressing the way we – and our colleagues – think, and that takes time and effort.
There are other causes and factors – and maybe there is one we could do something about, and it is something that would magnify the beneficial effects when you finally get around to addressing the two points I listed above: when we do find things out we don’t tell the people who could do something about it. And the very best way to get that wrong is to build silos within your supplier organisation and stop people sharing ideas and information.
After that last blog on devops, I was thinking about that particular kind of communication issue. There is something deep rooted in the human psyche that needs to dismantle their immediate environment into teams (or groups, or departments or silos or tribes – call them what you will). IT organisations are perfect examples – with high level internal teams always emerging once they gets past a certain size. And if you separate into teams that feel the need to compete, then helpful messages will not be fed across between them. So what was built wrong and delivers the wrong thing stays there and will be wrong in the next version too. That is the inertial element of behaviour that initiatives like devops and whole service lifecycle approaches have to contend with. We shouldn’t think it can be as easy as just telling people to collaborate and communicate. Like all challenges we need to recognise what we are fighting – and to fight back.
So – what are good ways to start? Perhaps as simply as recognising that while we might bond comfortably into (say) a ‘development’ team or an ‘operations’ team (or any one of a dozen more) – that doesn’t make the other team the opposition – I think that would be a good first step, if we can finally realise that – by and large – what benefits one team also benefits the other.
I'm not a fan of duel posting, but did want to make you aware of an article that I posted to the SWG Blog entitled, "There Will Be DevOps!"
It's about a great video that RedMonk* analyst Michael Coté did with us about DevOps.
Go there. Read the article. Enjoy.
* note that IBM is one of RedMonk's clients.