perhaps this is a sign that development-operations integration is garning more interest in the development community than in operations. Certainly the Q&A during the sessions seemed to be deeper
ISM for Design and Delivery Blog
Pete Marshall 110000HXS0 firstname.lastname@example.org Tags:  ibminnovate devops ibmpulse collaboration oslc 566 Visits
I spent last week at IBM's Innovate conference, covering the Collaborative Development and Operations track. This track, which was jointly sponsored by both Rational and Tivoli, covered the subject of development and operations integration, and was analogous the track we ran at Pulse 2011 in February on Agile Operations.
perhaps this is a sign that development-operations integration is garning more interest in the development community than in operations. Certainly the Q&A during the sessions seemed to be deeper
than at Pulse: more focus on the how rather than the why.
seems to be one of having multiple processes inside development and operations themselves. There's no one set of processes for everything: different groups (apps, divisions, technologies (hello mainframe folks!)) have different tools and process flows. This adds another dimension to the challenge.
operations audience were satisfied with the why of OSLC, but the developer audience wanted to know the how. Now the way OSLC integration works can be a little foreign to people who have grown up with other integration standards and approaches. The unasked question in the room seemed to be "where's the data model and the shared database?". That not how OSLC works and after a healthy exchange of questions and answers, most people seemed to get it. We'll be hearing a lot more about OSLC as adoption increases.
Pete and I have been working like crazy to make sure that this year's IBM Innovate conference is full of content around Collaborative Development and Operations. The interest in this topic has been amazing. We have almost double the people signed up for the track then we thought we would get.
Customers and Business Partners will learn all about what IBM is doing to help drive Collaboration between development and operations. But not only that, we will include many demos on the expo floor and will wrap up the conference track with an open discussion. So if you are coming plan on staying thru to the very last session. We want to talk with you!
See you in Orlando!
Michael Rowe 110000E1VR email@example.com Tags:  ism service-managment innovate devops 497 Visits
As we get closer to Innovate 2011, I've noticed that many people may not know what a day in the life Service Management. To that end, we have a simulator at the conference that you could attend and figure out what they heck we are talking about. My collegue Noah Kutler has a great blog entry on it over at The IBM Software Blog. Go check it out and let me know what you think!
Pete Marshall 110000HXS0 firstname.lastname@example.org Tags:  rational innovate2011 innovate tivoli 478 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!
Pete Marshall 110000HXS0 email@example.com Tags:  tivoli rational innovate2011 innovate 389 Visits
Pete Marshall 110000HXS0 firstname.lastname@example.org Tags:  operations devops rational change tivoli development 601 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:  rational devops innovate2011 innovate tivoli 579 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.
Pulse was great this year, and while I believe many enterprise customers don't yet grok this space, there was plenty of positive experiences from Pulse. I think Dave West caught the message with his blog post on if you build it, they may not come. While we have seen increased interest in this space, the numbers are not yet what you would think they should be. It can be tough to attract people to something that many would consider new.
Personally, I don't consider DevOps a new idea. As a developer, operator, and support manager, the basic tenants of DevOps are things that I've been trying to realize for 25 years. It's about allowing the business to accept change with minimal risk. In the enterprise we don't write code just for fun, we write code to help solve a business problem. We don't try to keep production stable because of a SLA, we keep production stable so that the business can function smoothly, minimizing risk to revenue. In support, we don't just tell you to turn it off and back on again, we try to find and fix problems. Net, the reason we focus on DevOps is because it is the right thing for the business...Period.
Reading a lot of blogs lately, and looking at what people are saying DevOps is, most people assume that DevOps is primarily Automation. I challenge this. DevOps is about business results. It is about how we can improve the way the business is run. It's not just infrastructure coding. When I started my career in IT, I remember the role of the Systems Programmer. This is probably the nearest analog to today's infrastructure programmers. These programmers have real-time access to production, and unlike application programmers, they get to deploy code whenever it is needed. (I guess deploy may be too strong of word, as some of them are actually just changing things in production.)
I would love to hear what you think DevOps means? Does your company use DevOps?
Michael Rowe 110000E1VR firstname.lastname@example.org Tags:  architecture deployment 1 Comment 571 Visits
A few weeks back I talked about how complex deployment planning can be when dealing with enterprise level packaged applications. We have been working solutions which address this in a manner that recognizes that almost no company starts from scratch anymore. We all have a history of applications which are in place running the business. In order to evolve this infrastructure of applications, you need to understand what you actually have running in production. Tivoli has had an offering for a long time called TADDM - Tivoli Application Discovery and Dependency Manager. This allows you to have a detailed understanding of your AS-IS environment.
As an enterprise architect understanding your production environment is key to developing a roadmap and action plan for transformation. Rational Software Architect (RSA) can take the information identified in TADDM and use this as a starting point for modeling your next release of an application. This modeling in RSA will also identify dependencies, and define architectural constraints, such as never have your application server running on the same server as your database server. By doing this, you are ensuring that your business's best practices are being enforced for deploying new functions. These models can then build deployment packages which are consumed by Tivoli's provisioning manager (TPM) for automating the rollout of new functionality. By automating this functionality you not only ensure that the right steps are followed each time, you also gain the ability to quickly stand up test and performance environments which can be used by developers and testers to validate the new functionality.
We will be showing this capability in more detail at Pulse next week in Las Vegas, come check it out! Session 1322.
Daniel Berg 0600006G7X email@example.com Tags:  tivoli pulse2011 ism design_and_delivery rational 1 Comment 508 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:  tivoli rational devops design_and_delivery watson ism 1 Comment 643 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 email@example.com Tags:  ism rational design_and_delivery tivoli 286 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.
Michael Rowe 110000E1VR firstname.lastname@example.org Tags:  innovate2011 pulse2011 ibmpulse ibminnovate 491 Visits
If you are coming to either Pulse or Innovate we would love to talk with you about Integrated Service Management. Both Pete Marshall and I will holding a birds of feather session at Pulse in Las Vegas, and a panel discussion at Innovate in Orlando. We would love to talk with you and hear your experiences with ISM.
Michael Rowe 110000E1VR email@example.com Tags:  deployment architecture integratedservicemanageme... 535 Visits
Let’s think about moving code into production. I don’t mean just the idea of code promotion within your SCM, but how packaged applications may impact the complexity of your development, test, and production environments. This complexity can decrease a business’s ability to react quickly. This can inhibit Agile Operations. By addressing these barriers with Deployment Planning and Automation, you can reduce complexity, reduce risk, and increase your ability to respond to the demands of the business.
I don’t want to provide a theoretical example, what follows is an actual example from work I used to do some years ago as the architect for a major reengineering effort within IBM. We were implementing a popular packaged application, and as part of the recommended application management system, we needed to have at least three environments - Development, Test, and Production. This would be fine for a small company with minimal required changes to the package, but we were working a worldwide rollout over multiple years and multiple releases. Our infrastructure requirements were a bit more complex.
At any given time we we had at least three level of development going, due to our waterfall development approach. The packaged application required that all objects in production originate from the same system. In the above example this would be 2 releases ahead of what was running in production, unacceptable. Also, all changes had to be applied in the sequence they were created to ensure that you didn’t back level any code. This meant that a roll back of a function was actually not just a simple, apply the prior version, but a create a new version which reflected the release prior to the current change. Talk about complexity!
While you can understand from a packaged application perspective it makes sense to have a true system of record, this does not scale with complex deployment architectures. Nor does it scale when teams have to handle multiple releases at the same. This requires a modern source code management system.
The second challenge that the above deployment architecture caused was that for each release a set of presentations were made to reflect the connections between this application and other applications within the architecture. These deployment architectures were at best a picture of how all the applications, pre-reqs and co-reqs, databases, operating systems, etc. needed to be installed and configured to achieve the desired operational environment. To put it mildly they were wrong, at best. We would have to have multiple meetings, and test runs to wring out all the problems and ensure that we could perform our quarterly move to production weekends.
This does not scale in the world of Agile development, where teams are providing many, small, incremental updates to production monthly, weekly, daily and some times even hourly! What is needed is a governance and tooling environment which supports this level of change, without delivering unacceptable risk to the production environment. I’ll describe this in my next blog entry.
Michael Rowe 110000E1VR firstname.lastname@example.org Tags:  integratedservicemanageme... tivoli rational devops 506 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.