Optimize IT

4 Posts authored by: Jody Hunt
Share: | mark of a mature IT organization is effective change management. But all too often, updating change records is a neglected data entry chore undermining the usefulness of the change record and raising the spectre of audit failure. To combat this, some of our automation solutions support a feature called "operator initiated change" whereby a Remedy ticket is automatically opened, updated and closed as part of making administrative changes. Role-based access control ensures the person making the change is an authorized administrator, so they are relieved of the tedium of updating the change ticket. Having changes require approvals means a solid record of authorized changes is ensured. This works because the operator never has to change their focus from system administrator to Remedy user, in effect never changing their persona,


A persona-driven approach is the essence of closed-loop change management because it allows someone to stay "in character" while making changes and automatically updates the change record to accurately reflect real-world state. Software development has its own system of change tracking for enhancement requests, defects, etc.and persona-driven approaches to closed-loop change management is an objective there too.


The DevOps trend has focused attention on improving the overall application change cycle (the DevOps Cycle). We at BMC are now taking a persona-driven approach to change management during the application release process. Planning and performing tasks during the release process automatically update change records as those tasks are executed (successfully or not, especially not). As a result, change records contain detailed results of task execution. We record not just operational changes but correlate those changes with the software development changes that are represented in the release (i.e. this deployed application went through these pre-production stages, corresponds to this ITSM change history, contains fixes for these defects and supports these user stories).


This achieves a complete "chain of custody" for the deployed application and connects CMMI with ITIL change disciplines. It provides forensic information for application support personnel should an issue arise, satisfies auditors and delights compliance officers.


Closed-loop change management in the application release process closes a huge part of the gap between Dev and Ops.

Share: |

About 10 years ago I was working for a company that had a product that, given a WSDL interface specification could generate a simple J2ME client to test it. On a hunch, I expensed a Nextel/Motorola handset, registered with the Motorola developer network and downloaded the WSDL for a service on the open internet. You gave it a zip code and got back the temperature at that location. With a bit of hacking, I loaded a J2ME client on the phone, entered my zip code, and waited, and waited, and about decided it didn’t work when the 5-line amber screen displayed “52”. It worked! We demoed this mobile client application at JavaOne that year with the admonition, “this is a new computing platform, take note.” But it was very early. The CPUs were way slow, memory measured in K, small monochrome text-only screens, short battery life and laughable bandwidth.


Fast forward 10 years. We have 2-core CPU mobile devices that run Linux (some can make phone calls), gigabit memories, hi-res color screens, batteries with enough juice to last all day and access to ubiquitous high-speed networks. The vendor strategies for these platforms are familiar: the manicured, walled-gardens of Apple (no surprise) and Microsoft(!) facing off with the wild and open Android and RIM platforms - newcomers that welcome all apps, caveat downloader.


Enterprise IT departments are scrambling to support these new platforms. They first try to limit support to one vendor/model. This effort is short-lived because users soon demand other platforms. In fact, they want to use their personal devices to do their jobs. Users like mobile applications more than browsers. Their internal application development departments are starting to deliver apps for these mobile clients.


This “App Internet” (Forrester term) is quickly supplanting the thin-client Web architecture on mobile devices. Suddenly, the Client is the thing again, augmented by (but not always needing) the Server to enable employees to do their jobs with a rich user experience, anywhere.


Do Enterprise IT departments need a single management platform to Provision, Configure, Monitor and Operate these heterogeneous mobile client platforms along with other IT environments? Absolutely. But with mobility, there’s much more emphasis on managing Apps, and less on managing platforms.

Share: |

Driving home last night, listening to Marketplace on NPR I heard the attached segment about making improvements in managing the food supply chain. As it went on I thought, "I wish all BMC could hear this" because the food supply chain is an apt metaphor for the application release process. Consider:


  1. The primary business driver is Time to Market - the "produce" can't be delivered too quickly
  2. UNLESS hasty or sloppy delivery processes contaminate the product or fail to remove contamination.
  3. The product changes hands frequently and covers a lot of distance.
  4. The earlier contamination is detected, isolated and removed, the less costly it is and the less negative impact it has on the market.
  5. Current practices are manual, ad hoc and ineffective.
  6. Regulatory compliance is mandating changes to current processes.
  7. The solution is a combination of logistics, automation, human workflows and end-to-end traceability.
  8. IBM and Microsoft are getting in the game, but they aren't the innovators in the space.


Please take 4 minutes to listen to the attached segment and:

  • when you hear a reference to produce, think "application"
  • when you hear "contamination", think "configuration error or application bug"
  • when you hear "people gettng sick and dying", think "major service outage"
  • when you hear "market" think "data center"
  • ...


you get the idea.

Share: |

DevOps describes the cultural mashup of Development and Operations
to address the Application Service Delivery bottleneck.

In Boston last week, the first DevOpsDays event of 2011 was held. Two days later at the CloudConnect conference in Santa Clara, there was a DevOps and Automation track.


Perhaps you’re asking yourself, “What is this ‘DevOps’, and what does it mean to me?” So glad you asked.


With Agile methodologies and Java application servers, Development is producing application changes faster than ever before. Those changes go through a release process, at the end of which Operations deploys them into Production. With cloud and web-based platforms, Operations can instantly deploy application changes and users will see those changes as soon as they refresh their browsers.


With Development producing changes faster and Operations able to make them available almost instantaneously, the release process in between has become the time-to-market bottleneck. Relieving this bottleneck is complicated by differences in professional cultures. Operations sees Development as cavalier about operational discipline; Development sees Operations as inflexible, imposing processes and approvals that hinder productivity. When things were simpler this culture clash was not such a big deal, but increasing change rates and greater environmental complexity have created real business issues around the delivery and stability of application changes. This is why Gartner is reporting a sharp increase in inquiries around application release solutions.


Some of our customers process over a thousand application changes per week and run their applications through nine different testing environments. The backlogs are becoming unacceptable. Operations must often borrow developers to assist with deployment and configuration, detracting from Development’s productivity. Detailed documentation must be written, tailored and updated - for every application, and for each environment between Development and Production. Without an Application Service Delivery strategy, the release process is labor intensive, time consuming and error prone. It is mission critical work that must be done by expert administrators who are doing their best with generic, ad hoc tools like command line interfaces, scripts, paper documents, spreadsheets, email, conference calls and instant messaging.


DevOps describes the movement to create a cultural mashup of Development and Operations to address the Application Service Delivery bottleneck. Development must produce applications that are more easily deployed and configured. Operations must become more agile in their workflows. The whole release process must be coordinated end-to-end as a symphony of activity that includes change management, human workflows, automated tasks and configuration data management.


For more on DevOps, check out the Dev2Ops website.

Filter Blog

By date:
By tag:
It's amazing what I.T. was meant to be.