Up to this point, I’ve covered relatively simple integrations but what happens if you have a complicated integration one involving dozens if not hundreds of systems?
I remember the first time I did a very complicated integration.
I was using the OPC protocol to integrate building automation systems from several different data centers into a centralized reporting hub.
This was complex to say the least especially considering each data center’s building automation system had to be converted from their native protocol to the OPC protocol.
If I just tried to wing it and had no structure or plan, this integration would have been impossible. But, using the method I’m going to teach you in this post, you will be able to perform complex integrations no matter how many systems are involved.
So let’s dive in!
Summary of Lesson #6
In today’s post I’m going to walk you through how to create an integration map. By the time you’re done reading this post you will be able to answer these four questions:
- What is integration map?
- What is an integration map used for?
- When and when not to use an integration map?
- How do you create an integration map?
Lesson #6: How to create an Integration map
What is integration map?
So what exactly is an integration map?
In lesson number five I discussed the concept of physical and logical integration connections, man is that ever a mouthful.
I described that in any systems integration project you will have either physical, logical or both connections.
I also discussed how you need to go and map out the connections between your integrations. However, I did not show you the exact process for doing this.
That is what I’m covering here.
An integration map, is a method, for mapping out the connections, dataflow, and process flow. Usually this is done by use case.
What do I mean this is done by use case?
In lesson two I discussed, how you can create a use case for your integrations. I also showed you how to list out the systems for this use case.
Since each use case is specific systems you’re going to want to create an integration map for each use case. In any systems integration project you want each integration to be as standalone as possible.
This will help you and troubleshooting as well as supporting and upgrading the use case because it will eliminate any interdependencies between use case
Now if you send yourself what is on interdependency?
An interdependency is where one use case depends on logical and/or physical systems from another use case.
Now it’s not possible to eliminate all interdependencies because some use cases require a previous use case before they can take place.
For example, if you were to go and say that you wanted to have use case on creating a schedule. That scheduling use case may be dependent on a login logout use case.
Ok, so back to the question “what is an integration map?”.
As I mentioned an integration map is a method or process for mapping out your connections, data flow, and use case flow. I also mentioned that an integration map usually created for each individual use case.
What is an integration map used for?
Okay, now that you understand what integration map is.
What exactly is it used for?
I mean, saying it’s a process for mapping out your connections, data flow, and use case flow, isn’t exactly the clearest way of defining what an integration map is used.
When you go to execute an integration project, you’re going to have to perform some specific tasks. These tasks commonly are:
- Connecting the systems
- Normalizing the data
- Prioritizing the data flows
- Creating any sequence or trigger logic (basically if this happens then that happens)
Now if you only had two systems to integrate these tasks would most likely be quite simple.
However, with the data center example I provided, I had to perform the following tasks:
- Data normalization on each individual system
- Quality of service (basically making sure the messages get prioritized over other network traffic)
- Physically connecting the systems on the network
- Creating an integration gateway to make all the systems communicate via OPC
- Triggering use case is based on specific points, alarms and commands
Could you imagine trying to do this on the fly?
I had over a dozen different use cases, and several dozen data centers, could you imagine the chaos of trying to map out all of those systems in my head?
I’m hope that you see, why I would want to create an integration map.
So quite simply, an integration map is a way of structuring your physical connections, logical connections, and data flow in a way that allows you to execute and document your projects step-by-step.
When and when not to use an integration map?
At this point you may be wondering when you should be using an integration map?
I’m not going to tell you that you should use an integration map on every project because it’s simply not true.
If you are connecting two systems, then as long as you identify the physical and logical connections and any data normalization that has to take place you should be fine.
So the general rule of thumb, is whenever you have to connect more than two systems or your project involves multiple use cases, with interdependencies, you should look at creating an integration map.
How do you create an integration map?
Okay, we’ve come to the point of the post that most of you been waiting for!
So you been following along, and you now agree that you should create an integration map, but how? If you go and scour the Internet, you can find resources on systems integration but it’s focused on IT systems.
How do you create an integration map for building automation systems?
Over my I’ve come up a step-by-step process for mapping out your integrations by use case. There are 6 steps creating an effective integration map. The steps are:
- Step 1: Identify the use case that mapping out the integrations for (I described this in lesson 2)
- Step 2: Identify your physical connections, logical connections, systems, and data flow (by the way I went through how to do this in lessons 3, 4 and 5)
- Step 3: Create an integration drawing to list out your systems
- Step 4: Draw the physical and logic connections between the systems and number those connections
- Step 5: Draw the direction, priority, and type of data that flows across the physical and logical connections, number your data flows.
- Step 6: Take your numbered connections and data flows and list them in a spreadsheet
Step 1: Identify the use case that you are mapping out the integrations for (I described this in lesson 2)
As I mentioned in lesson 2, during the use case creation process you identify the systems that will be used. It is important now that you identify the use case that you will be mapping out integrations for.
Otherwise you may not identify the proper systems and connections that are required.
Step 2: Identify your physical connections, logical connections, and data flow between your systems (by the way I went through how to do this in lessons 3, 4 and 5)
Speaking of systems and connections, it is important now that you identify the physical connections, logical connections and data flow between your systems.
You will use this information to create your integration.
You will need to identify:
- The physical connection type
- What systems the physical connection is between
- The logical connection type
- What systems the logical connection is between
- The protocol being used for the logical connection
- The direction of the data flow
- The priority of the data flow
- The size of the data flow
Once you have this information you’ll be able to perform the next step
Step 3: Create an integration map to list out your systems
Now, I’m not gonna walk you step-by-step how to create a system drawing. However, for those of you that are interested I will be creating a systems integration course in the future that will go through this process.
That being said, the important thing is to pick the format and software that you’re most comfortable with using.
I personally use Microsoft Visio and would recommend that to others.
Once you’ve picked the software that you’re going to create your system drawing in, you will need to place each individual system on the integration map.
Step 4: Draw the physical and logic connections between the systems and number those connections
Next, using the information you collected in step two, you will want to add the physical and logical connections to your system integration map.
I personally recommend that, physical connections be solid lines and logical connections be dashed lines ( - - -).
In most cases I recommend using a color code for the connections to show what protocol, physical medium (Ethernet, RS-485, RS-232, etc.) is being used.
You would typically list this in the upper right-hand corner as a legend.
Step 5: Draw the direction, priority, and type of data that flows across the physical and logical connections, number your data flows
Now that you have the physical and logical connections added to the integration map, I recommend that you go and add the direction in type of your data flows.
For data flows I recommend using dots ( ● ● ●), instead of dashes or solid lines.
You will want to list out the direction that your data flows in, the priority level of the data (four commands and quality of service), the size of the data being sent, and the type of data that is being sent.
You will also want to number your data flows.
I will be talking more about data flow, data models, and system requirements in lesson 7.
Step 6: Take your numbered connections and data flows and list them in a spreadsheet
Now that you have your connections in data flows numbered, you will want to list them out in a spreadsheet. In this spreadsheet you will want to show, what physical connections, logical connections, and data flows connect between what systems.
You will also want to list out the following information.
For your physical connections you will want to list out:
- What systems are connected by the physical connection
- The media type of the physical connection
With the logical connections you will want to list out:
- What systems are connected by the logical connection
- The protocol type of the logical connection
- Any software and/or services that the logical connections originate from or and at (often times these are called endpoints)
Finally, with your data flows will want to list out:
- The system(s) that the data flows from
- The system(s) that the data flows to
- The priority level at which the data flows
- The size of the data flow (typically defined in bytes per second)
with all of this information defined you’re now ready to move on to laying out your data model and system requirements. Some of you may be asking why I waited to have the data model after the integration.
I have found that if you don’t map out should your data flows and logical connections prior to creating the data model you can often miss or add data that you do not need.
I’ll be talking through this in, in greater detail in lesson 7.
Conclusion
There you have it, step-by-step process for creating systems integration maps that will help you ensure that your system integration projects execute smoothly.
What method do you use for mapping out your system integration projects? Let me know in the comments below.
