Better Operations, Better Decisions, Better Results!
Affordable Software Integration Solutions

Strategies for Success

A comprehensive approach to software integration.

Although some examples below refer specifically to manufacturing, our services are not limited to those industries. Manufacturing merely serves as a good backdrop for the description of our capabilities.

Click on the headers below for detailed information.

Expand all Collapse all

1. Coping with the Scope Issue

Look to Others

In the early stages of scope definition, there may be a period where the team really has no idea what the project is trying to accomplish. (This happens more often than you might imagine). In times like these the examples of other businesses (or even other industries) can be helpful in mapping out the objectives.

A discussion with the supplier of one, or more, of the systems in question can lead them to share examples of successful projects that they have implemented. Ask the supplier why the business did what they did, as well as how they did it.

In addition, locating relevant standards for message exchange that have been developed by industry trade associations (e.g. CIDEX, ISA S95) can help to identify important integration scenarios and, ultimately, map out the overall project scope.

Focus on Business Benefit

Believe it or not, some project leaders and consultants forget this rather obvious truth: just because information can be passed automatically from one system to another does not mean that it should. The project team and its leaders need to begin with an examination of business value:

  • What benefits will be delivered to the business by integrating the two systems?
  • What kinds of integration scenarios will support those business benefits?
  • How much value will any given scenario deliver?
  • Are other scenarios dependent upon this scenario?

The next question that needs to be addressed is one of cost:

  • What is the cost of automating a given integration scenario?
  • What are the risks (to the business or to the project) associated with automating that scenario?
  • Do the benefits outweigh the cost and risks?
2. Better Business Process Mapping

Ideally, all of the systems to be integrated would be implemented in parallel with separate, but coordinated, project teams. These teams would map out the processes of the entire business and make realistic and informed decisions about where the various process activities should be automated. The process maps would always be end-to-end, ignoring artificial system boundaries.

If that ideal situation is not possible, then the business processes involved in the integration should certainly be re-mapped from end-to-end. The owners of all affected systems should also be forewarned that changes may be required in their system implementations in order to ensure smooth operation of the integrated solution. Finally, the team should examine all of the affected business processes, looking for primary and secondary interactions between the processes.

3. Breaking Through Culture and Terminology Barriers

Solving cultural barriers can be a significant hurdle, but being aware that such barriers exist is an important first step. Armed with that knowledge, the team leader can ensure that all stake holders are represented in the project team and can also secure executive sponsorship for the project (from a level that crosses all/most of the departments involved).

Again, awareness of potential terminology issues can allow such issues to be identified more quickly. Ask each stakeholder to discuss the project from their perspective and to take the time to explain important terms and concepts. If necessary, a team lexicon (a “Rosetta Stone”) can be prepared.

External consultants especially those who understand both the manufacturing and the corporate environment can become the mediators between departments and so can help to accelerate the development of a set of shared objectives and that all stake holders have a common understanding of those objectives.

4. Resolving Model Disconnect

As has been discussed, the software applications typically build their model of the physical world based upon the level of granularity needed by that system. The needs of other systems are not considered. Integration projects are simplified greatly if the models have a one-to-one mapping between them. For example:

  • If there is a raw material called WATER in one system, there is also a material (and only one) for water in another system. The second example does not have to be called WATER (it could be called AGUA, for example) but having one, and only one, instance of water in the second system simplifies things tremendously.

If one-to-one mapping cannot be achieved, then many-to-one mapping is the next goal. Here, many items in the source of a message are represented by a single item in the destination. For example:

  • An inventory tracking system may have storage locations of RL1S1, RL1S2 and RL1S5 all of which hold a product called DVD-RW. If the Supply Chain Management (SCM) system tracks inventory of that product, it will not care where in the warehouse the product is stored, so it may have an inventory location called WAREHOUSE. As long as we send inventory related messages from the warehouse management system to the SCM system, we can map RL1S1 to WAREHOUSE; RL1S2 to WAREHOUSE and RL1S5 to WAREHOUSE and the SCM system will understand all of these messages.
  • However, what happens if we try to send a message from the SCM system to the warehouse? To which warehouse location should the message be directed? If it needs to go to all of them, how do we split the quantities in the message across these three locations? This is a one-to-many problem.

It is very rare for one-to-many mappings to be successfully handled by an automated interface. In most cases, the external model will need to be modified to allow the business objectives of the integration scenario to be achieved.

NOTE: Identifying and resolving model mapping issues can be a huge bottleneck to the project (especially where very large models are involved). The model owners themselves can be a barrier to resolution – often they do not even accept that a problem exists and may have little incentive to make changes. As ever, early awareness of the problem combined with clear communication and executive support are the best weapons to use.

5. Choosing the Right Technology

Today there is a wide availability of robust, easy-to-use integration middleware products, which provide a re-useable infrastructure for message delivery; message routing and message translation. Products such as SAP NetWeaver; IBM Websphere or Microsoft BizTalk Server provide such services; support business process mapping and automation; provide a wealth of adapters for common software systems; and can even simplify secure transmission of messages across the internet.

The recent popularity of XML and Web Services, as well as the advent of Service Oriented Architectures also lowers the technical barriers to integration – by ensuring a common format for message delivery and interpretation. However, the notion that Web Services or XML deliver integration is false.

A well composed Web Service exposes the capabilities of a software system in such a way that they can easily be understood (at a business level) and can easily be consumed by a variety of other software applications. However, the content of an XML message conforms to some pre-defined schema. Unless two systems understand and expect the same schema as one-another, then using XML does not preclude the need to translate a message from one schema to another.

A number of standards initiatives are underway to help define common XML schema that can be shared by many different software packages, out of the box. Standards bodies like OAGIS & CIDEX have already published hundreds of such schema and, in the long run, these standardized schemas should dramatically reduce the barriers to system integration projects.

In the meantime, the combination of the aforementioned middleware solutions with XML and Web Services has become the most common approach for larger integration projects. The Web Services provide a common way to access system services and process messages; while the middleware takes care of coordinating message flow and performing schema translations.

For smaller projects, custom code often fills the need for coordinating processes and message translation – although such code can become unwieldy if the system complexity increases significantly over the life cycle of the solution.