View All Videos

Archive for February, 2008

CIM, APML, SML, CML, SDM, MOF, CMDBF, WTF??… Users aren’t buying vendors’ alphabet soup

CIM, APML, SML, CML, SDM, MOF, CMDBF, WTF??… Users aren’t buying vendors’ alphabet soup


Damon Edwards / 

Every year there seems to be a rash of IT modeling standards proposed by vendors like Sun, Microsoft, IBM, Oracle, BMC, CA, et al. They primp, they preen, they puff out their feathers as they jocky for position. But the comedy (or really, the tragedy) of the situation is that they are competing in a race that none of them will ever win. Especially if they stick to their current belief that they can find one true industry-wide model to rule all of enterprise IT. How many times do they have to launch another vendor-driven standard to a resounding thud to get it?

The plain fact of the matter is that end users just don’t care. They want tools that just work and simple frameworks that they can quickly compose into a solution that fits THEIR operations. They want their IT management problems to just go away, not become a new center of the universe that requires an increasingly diverse and complex set of skills to master.

Although I’m a firm believer that the best solutions in IT management must ultimately be model-driven, I also am well aware that the industry has done a terrible job educating users as to why they should even care about modeling in the first place. “Tool interoperability” is the only answer that is consistently given. But tool interoperability is something that vendors care far more about than end users.

Your average systems management jockey is smart enough and skilled enough to cobble together tools as needed. Sure they would like a smoother answer, but not at the cost of pulling a big modeling headache down on top of themselves. This may not please the IT Architect types… but it’s not the first time that they’ve been ignored by their own overworked rank and file whose paychecks depend on getting things done as quickly as possible.

A fun illustration of the absurdity of the standards alphabet soup took place on a recent episode of the always enjoyable and informative “IT Management Guys” podcast.

Host Michael Cote (a RedMonk analyst) and guest William Vambenepe (a well respected vendor representative from Oracle by way of HP) get into a discussion of current standards efforts and how they relate to other recent standards efforts. Of course,those who follow these things will recognize that these standards have gone absolutely nowhere with users in the wild.

The acronym fun begins about around the 8 minute mark and things really go off the rails around the 15 minute mark. It’s a fun bit of unintentional comedy to hear it. All are very bright guys who really know their stuff and have my upmost respect, but it’s just classic to hear an analyst and a vendor jump from acronym to acronym and throwing around modeling and language concepts all while the other host, John Willis, who represents the cream of the crop of actual in-the-trenches IT Management consultants, sits in stunned silence.

John’s quote to snap them out of it is priceless:

“Just give me something that I can go and manage ESM [Enterprise Systems Management] or do IT management!”

Amen, Brother John.

Side note: Cote also retold a fun little joke that a guy named Chip Holden from BMC likes to tell…

“People ask me what I do and I tell them Programming, and that puts most normal people to sleep. When I’m with Programmers I tell them I work in IT Management and THAT puts them to sleep.”

It’d be funnier if it wasn’t sadly true.

Why the crack(berry) stopped working… and counting down to the next outage.

Why the crack(berry) stopped working… and counting down to the next outage.

Damon Edwards / 

The WSJ is reporting that yesterday’s Blackberry outage came during an “expansion of their network operations center” due to service growth. That sounds a lot like RIM spinning the outage so Wall Street hears: “hey, we are growing like crazy so please ignore the fact that we’re a communications company and cut off most of our US customers for the better part of a workday”.

This was RIM’s second major outage in less than a year. Surely the media will place a big portion of the blame (as they previously have) on RIM’s highly centralized hub-and-spoke style architecture. But I hoping savvy tech readers will realize that the redundancy issue is a cop out. Blaming the lack of a safety net doesn’t change the fact that these failures are caused by poor change control and ineffective processes.

This isn’t exactly an uncommon problem. Many popular services are able to survive deployment screw-ups with various forms of a brownout, enabling them to play fast and loose with “uptime” statistics. But why is that even tolerated?

Until the discipline and science of operations is discussed openly and freely within IT communities as it is within mature industries like manufacturing or energy, I really don’t expect much to change. Money and goodwill will keep hitting the floor and CEO’s will just scratch their heads and shrug at the convoluted excuses offered up by their IT organization.

Built for operations

Built for operations

Damon Edwards / 

A big piece of solving the development to operations problem is convincing developers and architects to design their applications with production operations in mind.

Randy Shoup (Distinguished Architect from eBay) gives an interesting presentation that shows how eBay has done just that:

(And he puts his points in design pattern format!)

Edit: Michael Nygard’s book “Release IT!” also does a great job of covering the topic of designing operations-ready software. It’s a great addition to your bookshelf if you don’t already own a copy.

CodeData Split: New OMC Design Pattern

CodeData Split: New OMC Design Pattern

Alex Honor / 

One everyday source of confusion seen during the dev to ops handoff is the necessary modification of files during the installation and setup during deployment. Typically, there is one or more modifications to configuration files that enable the software to work in the context of the target environment. The process can be greatly improved if these files were split away from the executable software code itself. I describe this best practice as the CodeData Split:

Separate executable software files from environment specific deployment ones, identifying files that change during installation or operation, thereby facilitating cleaner upgrade process, and the ability to manage deployments independently and separate from each other.

The concept of splitting code from data in applications is nothing new and examples can be found ranging from OS filesystem structure and application servers. The pattern emerged in those places because the operation of the software was a clear requirement so this led to the data files (both configuration and variable data files) to have their own places. This best practice should be followed generally for any application. Doing so will avoid problems like the Service Monolith