One of the most interesting elements of any research project is to have the opportunity to speak with those in the IT “front lines” dealing with the challenges of the moment. This was definitely true of the recent ADDM research, and we came away with a wealth of lessons learned. I have highlighted five of them here and will continue to discuss additional key ideas over time.
By the way, thanks for all of you who gave us interviews. You know who you are—we really appreciate your time and having had the opportunity for some very interesting discussions.
Quotes: “We had zero unanticipated impact on our data center move, which is a huge validation of the power of automated dependency mapping.”
“Anybody can build a dashboard of application components. To keep it current, you have to have a really good process in place and follow it religiously. We realized 4 years ago that we couldn’t keep our maps up to date manually—they change too quickly. We had to be able to track changes in near real time, and without dependency mapping this just can’t be done.”
2. Changes can’t always be planned—ADDM helps companies deal with the fallout of unanticipated change.
Quotes: “Our company has been bought 4 times and divested 3 times in less than 15 years, so we are accustomed to dealing with constant change.”
“We got the green light to go ahead with an ADDM purchase after we had a bad experience. A developer changed an application and didn’t inform anyone. The change impacted multiple other applications, resulting in massive disruption.”
“Management really comes down hard in those fast-moving lines of business when something goes wrong”
3. Political issues can be significant roadblocks
“When we were trying to implement change management, some stakeholders had to give up direct access to production systems. Getting everybody to agree to submit to the changes took some time. In fact, they didn’t agree until our CIO said, ‘Do it.’ ”
“We really liked the fact that all our monitoring tools feed into the vendor’s CMDB. This solves our organizational problems because we are able to keep our third-party and home grown tools at the silo level. Everybody in IT could keep their ‘babies’ and all the information is centrally federated.”
4. For many (probably the majority of) IT organizations, nobody really understands all aspects of production applications
“You can get 80% of your applications into the mapping tool in a month, because they are relatively simple. But we have 1500 applications, and the other 20% are the ones that are the most business critical. These are the large, complex applications with multiple tiers. These 20% take a lot of effort. The server to server mapping is quick. But then you have to talk to people, who often can’t or won’t identify an application or give you necessary passwords. So you have to go in search of the application owner, then find the person who knows the processes. Tiered applications may traverse banking and investment tiers, so different tiers have different owners. These 20% are time-consuming to build, and the reason why a full rollout may take months—or years.”
“Even with strong executive buy-in (and pressure), it is still hard to find the “right” people, then get 6 or 8 people in a room at the same time to “map” the application.”
5. ADDM solutions are being linked to efficiency, delivering “more with less”.
“We were looking for broad groups of applications where it makes sense to consolidate. We had forty different calendar registration applications, for example. Because of our service modeling product, we were able to identify a need for consolidation, which became a requirement for a new system.”
“This gives us a competitive advantage and allows our organization to provide higher levels of customer service. Focusing on process, efficiencies and economies of scale can make a dollar last a lot longer.”