Sunday, February 13, 2005

Who Manages J2EE and .NET Applications in Production?

We all talk about "Application Management", and at least some of us claim to truly understand what it is and how to do it properly. But putting aside the technologies, processes and all the hype surrounding the space, I want to raise a seemingly-easy question: if applications are being managed, it means someone is managing them. That's simple logic. In the application delivery phase (i.e. when the application is designed, developed and tested), the owner would always be the person running the application group. But when a home-grown application gets deployed into production, the picture becomes considerably more blurry. Traditionally, we have seen application development groups throw applications over the wall to the IT operations folks, who would then take over.

But how does this work with new distributed applications?

Well, I would claim that it just doesn't. Why?

Today's applications are incredibly complex. That means that no matter how good your testing team is, problems are imminent. Now can the average IT operator (a probable master in handling hardware, OS, network, firewalls, anti-virus, backup software and more and more) even begin to analyze a problem in an average J2EE application? I seriously doubt it…

What does all that mean?

Simply put, it means "developer power". If a J2EE/.NET application breaks, it would take a developer (or a developer-type of person) to fix it. How does this work? Some of the more advanced organizations that I've 'worked with have created a dedicated task force, sometimes referred to as "application support". This is a team of highly-skilled developer-level professionals who live and breathe the production environment. When the application runs slowly or crashes, they are there to fix it. Other organizations are attempting to bridge the gap between operations and development through process re-engineering and a bunch of new technologies. The other 90% are in trouble…

And what does the future hold for Application Managers?

Traditional walls will continue to fall… we will see a lot more application expertise in production, substantially increased cross-team collaboration, and new technologies to make this happen.

0.7999 probability :)

Thursday, February 03, 2005

Welcome to my Weblog

Welcome to "Thoughts on Application Management", a blog dedicated to the space of Application Management.

What is Application Management?

Princeton University's definition of "Management", which I found less than enlightening, is "The act of managing something". Thereby, Application Management can be described as "The act of managing some applications"…At the risk of excessive disparagement of Princeton’s term, anyone who has ever managed any “something” knows that it is a “process” not an “act”. Therefore, at its most basic, Application Management is the “process of managing some applications”.

There probably isn’t a less well defined and understood discipline than Application Management. The definition of this space really depends on who you ask (and possibly what mood they are in). Application Management encompasses a host of technologies and processes that revolve around business applications. These include application SLA measurement, application monitoring, user experience monitoring, application security, application configuration, application deployment, application mapping, and more and more. The one thing all disciplines share in common is that they all have to do with the very simple goal of "making applications work and work well”.

Why write about Application Management?

As with anyone who starts a blog, I have a passion about it. I find it compelling that G2000 companies have between 500 and 1000 applications, some of which are incredibly complex, supporting their critical business processes. The risk, the vulnerability is amazing. Yet, the processes for managing those applications haven’t evolved much since the mainframe days (when it was really a walk in the park).

I spent a good part of my professional life working for Mercury, a company that made a fortune by telling people (testers in those days) that problems exist. I then started working for companies that help people (primarily developers) figure out why problems exist, and how to fix them.

So, covering both ends of the equation, you could say I've been dealing with Application Management for little over 14 years – working with customers on their real issues, talking to analysts on their perception of the space, and collaborating with other software vendors to provide integrated solution stacks. Hence my passion. Hence this blog.

One last comment: I'm currently working at Identify Software, a company that pioneered the Application Problem Resolution space. This blog represents my personal opinion, and does not necessarily reflect the company's viewpoint.