Bob Sutor

At the Open Source Business Conference (OSBC) this year I did a presentation called “Asking the hard questions about open source software.” I’ve been expanding on some of the areas I mentioned and have previously posted the blog entries “10 elements of open source governance in your organization” and “10 considerations for maintaining open source in your organization.”

Today I want to talk about integrating open source software into your IT infrastructure. Here’s the slide I used at OSBC:

How easy is it to integrate the software with your data or other software you already use?

• Does your software use recognized industry standards or does it have its own way of formatting data?
• Are the developers of the software involved in creating the standards that will allow interoperability?
• If you adopt the software, who will do the integration tasks?
• Is the software certified for use on the operating system and hardware platform you plan to use?

Integration means having your software systems and services talk to each other, wherever they may be located, in ways that implement the processes by which you run your company or organization. Integration failures can cause unhappy clients or customers, lost productivity and revenue, and sometimes legal problems.

1. A certain vendor who shall remain nameless used to tell its customers “Integration and interoperability are easy, just buy everything from us.” They usually skipped the next part which would have said “and then you’ll be locked into our products and it will be very expensive and time-consuming to change that. Ha, ha, ha.” Most customers with whom I speak have a combination of traditional software from multiple vendors, open source from several providers, and various combinations of bespoke code. Your IT world is heterogeneous, probably, whether you are using open source or not.
2. Newer technologies like Service Oriented Architecture and Cloud Computing can change and improve the way you implement your business processes. As you look across your IT landscape, ask yourself where open source software might or might not fit and where it will improve or possibly make worse what you are doing now. I say “open source software” in that last sentence, but you could substitute “any software I am considering using.” Remember that open source software is software, after all.
3. Whatever the price of the software you are considering integrating into your IT infrastructure, you need to know if it will exchange information with full fidelity with your other installed software or that which you are using as a service, perhaps in the cloud. That is, does the open source software fully and correctly implement the open standards and protocols to allow it to drop into your infrastructure? Again, and for the last time here, you should ask this of any software, not just open source software.
4. It is not sufficient to say “I have the code for the open source software, I can see how it does things, so I don’t care if it implements open standards for interoperability.” Code changes while standards define interfaces that are meant to be stable, at least for a while. By all means, ensure that the open source software implements open standards.
5. Customers routinely test software vendors to see how well they implement standards. Expect them to do the same with open source software providers. Further expect to have to document each and every standard that it is used for interoperability, along with the versions implemented, and extent of implementation.
6. Customers often ask traditional software vendors to join standards organizations. Expect them to do the same with open source software providers. You’ll need to figure out exactly what this means if the open source provider is a widely diverse community of people from many organizations. If a vendor who is a member of an open source community joins a standards organization because of a customer request, you’ll need to know explicitly whether the vendor is representing itself or the community.
7. Vendors often take on the task of integrating software for customers, and there are system integrators who can do the same. Who will do this for the open source software you are planning to use? Sometimes there are open source companies like Red Hat or Novell, or services and integration companies like IBM or Accenture whom you can pay to do the integration. You might even be considering installing, integrating, and maintaining the software yourself. Make sure you have someone who knows the open source technology and can integrate it correctly with the rest of your infrastructure.
8. Depending on your organization and its rules about what software can be used, you may need to check off that the open source software is certified for your hardware. Learn whether that is done by the software or hardware provider. Depending on where your open source code is coming from, you may need to reconsider any ironclad rule about certification, if you decide use of the code is critical. Your internal process for such an exception will need to be adjusted accordingly.
9. Once that open source software is sitting in your infrastructure, how are you going to manage it? Does the systems management software you are using now support the open source code? Does the open source software need to be extended in order to support management standards? Does the systems management software itself need to be augmented?
10. If you are using no open source code strategically in your organization but you think you should consider using it, start with Linux. There are many highly motivated people, organizations, and companies that can help you integrate Linux into your IT world. Furthermore, it is mature technology with several first class distributions.

• “Asking the hard questions about open source software”
• “10 elements of open source governance in your organization”
• “10 considerations for maintaining open source in your organization”
• “10 ideas about integrating open source into your IT infrastructure”