Today, I am struggling with explaining to stakeholders that they need to pay for capability integration into systems. I deal with a lot of situations where a number of computer and network elements have been cobbled together to just get to a minimal functioning capability, but no more. As soon as that state is achieved, they all immediately begin asking for each of these disparate elements to function smoothly and intimately in a finely tuned integrated system. Unfortunately, they usually do not want to commit additional or significant funds to create that seamless, integrated environment. As a professional systems engineer, I find it very hard to explain. The best that I can come up with is that there seems to be a prevailing idea that you can herd cats without paying any cat herders.

gears

So I turn to you and ask, how do you determine the cost for integrating software solutions on your network? What is return on investment (ROI)? How do you show and demonstrate it. It is like paying for preventative health benefits, right? You only know what you spend, not what you would have spent to fix the maladies if you had not! As far as I know, there is no way to prove what the opportunity cost was for a lack of integration funding. Do you know of any?

I went online and did some searching and found two good articles on the subject. I recommend them to you for thought:

“So Many Tools Today…

We have so much technology infrastructure underpinning software development today that, for the most part, remains unseen. Have you ever wondered what it takes to hold it all together? Have you any idea of the costs involved when it fails?

When we look at the average development organization we usually find a heterogeneous collection of tools from a variety of vendors. Some are modern {sidebar id=1} state-of-the-art technologies and others are legendary tools that we invested in years ago and which contain vital historical data about our development history.”

“Of course, if the textual merge does detect a conflict, the risks are far greater. An automated merge won’t get tired or make a typo. A human can and sometimes will. If the conflicts are nontrivial, as in the case of two engineers rewriting the same code, merges can be some of the most dangerous changes of all.

So far I’m not really saying anything new here. It’s pretty standard advice that engineers should commit code no less than once a day, even if only to reduce the risk of losing code by accident. Also, there is a lot of literature on the benefits of “continuous integration” as opposed to “Big Bang integration”, or on releasing your software “early and often.”"

While both are excellent in their own rights, neither really scratches the itch with a proven method to calculate the real cost for integration nor the return on investment for that expenditure. I will continue to search.

Do have any best practices, industry norms, rules of thumb, or case studies on this topic? Have you ever seen an effective presentation, book, article, or lecture on this topic? Do you know of a term for this study? Are there any presentations from IT consultants available that sell their integration services to an enterprise? If you know of any, please share.

That is my Information Technology Thought of the Day (ITTOD) for November 10, 2009 ©Scott Coughlin.

Image Credit: JBA Systems

Be Sociable, Share!

No related posts.

Related posts brought to you by Yet Another Related Posts Plugin.