ISM for Design and Delivery Blog
Pete Marshall 110000HXS0 email@example.com Tags:  tivoli rational innovate innovate2011 431 Visits
Pete Marshall 110000HXS0 firstname.lastname@example.org Tags:  ism rational design_and_delivery tivoli 321 Visits
In any discussion about development-operations integration, a key question comes up: who drives it? Can the development or operations organization drive it on their own? Does it really need a top-down - CIO-level - mandate to get it done? The answer, of course, is "it depends", but whether it comes from the top or elsewhere, there's no doubt that it can't be done without having both organizations on board. It might be tempting to think that one organization - development or operations - could go it alone and at least try to do something tactical, but it doesn't work.
Cynics will say it's about protecting turf, but there's more to it than that. The bigger issue is understanding the cultural issues on each side of the development-operations divide. The best chart I've seen that explains this is here:
[If anyone knows the original author of this chart, let me know and I'll offer proper kudos here. I pulled it from a presentation at Pulse 2010 that doesn't have the speaker/author's name on it.]
We talk about different cultures, but culture come from compensation, and most organizations compensate development departments for their speed of delivery, and their operations departments for their stability. These goals are, of course, mutually incompatible.
Now in development-operations integration projects, each organization starts to bump up with the other:
What's important in these projects is to get everyone in the same boat but realize that they are there for there own reasons. One way of doing this is have each organization stick to it's strength. Instead of trying to force each organization to adapt, extend the role of each organization based on it's strengths. Bring the two teams together on the project and charter the development folks with pushing for speed, and the operations folks pushing for stability. Everyone is in their comfort zone and people feel they have control over what they hold dear. Both sides win: but more importantly the business wins.
Daniel Berg 0600006G7X email@example.com Tags:  tivoli pulse2011 ism design_and_delivery rational 1 Comment 530 Visits
IBM Pulse 2011 is right around the corner and there are a plethora of interesting DevOps sessions. I thought I would recommend a set of sessions that you may find interesting.
The Solution Expo also has several booths that you can find live demonstrations of tools that are DevOps friendly.
Come meet me either at session 1322 or at booth 21 in the Solution Expo.
Pete Marshall 110000HXS0 firstname.lastname@example.org Tags:  rational innovate2011 tivoli innovate 517 Visits
Just got some interesting news about Innovate registrations: the number of people signing up for the Collaborative Development and Operations track nearly at our internal target and, more importantly, shows our highest level of interest yet.
This is great news. The naysayers have been skeptical about the real level of interest in development-operations collaboration, and especially about the prospects of people wanting to spend time on it when there's so much else on offer at the conference.
But this is becoming more and more important. Momentum is growing. Attendance is up from last year, as it was in the parallel track at Pulse.
Should be an interesting - and lively - few days.
See you in Orlando!
Michael Rowe 110000E1VR email@example.com Tags:  integratedservicemanageme... tivoli rational devops 517 Visits
I've had the luxury of performing many different roles during my career so far in IT. In 1999 I took on the responsibility of being the level three support manager for a major application within IBM's infrastructure. While the application was not directly in front of the customer, it was critical in fulfilling IBM's year end customer orders. Prior to this I had been in development and consulting so I had a preconceived notion of what operations did. The best way I could describe it was that operations' job was to say no to all the cool things that development wanted to provide the business. I quickly learned how wrong I was.
As level three, I was still working closely with development, but I was now directly exposed to the challenges of running the business. We were the group that had to fix the production problems, while at the same time keep the next release informed of the fixes, so that we would not regress when the next major release came out. Our release cadence was twice a year - Spring and Fall. This aligned well, since from an operations perspective we needed to have year-end, quarter-end, and month end change freezes, and we also needed to have maintenance windows for things such as OS and database updates, disaster recovery tests, etc. Each one of these operational change freezes reduced the number of opportunities to introduce function to the production; however, at the time we were doing waterfall development which tended to have long development and test cycles meaning aligning releases was manageable.
Over the course of the month of November one year, we started having significant performance issues. While we were under severe schedule pressures for the next release and in year-end change freezes, this problem had to be addressed as it had the ability to impact year end sales. Our datacenter was one continent and our development teams were split over two others. In order to resolve this problem, we felt it necessary to send the support manger (me) to the datacenter to help trouble shoot the problem. Well this meant analysis of running applications, sitting side by side with production DBAs. DBAs or Database Analysts in development are a different creature than those in operations. Production ones worry about performance and the ability to backup data to keep the business running at peak efficiencies. Development DBAs are worried about the integrity of the data and the business process it supports. What this means is that to fix a performance problem, its very easy in development to add a new index to a table. In operations, this may have a net negative impact to the overall system performance and maintainability, as each update to the table may require updates to the index table. After working side by side with operations, we discovered that the application was doing ful table scans every time it hit a specific table. The code appeared to be optimized on the right the key and the DBAs were positive that an index existed to address this.
How can that be? How can a simple table look up do a full table scan every time, when an appropriate index was defined for the table? After significant testing and working with the packaged application vendor, our test infrastructure team, and the development team, it was discovered that the problem had to do with our test infrastructure not behaving the same as production when resolving the database at run time. The primary key on the table was Company_Number and Part_Number. On the test systems we had multiple companies setup in order to execute different test conditions; however, in production we only had one company setup. Therefor development had optimized the code for production, i.e. omitting the company number in the code since it was not relevant; however in operations the database required this to be in the code in order to identify the correct index?!?! Under traditional development / operations practices, this kind of problem would have lingered for months, if not releases since we would have handed off trouble tickets, declared the system working as designed, and passed it back and forth many times. Only by having development and operations working side by side were we able to resolve this in time to not impact year end.
Many companies do not have the luxury of jetting people around the world to work on production problems, nor do they have the time to wait for this to be discovered over time. They need quick and collaborative activities between development and operations, in real time. Also, in the last 10 years many development shops have implemented agile development processes, over traditional life cycle processes, in order to be respond to the quickening pace of business change. This means that operations has to react faster to this onslaught of change. As an operations group priority one is to keep the business running. Change can interrupt that, and reducing the impact of these changes requires that development and operations improve the overall flow and processes that address that change.
The Integrated Service Management blog and activities that IBM is doing around Integrated Services Management is all about helping businesses drive towards Agile operations with less risk, increased quality, and improved flexibility.
Pete Marshall 110000HXS0 firstname.lastname@example.org Tags:  operations devops tivoli change rational development 636 Visits
In recent weeks, we've been having a series of open-ended discussions with the analyst community about DevOps and especially about where this is going, or likely to go, in the enterprise.
They have all, without exception, been great conversations and, being open-ended, have covered a lot of ground. One topic that kept coming up and that people got really excited about was the potential impact of DevOps on the IT organization and where that impact might be felt the most.
(Image by Robert Couse-Baker)
The concensus answer to these two questions appear to be:
1. Very impactful (potentially) and,
2. Operations, a lot more than development.
In many of these conversations, at least one person (on either the IBM or the analyst side, I will add) would end up taking the position that DevOps was potentially a radical game-changer for IT operations, that development will end up owning most of the key operational processes (change management, provisioning, automation, monitoring etc.) Furthermore, because programming, rather than systems administration, skills will be at the center of this, the hapless operations folks won't be able to make the transition. You get the picture.
I can see this happening, albeit at a much slower pace than some people might predict or hope for. But even if you think it should happen, and happen fast, this mental model for the transformation is likely to be counterproductive. If operations people start to believe their positions, indeed their jobs, are threatened by this, driving organizational change is going to become very difficult.
A better mental (and management) model for DevOps - one that avoids parts of the organization reaching for the metaphorical torches and pitchforks - is that of collaboration. Making these changes, especially in the complex, heterogenous, legacy, environment of the typical enterprise IT shop is going to require collaboration, not confrontation. If fact the collaborative model really represents the low-hanging fruit in most organizations.
In most organizations, both development and operations are well-functioning organizations. It's the historical divide that is the issue. Erasing this divide is disruptive enough (in many businesses we're talking about a 40+ year organizational split) without throwing uncertainty and fear into the mix. Change will come, but collaboration rather than wholesale re-engineering is likely to be the best on-ramp to success.
Pete Marshall 110000HXS0 email@example.com Tags:  tivoli rational devops design_and_delivery watson ism 1 Comment 690 Visits
I was on a call with analyst Audrey Rasmussen this morning and she pointed me to her post IBM Watson - An Example of Dev Ops?. Great insight: this was hardly a case of the software guys building the application and then "throwing it over the wall" to the pSeries folks to find some hardware on which to run it. Watson is, by definition, a system.
We don't all get to build something as exciting as Watson, but there are many cases where thinking about design, delivery, and operations together - systems thinking, life-cycle thinking, DevOps thinking, whatever you want to call it - can make a major difference in the final product of whatever it is we are building.
We'll see how this pays off this evening.
Pete Marshall 110000HXS0 firstname.lastname@example.org Tags:  delivery tivoli design rational ism 483 Visits
Welcome to the Design and Delivery blog. You know what a blog is, but Design and Delivery?
Design and Delivery is one of the three key capabilities within Integrated Service Management. ISM focuses on management within the data center, within industry verticals - and across the service design and delivery life-cycle.
What makes this area so interesting is its newness. In the past the design and development of products and services has been separate from the management of those products and services after they are built. Increasingly, businesses can't afford to do that. In order to continually improve and innovate at an ever faster pace, organizations need to remove the walls between development and operations.
One of the key areas where the development-operations barrier is most obvious is in IT. The traditional division of labors between applications development and IT operations has been a feature of our business since the days of the earliest mainframes. Despite the huge changes in technology since then, that divide has remained largely in place through the decades, and it is only now that we are seeing a change in approach.
This change in approach is still in it's infancy today, but all the signs are pointing to this changing in the next 12-24 months. A new approach to managing the application and service life-cycle is starting to emerge. It's not yet clear what this new world will look like, but we're in for an interesting ride!
We've started this blog to bring together some of the key IBM people who are working in this area. We want to use this to talk about what we're doing, where we're going, what we're seeing in the marketplace and to think aloud about how businesses and IT are transforming. We're also hoping that this will become a two-way street: the most exciting times in IT and business are when major changes are happening and the industry is trying to figure out the best ways of doing things differently. It's a conversation between users and vendors, and we invite you to be part of that conversation.
Pete Marshall 110000HXS0 email@example.com Tags:  rational devops innovate2011 innovate tivoli 618 Visits
There are 2,032 miles (3,270 kilometers) between Las Vegas, where we held the IBM Pulse conference in March, and Orlando, Florida, where IBM's Innovate conference will take place between the 5th and 9th of June.
Some might say that this distance is indicative of the gap between development (the focus of Innovate) and operations (the focus of Pulse), but we are encouraging operations professionals to attend Innovate this year.
Why? Why would an operations person want to attend a developers' conference?
Why? Because things are changing. Vegas and Orlando are (hopefully!) going to stay right where they are, but development and operations are coming together. Agile has made development more responsive to business needs, and automation and cloud is making operations faster and more flexible. The bottleneck is now the hand-off between development and operations, which continues to be a fragile, often manual, process.
Better collaboration between development and operations is the key to removing this bottleneck and getting the most benefit out of both Agile and cloud. At Innovate we're dedicating a track to this collaboration and hope that we can get both developers and operations specialists to attend.
As we did at Pulse, our intention is not only to share experiences, best practices, IBM solutions and customer stories about bring development and operations together, but to encourage a dialog between these two previously-divided organizations. We hope that this will be a dialog that attendees can then take home to their respective organizations and start to discuss development-operations collaboration there.
Hope to see you in Florida.