Inspiration for writing these blogs comes from the most unlikely situations. A few days ago I was backing the car out of my garage and my daughter, in her typical fashion, says, “Daddy, can you put my music on please?” I complied and “Dem Bones” broadcasted from the speakers. You may not recognize the name of the song, but the lyrics are likely familiar: “The leg bone’s connected to the knee bone, The knee bone’s connected to the thigh bone, …” Is this not the perfect metaphor for approaching systems integration?
I’ve talked to enough technology leaders over the last 20 years to know that the words “systems integration” can occasionally be viewed as synonyms for “ballooning IT budget” and “science project”. However, in spite of the drawbacks, integration projects are well worth the expenditure of both time and money if planned and executed appropriately.
Once upon a time a common turn of phrase was “Nobody ever got fired for buying IBM”. However, gone are the days of gigantic, monolithic systems and/or vendors that control wide swaths of an organization’s IT systems. Today’s business technology landscape is moving faster than ever. Large vendors often aren’t agile enough in their product offerings to keep pace. On the other hand, deployment of technology-specific solutions for the ails of an organization creates the problem of too many tools to be managed. What’s an overworked IT Manager to do? Integrate all the tools with one another. Of course, the real answer is more involved, but we’ll address that shortly.
Integrating all your IT systems gets you closer to a single, canonical, source of information for everything. No more functional or technological silos. Sure, that might sound like a utopian fantasy. However, within the context of IT monitoring, it isn’t. Consider three typical systems you’ll find in most organizations: NMS, CMDB, and ITSM. All of these applications are designed to solve very specific and different problems. Yet, they all (likely) contain overlapping information. How much work is created when a server in the Human Resources department goes off lease? The monitoring system needs to be updated so it doesn’t send out false alerts. The inventory application needs be updated so the bean counters don’t get nervous. And the ticketing system needs the item removed so cases can’t be opened against it. How much work (and human error) gets removed from your processes if your systems are integrated?
Unlike those super-awesome tuxedo pants with the elastic waistband, when it comes to IT infrastructures, one size certainly doesn’t fit all. While it is common to find organizations that have separate applications for different functions that isn’t always the case. Some IT folks have managed to find single applications that fit all their needs. For example, OmniCenter is, at its core, an NMS system. However, it has capabilities to allow it to masquerade as a CMDB and a robust enough incident management “engine” to fulfill some ITSM functionality. We don’t recommend it for either, but it is possible and integration isn’t necessary. However, embracing an integration strategy with other tools affords you the opportunity to right size your applications so they fit your environment perfectly AND allows for flexibility down the road as your infrastructure (and technology) change.
The last aspect of integration is that it’s complementary in nature to automation. When your systems are integrated there is a higher likelihood you’ll also be employing automation strategies to keep all your systems singing from the same hymnal. Take your typical IT orchestration applications on the market today like Puppet, Chef, or Salt. Perhaps you have a Chef recipe that spins up a new virtual appliance when conditions A, B, & C are met. In such an IT infrastructure it also makes sense to include additional elements in that process. Perhaps an API call to your NMS system so the newly-added device is properly monitored? Or another API call to your ITSM application, which allows for creation of trouble tickets in the case of a service outage. In other words, once there is a commitment to integration, then automation is the logical next step.
I’ve enumerated myriad examples of why an integration strategy is a worthwhile pursuit. That was the easy part. The real question to answer is “What should be integrated within my IT infrastructure?” The answer has the potential to be very tricky, but I recommend analyzing it much like we analyzed “What” elements should be considered for automation. The “four quadrant” worksheet is a great starting point. However, there are a couple elements that require further evaluation. The first is that you must consider if a target system even supports integration. It is common to find that capability in a lot of enterprise applications these days, but it isn’t a slam-dunk. The second is that in “Quadrant 1” you’ll want to prioritize tasks that have a high likelihood of being fraught with human error. For example, the removal of a device record from NMS, ITSM, and CMDB systems. The more systems you can touch with a given integration strategy the better.
The last obstacle in our quest for integration nirvana is “How do we get there?” This answer isn’t particularly complicated, but does depend on the capabilities of your vendor mix. In lieu of actual UI elements contained in an application (i.e. “Click here to integrate with salesforce.com”) the most common way to sync up disparate systems is through RESTFul API access. An excellent tool for this purpose is called “Postman”. Combing this tool along with documentation of your vendor’s API reference will be the place to start. In an ideal world, one application has the ability to simply make an API call to another application. If not, it means rolling up your sleeves and writing some integration “glue”.
When all is said and done, the payback in terms of time-saved and reduced-human-error in your NMS systems is well worth the investment. Will it be as fun as loudly singing a children’s song on your car stereo? Probably not, but then again who knows? Request a demo today!