Way back in 1624, English poet John Donne observed that "no man is an island entire of itself; every man is a piece...
of the continent, a part of the main." Today, we might say "no cloud is an island" because the value of cloud integration services can be greatly enhanced when they are connected to back-end systems. The trick to maximizing this value is choosing the best way to make this connection happen.
Everything old is new again
Tying systems together is not a new concept, and years ago we used the term middleware to describe that class of software. In the early 2000s, I fielded a major research project to better understand the underlying whys and hows. One of the biggest findings was that organizations need to talk less about integration and more about interoperability. The reason is that they need to get their siloes of information to work together, and they want to do so without having to bind them programmatically.
As the cloud becomes more mainstream, this concern is amplified. Different kinds of computing power are more readily available to a broader range of users in a greater multiplicity of locations than ever before, thereby making the cloud another silo that must be hooked to legacy solutions. The good news is that there are many ways to do this, from custom coding to clever process management. But companies have to understand their own situation fully before choosing the best method for them.
The following are cloud integration services and approaches that will help companies in creating a list of their options:
Application programming interfaces (APIs) are bits of programmatic code that facilitate interactions between software programs, in the same way graphical user interfaces do between people and computers. Not all providers open theirs up for customer use. They prefer to be paid for these sorts of integration services. But this has changed over the past few years, and if an organization has the in-house skills to take advantage of APIs, it's definitely something worth asking its providers about.
Software development kits, or SDKs, are sets of development tools built specifically to ease the work surrounding a particular application. They are often offered for free as a way to encourage organizations to buy the software with which they are associated. Besides an API, they may also include debugging aids, sample code, and supporting technical notes or documentation.
Services and connectors are prebuilt adapters that plug one business application into another and thus allow for simpler integration to existing data centers, as well as to in-house applications. Among these adapters are industry-standard Web services such as SOAP, REST and CMIS, as well as vendor-based protocols like .NET, Java Message Service, and MQ messaging. They also are a step along the path to Enterprise Application Integration.
Enterprise Application Integration is a technique that leverages a standardized central platform, or bus, that connectors and applications can plug into. In essence, it works the way the old Windows print driver did, by allowing developers to write to a single technical interface rather than a dizzying array of individual offerings. These platforms also often include plans, methods and tools for consolidating and coordinating solutions so they can behave as one. It's worth checking to see whether the cloud provider can play in this arena.
Business process management (BPM) is a set of process improvement techniques that can achieve functional interoperability by, say, tapping information in one system, moving it around the organization -- according to predefined rules -- and essentially putting it back when the process is complete. This is a great way to let solutions communicate without anyone in the company having to be a coding expert. However, it does require a little creative thinking. It also may expose particular cloud data fields to legacy systems.
Metadata management and enterprise search are content-based capabilities that trade in the descriptors surrounding particular pieces of information in order to locate the data needed. They then tee up this data for retrieval and use. Since the first step in sharing information is finding it, matching one system's key pieces of metadata with another's is a great way to build a consolidated view of data without actually having to integrate anything. Because different users and different systems commonly utilize different words to describe particular bits of information, a thesaurus may need to be inserted between the cloud and the back office to make the proper connection.
These cloud integration services range from the programmatic to the practical. A company's particular situation will dictate which options to use, and in which combination. For instance, how complex is the need? If all management wants to do is get its salespeople up on Salesforce.com, most of the options here may be unnecessary. But if a company is trying to hook Salesforce.com up to its old SAP solution, it may need to have a rep do some serious explaining to IT.
Consider the skill sets the company has in-house, and which can be more readily obtained from a cloud provider. Someone, somewhere has to do the work, so it's important to understand how much the company will have to do versus the provider. It will also be critical to calculate what those relevant costs will turn out to be. Time ismoney, of course, and if staff needs training before it embraces the cloud, factor that into the overall cost projections in order to avoid a nasty surprise.
These are just a couple of the questions to ask within an organization and of potential cloud partners before a company integrates the cloud with its infrastructure. There are many ways to achieve integration or -- to use language Donne might recognize -- to build bridges between islands.
Steve Weissman asks:
Which cloud integration strategy do you use? Would you recommend it?
0 ResponsesJoin the Discussion