Once upon a time, when AS/400s roamed in vast herds and S/390s ruled the roost, just about all of IT was homegrown. Vendors didn't have "solutions" -- they had platforms, and you customized them to fit business needs. Applications were written from scratch and tightly linked to business needs, with infrastructure sized and configured to match.
Today, we live in an era of homogenized, vendor-driven solutions that plug into existing infrastructures and are lightly customized. In the battle of build vs. buy, buy has won, with plenty of extraneous cruft carried along. This holds true for both hardware and software.
[ For best practices on how to set up remote monitoring and control systems to begin with, see Paul Venezia's, "Troubleshoot your data center from the easy chair." | See if you match this profile: "Nine traits of the veteran Unix admin." ]
The main reason for this shift has been the explosion of technological diversity. Where there was once a mainframe, green screens, and printers, there's now a wide palette of client access methods, networking, remote connectivity, security, storage, server infrastructures, virtualization, and so on and so forth.
Back when IT was "simple," several good programmers and support staff could run the whole show. Nowadays, it's difficult for smaller and midsize companies to justify keeping subject experts on staff for every part of the infrastructure. Instead, they buy hefty support contracts and shift the burden of maintaining and troubleshooting large parts of their IT infrastructure on to the vendors who may know their own product well, but have a hard time dealing with issues that may crop up during integration with other vendors' gear.
Essentially, moving to this model creates silos around the major components of IT, with a vague understanding of how the whole thing works together. This is where many companies find that their IT people spend a majority of their time sitting in meetings discussing problems with vendors on conference calls rather than actually researching and fixing the problems themselves. In those cases, the local IT staff can seem like little more than caretakers -- they don't have mental ownership of their own environment.
