View All Videos
New IT Management / ESM podcast is worth a listen

New IT Management / ESM podcast is worth a listen

Damon Edwards / 

I just listened to Remonk’s latest podcast, “IT Management”:

The hosts are Redmonk’s Michael Cote and independent consultant John Willis.

This podcast shows real potential. Hopefully they’ll feature other voices on the show as it progresses and avoid the all too common trap of just rehashing big vendor press releases (especially given John’s deep immersion in the Tivoli universe). If they deliver on the promise of doing real analysis on the day-to-day reality of the IT Management / Enterprise Systems Management world… this is going to be a great addition to all of our ipods.

The “what is and isn’t SaaS” debate comes up again

The “what is and isn’t SaaS” debate comes up again

Damon Edwards / 

This question seems to pop back up every couple of months:

Does a SaaS relationship have to be between two different companies or can it be between internal IT and business users within the same company?

Now it’s Todd Biske and Joe McKendirck re-igniting the debate.

My view hasn’t changed much since the last time this went around. Saas formalizes and standardizes what business and IT leaders have been discussing for years. The business agrees to specific business requirements and to a minimum platform (in most cases, a standard browser). IT (or external provider) agrees to meet those requirements with a minimum SLA. How the bill is paid or what corporate entity owns the datacenter are secondary logistical concerns and not central to grasping the importance of what the SaaS model brings to the enterprise.

Nick Carr’s “The Big Switch”… the big dream?

Nick Carr’s “The Big Switch”… the big dream?


Damon Edwards / 

Vinnie, The Deal Architect, has an interesting early review of The Big Switch the latest book from of Nick “IT Doesn’t Matter” Carr. The book sounds like an interesting read and I just ordered a copy from Amazon.

Vinnie has a great take on how the reality of utility computing just doesn’t match up with the dream the pundits are selling.

My comment on his blog sums up my $0.02 on the matter:

But I would add to your analysis that the root problem isn’t scale. The problem is that the business visions have jumped light years ahead of their internal capability to “deliver”. Simply put, the technical tooling and technical processes are woefully inadequate. Poke around in how the large outsourcers, managed services providers, or even large e-commerce and SaaS providers manage their infrastructure and applications and I think you’ll be shocked at how manual and ad-hoc things really are.

A good metaphor to use is manufacturing. The business minds behind the utility computing push are talking about things that are the equivalent to “mass customization” and “just in time delivery” while the technology and process model available to deliver those dreams is little more than the master craftsman and apprentice model of the pre-Ford Motors days (or maybe an early Ford assembly line, to be fair).

There are some interesting things under the radar in the open source community like ControlTier (plug) and Puppet, but the general interest in the problem space seems to be limited to the relatively limited pool of engineers who have tried to scale significant operations and know that a better way is out there. Unfortunately most of the technical fanfare in this area seems to be focused around “sexier” things like faster grid fabrics and hardware vendor wars. In general, automating and optimizing technical operations is a neglected field.

And for the time being, forget about help from the big 4 systems management vendors. Their state of the art is not much more than 15 year old Desktop/LAN management technology wrapped with a new marketing veneer.

So this is a problem that isn’t going away soon and is a real impediment to all who don’t have high profit margins or large pools of cheap labor to throw at the problem.

“What does Bob want?” – an amusing lesson about figuring out what actually matters to the business


Damon Edwards / 

This is a great episode of Redmonk’s People Over Process podcast:

For anyone interested in systems management or automating operations this one is not to be missed. The interview is with John Willis (master independent Tivoli consultant) on the state of the enterprise systems management world.

The most impressive part is John’s retelling of his conference favorite “What does Bob want?” story. This modern business fable (based on a true story) really should strike a nerve in anyone who has been involved in systems management implementations. We’ve all heard terms like “business and IT alignment”.. but how often does it really happen? What may seem like a success to the guys in the trenches will seem like a letdown (at best) or failure (at worst) to the business leader who signed the check.

Or as the interviewer, Coté from Redmonk, puts it:
This is about “understanding what it is that the company wants to accomplish with the software, not just making the software do what it does”

Teaming with the Open Management Consortium on a Software Operations Design Pattern Repository

Teaming with the Open Management Consortium on a Software Operations Design Pattern Repository

Damon Edwards / 

After Alex’s post yesterday on the need for design patterns, he contacted the Open Management Consortium (OMC) about setting up Design Pattern Repository specifically for those who are creating Operations solutions.

Whurley (fearless leader of the OMC) liked the idea:

“Well, as you all know this is exactly how we want the OMC to operate; community lead. So we have created a new workspace under the “Open Standards” section of the website called “OMC Design Patterns”. Thanks to ahonor for the idea and for volunteering to kick things off and help manage the workspace. You can link directly to the workspace (from your blog or other sites) using the following URL:

It will be very interesting to see how much adoption this idea picks up. I for one will be participating heavily in the workspace as ahonor has a great idea/perspective that I hope others join in support of.”

Be sure to subscribe to that section of the OMC site and join in the discussion.

Where are the design patterns for software operations?

Where are the design patterns for software operations?


Alex Honor / 

In the world of software development, application developers are accustomed to drawing from the wealth of design patterns that address common programming problems, codify best practices, and establish proven reusable solutions. There are several well known design pattern repositories that catalog solutions into various categories from fundamental ones described by the GangOfFour to architecture specific ones like J2EE Patterns, even ones for social organization. An Anti-pattern is a pattern that tells how to go from a problem to a bad solution. Design patterns help avoid re-inventing solutions and when combined together can form the basis of a problem solving “play book.” When used effectively, design patterns become a common problem solving language and can lead to better written software.

But what happens after the code is written? For most organizations today, software operations – the acts of deploying, configuring, and operating software (and all of its related code and data artifacts) – is arguably as important as writing the software itself. If such an organization can’t efficiently and reliably operate the software, the quality of the software will not matter. But if one looks for design patterns that codify best practices for automating software operations, nothing turns up. Where is the catalog of design patterns that address the problems encountered when managing environments of software deployments and the overall life cycle of the business service?

Anyone that has managed software operations for different organizations, will recognize the same kinds of problems and will often re-invent solutions that were successful in the past. Others that work closer to the bleeding edge will encounter problems that other groups will face later. If these problems could be discussed in terms of design patterns (or failures as anti-patterns), solutions and best practices for managing software operations would be more consistent across organizations.

Here are two specific problem areas that everyone can identify with:

  • Packages: Depending on the application and infrastructure, one will find multiple package formats in use. Operating systems use their own (eg, .rpm, .deb, .pkg, .msi, etc) and so do software runtime environments (eg, java, .net). Each format has its own way (to greater or lesser extents) of being created, extracted, and described (including dependencies). These differences lead to multiple package silos and administrative gray areas (cumbersome handoffs between dev and admin groups). It would be preferable to have a common repository that can host any kind of package type, and a homogeneous interface to controlling their life cycle (creation, installation and removal).
  • Services: At a certain level, one can view applications as a set of interacting long running processes. Again, depending on the application architecture, these processes might be standalone unix-style daemons, or windows services. Each service has its own way of being started or stopped, as well as a procedure for checking its current runtime state. Often times, shutting down a service is not a simple matter of just invoking a single command. Things go wrong at shutdown requiring other logic to figure out the next course of action. Besides coping with these differences, the deployment process is also difficult because change of runtime state and software package installation is intertwined. Software operations would benefit from a body of design patterns that described proven strategies to managing runtime state and a common model for describing these states.

Here is a sampling of general recurring problems in the world of software operations:

  • Complex application deployments: Applications are based on technologies from different vendors, are spread out over numerous machines in multiple environments, and use different architectures
  • Inconsistent management interfaces: Every application component and supporting piece of infrastrucure has a different way of being managed. This includes both how components are controlled and how they are configured.
  • Hard to scale administrative management: As the layers of software components increase, so does the difficulty to coordinate actions across them. This is especially difficult when the same application can be setup to run in a minimal footprint while another can be designed to support massive load and redundancy.
  • Incoherent life cycles: Applications are typically multi-tiered, where each tier may be on its own development track, uses its own release paradigm and requisite tools.
  • Generally, these problems are found in combination which means coping with them on the whole is a difficult challenge.

What’s needed: Domain specific patterns for software operations


The body of existing design patterns can and should be used to analyze and solve some of the above problems. To make the design patterns more readily useful to software operations, we need a set of domain specific patterns. These patterns would be expressed in terms of concepts familiar to software operations groups (eg, package, service, process, node, etc) and would be geared to coping with typical problems they face (eg, various startup, shutdown strategies for services among many others). Ideally, these patterns can be composed into a system of patterns that help solve larger scale problems.

Developing patterns is a bit of an organic process but the most durable patterns are ones that have been proven over and over again in different contexts. The first step is to establish a repository to which various patterns can be contributed and a supporting forum where their merits can be discussed. Ultimately, the software operations community will find consensus about some of these patterns, thus establishing some common vocabulary and a basis for framework development.

External links:

Page 23 of 26First2122232425Last