There are a lot of misconceptions about integration. The concept can be deep enough to evoke hundreds of questions, specific to a company’s back-end systems. This article focuses on five common questions that integration sales representatives may dance around either because of shortcomings in products or a lack of knowledge about how integration is implemented. The questions are:

  1. Building integrations really isn’t easy, right?
  2. How much will I need to spend on professional services, and what particular expertise will that entail?
  3. What is the true time to develop integrations?
  4. What are the real costs/options for software?
  5. With all of the standards out there, isn’t integration pretty straightforward?

Midsized organizations may undertake either internal or external integrations, and projects can cross over data formats and system boundaries. One good example is integrating order data from an online store (typically in XML or an intermediary database back end) to an enterprise resource planning system. It’s what many think of as a singular or monolithic integration. It connects two points, crossing data formats and system boundaries.


However, that’s only part of the picture. You may also want to move the information into a customer relationship management application as a subsequent transaction. This can be thought of as a complex (or multistep) integration. Some other examples of integrations involve legacy data movement, electronic data interchange and XML. Interestingly, there is an increase in spreadsheet-to-application integration, as spreadsheet formats emerge as a lower-end data-exchange standard and represent a tempting staging area for incorporating into other applications.


Why Integration Matters


Islands need to communicate within a company. Most midsized companies have IT departments that are stretched thin for several reasons:

  • Limited staff and resources,
  • Lack of knowledge and difficulty in finding impartial advice,
  • The cost of solutions,
  • Lack of time to devote to implementation and maintenance,
  • Short-range management perspectives,
  • Lack of understanding of the benefits that IT can provide and how to measure those benefits and
  • Lack of formal planning or control procedures.

These limitations lead to inevitable questions.



Question One: Building Integration Isn’t Easy, Right?


The ugly truth about integration projects is that typically they're tough going. There are tools that can help, but organizations still need to be prepared to get in and roll up their sleeves.


There are several considerations, including the data formats to be used (and your understanding of data formats and processes?), the processes to define and communication methods. Additionally, with an external Integration, how cooperative is the external partner, what information have they providedand what skill sets are available inhouse to achieve understanding?


Integration does not need to be difficult if organizations have the following variables:

  • Ability to work with data definitions and create definitions that can be reused.
  • An easy-to-use mapping tool (graphic, drag-and-drop, connect source and target information).
  • Business process management, something that is often overlooked. Companies are conscientious about this data, but often forget about the processes and how they can improve or accomplish more with what they have.
  • A flexible way to use communications adapters. Without them, a company’s infrastructure can be over-burdened.

So, the key to making the “how” easier is understanding what the tools can do for you. There is a direct link between the capabilities of tools and the ease of building the integration.


Question Two: How Much and What Kind of Professional Services Will I Really Need?


This depends on a few key factors. The first is the size of the integration project, which is then followed by the capabilities of the tools used and in-house skill sets.


For large integration projects, point solutions, especially where manual programming is involved, can run from 4 to 10 the cost of the software. The sophistication or complexity of the tool, compared to in-house skill sets tend to define the need for consulting. The in-house capabilities need to be aligned with the capabilities of the tool. This may not be obvious, but it’s important to keep in mind. You don’t give an eight-cylinder roadster to a new driver nor send a jet pilot to operate a back-hoe. Match the tool to the skills and experience of the user.


Users can leverage a pilot project as a mentoring stage. The key to finding the best ROI is to define a small pilot project and engage a professional services group to mentor the team. This allows a skill set transfer, won’t consume a large amount of resources and produces a usable integration. In other words, the pilot project doesn’t go away after implementation, it actually goes into production. The concept has been proven, and the results are immediate. Because of the capabilities of contemporary integration tools, these pilot projects only last a few weeks. They can be an effective way to measure the rate of knowledge transfer and end up with a usable result.


Question Three: What is the True Time to Develop Integrations?


As with so many things in life, the classic answer is: “It depends.” There are several factors that tie in with the first question - integrations aren’t really easy. I’ve worked with companies where the IT team staffs the new systems inside-and-out. They were able to grasp the tools and run full-speed. We also have the converse situation where a smaller company has a business analyst who is savvy and is thrown into the mix as the person in charge of integration. They have some knowledge of the processes, passing familiarity with the data formats and limited background with the notions of mapping and data conversion. The third scenario includes everyone else.


Thus, this question is too broad a question to answer generically. There are usually metrics available, such as these used to map an EDI 4010 purchase order into a back-end database for example. Professional services teams usually have a good handle on these types of metrics.


The answer lies within the capabilities of the tool and how easy it is to understand and leverage. A good example is a tool that allows the user to take a flat-file document and discover its structure, which saves him or her from having to build the data definition by hand.


Understanding one’s business goes a long way toward developing integration. Besides understanding the company’s own business processes, it also helps to have an understanding of the data formats. Be aware of all facets general to specific.


There are no absolute answers, just a range of times that have been observed from projects. Your first pilot project should definitely be designed to take only a few weeks to a month. You want to attain a completion without burdening the user with a large knowledge transfer upfront. Integration tools can help accelerate the process, and a few key principles come into play:

  • Easy-to-use visual tools reduce the learning curve,
  • Reusable objects improve development efficiency and
  • Integration tools can reduce complexity and therefore reduce dependency on consultants.

Testing the integration is a key area that gets lost in the time estimates, so always keep that in mind.


Question Four: What are the Real Costs/Options for Software?


Most salespeople want the prospective customers to buy the whole enchilada and think of integration architecture and enterprise-wide solutions together. However, there are packages designed for the company to buy only what they need at the present moment, and allow them to grow into the full solution later. Depending on the corporate setting, an organization may be addressing a mandate such as an EDI standard from a large trading partner. In that case, the organization should look at a tactical solution with some interest in moving into integration later.


Given the complexity of enterprise systems today, it can be overwhelming to think, about all the touchpoints where integration would be a benefit. Being able to buy a slice of a full integration solution is a valuable way to meet immediate needs and hopefully introduce the technology at a lower price point. Be cautious of hidden costs, such as training time/ramp up.


Question Five: With All of the Standards Out There, isn’t Integration Pretty Straightforward?


There’s an old saying in IT, which states “The beauty of standards is that there are so many.” That’s also a pitfall. One interesting thing about standards is that there are a lot of them and they all want you to do things their way. Figure 2 shows technology standards relevant to integration. There are no formal integration standards, however, just technology standards.There are ways of thinking about integrations, templates or patterns to follow, but no established rules on how to do integration. Quite often, standards are simply guidelines. That said, understanding your data and processes is a fundamental requirement when thinking about integration.


Importance of Integration


The reason why integration exists is because of what I call the standards oxymoron - the notion of standards regarding data. There are standards for what the data looks like, how it is transmitted, etc., and every type of data has someone attaching a standard to it, from XML (RosettaNet, large-customer proprietary formats) to the EDI (X12 and EDIFACT). That is why integration is important. If we just had one common layout for files and databases, we wouldn’t have a lot of these issues. We don’t though and integration is key to navigating the differences.



Another of integration is the agility to deal with new data formats as they emerge. Spreadsheet formatting is at the forefront of this movement. Whoever would have predicted excel to be a foundation for integration?


Now You Know


Equipped with these five questions, a company will be better prepared to deal with the inevitable uncertainties of an integration initiative. Remembering a few points will be especially helpful: 

  • Start with a pilot project and mentoring.
  • Think strategically. Consider where the business is going.
  • Ask if the company needs the whole picture or just the key pieces first.
  • The existing team, with their existing skills, can be successful.

Vendors ranging from software companies to integrators will do their best to sell their approach. Knowing the right questions will better equip a company to sift through the answers.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access