Years ago when I covered application management and saw the rise of J2EE-based applications, I was initially surprised that my client inquiries for tools and best practices with regards to Java management were coming from development and application support teams.  It was déjà vu all over again with SOA. Today, of course, we have REST, EDA (Event-driven Architecture), CoDA (Context Delivery Architecture) and other application paradigms that just seem to add fuel to the proverbial management challenge fire.  And why were application developers calling and not traditional IT operations?  Well, the latter weren’t sufficiently skilled in terms of support at the time, and this can still be true today – especially for these emerging application types. 

So the thought is this … quit fighting natural selection.  Developers (or application owners) know more about the application than others within IT so they should be the rightful management owners as well.  I’m not talking about traditional level 3 style activity, but ALL management.  I know the argument against this which is that an expensive resource like a developer should focus on their core competency and only be engaged with problems at the last possible moment, but I ask you the reader, how successful has this posture been?  We throw applications over the wall to operations and somehow we hope that those less knowledgeable about the architecture will sometime in the future be able to management it effectively.  This is not a criticism of IT operations capabilities because they are already extremely busy having to deal with substantial infrastructure change in the form of virtualization, cloud computing, etc.

And speaking of cloud computing, for some cloud and Internet services providers this wouldn’t seem so unusual as some already require heavy instrumentation of their applications and operate under the mantra of “you built it, you manage it  (see On Designing and Deploying Internet-Scale Services).”  They (as does Gartner) believe also that most operations-related issues have their origin in pre-production (note: the research paper by James Hamilton has many other valuable lessons in it that I’ll return to periodically).  For me, the question isn’t so much should application development assume management ownership, but “how low should they go?”  The recent acquisition of SpringSource by VMware I think will further blur the line between infrastructure and applications adding even more impetus to a re-evaluation of how we’re currently structured within IT. So, let the debate begin.

[Danger: I'm about to show my age] I remember years ago when I was at IBM trying to enable a port of the DEC VT-100 protocol to an IBM 3090 class mainframe for one of my clients (we were trying to dislodge those pesky, from our perspective, DEC/SNA gateways).  Can you say performance problem?  We did the right thing and ultimately canceled the project but I’m sure some of the sales folks looked wistfully upon the lost mainframe cycles that might have been sold.  I share this though as an example that there are certain environments that don’t blend well with mainframe architectures.  

But for the moment, let’s assume the overhead is manageable and that there are no issues with remote protocols, etc.  Is the mainframe the right place to do this?  While still expensive in nominal terms, the latest z10 IBM server and associated specialty engines (IFL, zAAP and zIIP) seem to be changing many traditional notions about mainframe costs (and capabilities).  I seem to recall studies suggesting that power consumption may also be increasingly a winning argument for mainframes.  And of course when it comes to security, the mainframe is often the bar that other systems alternatives aim for.

So, there may be a plausible case for this – at least among existing mainframe customers.  Still I am concerned about one thing that in my traditional virtualization coverage I heavily focus upon – support (and related to this, complexity).  It’s no secret that skills availability for mainframe support is starting to become an issue as many of these traditional administrators near retirement age.  And of course, even with skilled operators the mainframe can be complex to manage – although managing a distributed UNIX or Windows server farm isn’t necessarily for the faint of heart either.  All-in-all, it’s an interesting announcement and we’ll have to continue to monitor Mantissa’s progress. 

• Energy saving solar technology will be built into asphalt, paint and windows
• You will have a crystal ball for your health
• You will talk to the Web . . . and the Web will talk back
• You will have your own digital shopping assistants
• Forgetting will become a distant memory

What was I writing?  Oh yes … whew, glad that the last innovation listed will materialize (and not a moment too soon for me)!  I wish the IT operations management market was as exciting as some of these but that shouldn’t prevent us from developing our own list.  Here are my "Five in Five" predictions (but not necessarily innovations) for the IT operations (and enterprise) management industry:

• We’ll still be playing catch-up in trying to manage the "new, new" thing in terms of infrastructure technology innovations
• Overall, our management tools will remain too expensive and difficult to support
• There will still be a continuing struggle to straightforwardly link many of our management product investments to improved business performance
• Operational best practices frameworks will continue to be easy to conceptualize but hard to implement
• The organizational structure to optimize the management of an increasingly complex environment will remain elusive

A bit pessimistic to be sure, but given that we often seem to be only focusing as an industry on the "low hanging fruit" reinforces my less than sunny perception.  Anyone else care to provide their predictions?