The Realities of Single Panes of Glass

The folks at Virtualization Tech Field Day 2 were tweeting about single panes of glass (I think they were playing buzzword bingo) and reminded me of my feelings on the topic.

I’ve never thought a single pane of glass was all that special, or necessary. Once upon a time, when I was the IT guy for a small environment, I never used them because I didn’t feel like dealing with the hassle of tying everything together, arbitrarily creating dependencies and unnecessarily complicating my life. Now, as an “enterprise” guy, I can’t use a single pane of glass to see into my storage, network, backups, etc. because of the politics & silos with the storage, network, and backup teams. And even if the politics weren’t there I still wouldn’t use a single pane of glass, because I don’t need more complexity and dependencies in my systems. I want to remove interdependence & complexity, not add more, and every time one product touches another it opens the door for support finger-pointing, and causes lag & drag as I wait for support matrix updates, certifications, qualifications, etc. Have enough products touching each other and you find you can’t move forward at all.

When it comes right down to it, I think a vendor is better off spending time making their interface solid & highly usable than trying to integrate it with everything else. A good example of this is Veeam, where they’ve decided that a full-featured Windows client for their Backup & Replication product is the way to go, rather than making a half-assed web interface that “integrates.”

Single pane of glass? Great idea on paper, but never works right in practice.

4 thoughts on “The Realities of Single Panes of Glass”

  1. I’ve been part of teams building IT management software for over a decade, and customers frequently ask for the single pane of glass. In wrongheaded attempts to satisfy that request, I’ve been part of product teams that mash together really different UIs meant for different users, leaving just sad frankenware at the end of the dev cycle. At my current company, SolarWinds, we get the “single pane” request a lot, but our philosophy has been to try to focus on specific use cases where integration of two products will solve a specific problem for a specific user. For instance, tightly integrating bandwidth monitoring and traffic flow analysis makes sense because they tackle different parts of a problem that a single user might have.

  2. Just to chime in on this, the end goal has to be about providing solutions to peoples problems so that they can get their job done on time and on budget. The more we understand our customers and the jobs they are trying to do the more successful we will be in providing solutions. There is no getting away from the fact that sometimes single pains of glass are needed to solve some problems, however they should be transparent to the user and not hamfisted together.

    Its interesting that this conversation started at a Virtualization tech field day. Virtualization has seen the lines blur between network teams and server teams, this has meant a slow movement away from silo based management to a more integrated approach of IT management where teams are now being tasked with providing a full service rather than providing one piece of the jigsaw, hence customers are now requiring more “single pains of glasses” to reflect this change.

Comments are closed.