Midwest IT Survival

"Spaghetti Infrastructure" can save the day!

Whether you are working in a complete custom software development shop with little vendor interaction or a technology integration shop with vendor solutions integrated with other vendor solutions on top of yet other vendor solutions, you will have to manage vendor relationships to some degree as an IT manager in a MidWestern company. This series looks at the complex arena of IT vendor management and offers some tips to make the arduous process a bit less arduous and possibly discover some additional benefits along the way.

Vendor Management Categories

• Who Owns the Relationship

In the previous article, I described aspects the vendor due diligence process and mitigating technology integration risks with a vendor prior to signing a contract with the vendor. In this article, I suggest some approaches to consider when the partnership between the business and IT is weak and a contract for services has been signed with the vendor without full IT due diligence participation prior.

Has the Contract been Signed? Yes!

Let us be honest, in a perfect world, all critical stakeholders would be engaged at the onset of the vendor selection process. A disciplined procurement process would unfold measuring and weighting all the pros and cons of each solution. Internally transparent decision matrices would ultimately reflect a cross-functional consensus based vendor selection decision. MidWest IT is definitely not a perfect world. Many factors, most not based on logic or metrics, rather emotion, drive the vendor selection process.

If the contract has already been signed, the rules of engagement are becoming established and the boundaries by which you get to interact with the vendor are becoming even more defined. Unfortunately, defined in the sense that integration expectations have already been set, but the specific details are unknown. If the contract has been signed and work has been underway for some time but you have been recently engaged, you are not going to be very popular when you pop up with:

You: “Oh, we have to integrate our technology with Vendor X to provide that? We are going to have to buy all new servers and upgrade that old version of the FlimFlam platform to 9.0! and … and …”

Budgets have been set, integration costs have been projected and expected revenues already sold to the organization. Although not popular, you have to be somewhat transparent in how the vendor integration will put stress on you and your team’s technical services and how to mitigate that stress. Yes, in my experience in shared IT services, this is a rather frequent occurrence. An effort is underway without involving all the stakeholders at the onset. As you are identified as a stakeholder down stream in the project process, you didn’t get to participate early when including your service impacts into the mix would have resulted in a more rational inclusion of your service extension needs within the effort’s requirements framework. Not to fear, there are some options to allow you to mitigate the risks to you and your team’s service.

Keys to improved success in this hypothetical example would be to smooth the impact in proportion to the usage ramp up. Is the ramp up slow enough to allow use of your service in its current configuration but plan for the next budget cycle to incorporate the purchase of additional capacity to support this service growth? The spreading of the impact to your service over budget cycles allows the initial implementation to continue as planned and essentially pushes the “problem” of the need for additional capacity to a corporate exercise that expects to digest investments in capacity to support continued growth.

Another example of improving the chances of a successful outcome without appearing to need significant unplanned investment on meeting the need is to look to leverage the ever declining cost of infrastructure. Especially with today’s service oriented architecture flexibility, is it possible to add additional infrastructure capacity on the cheap? Is there virtual capacity that you can take advantage of now and then plan to fold your virtual architecture extension back into your overall architecture direction? Are there older, decommissioned servers that, not the latest and greatest, could absorb the initial vendor integration work and usage projections and again, allow for folding back into your overall architectural direction in the future?

Yes, the cost of “spaghetti infrastructure” needs to be weighed against the benefits of architecturally separating the design, development, testing and performance tuning from your existing service. Plus, experience suggests that during the integration and testing phase before deployment, one gets a projection of the production usage pattern but rarely is that projection spot on. More than likely, there are big swings in production usage from those estimated from the integration project. Anywhere from way fewer users performing transactions to a huge spike in volume based on pent up user demand. Your “spaghetti infrastructure” investment can pay off with real production workload pattern data allowing you to strategize on a more strategic and holistic architecture that can support the current workload and this new workload. Don’t be too quick to dismiss this option as a step back on your architectural roadmap. Rather, consider the ability to gather production data as a way to strengthen your architectural roadmap.

Although a pre-signed contract and delayed vendor integration project involvement can create some challenges, consider some of these sub optimal but success trending options. The next article will dive into the MidWestern IT perspective on the topic of “Vendor Service Integration Challenges” touched on at the end of this article.