<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=2854636358152850&amp;ev=PageView&amp;noscript=1">

Systems Integration is a tough topic. I've been planning to write this series for a long time. This series is going to take you from zero to systems integration hero.

In this series you will learn the process I created when I first started systems integration way back in 2008. I've since refined this process to align more closely with enterprise architecture models, but at the end of the day, it's still my same process, just a little bit cleaner :-D

Table of Contents

  1. Overview: A Summary of SBA's Systems Integration Lessons

  2. Lesson 1: Level Setting on what Systems Integration is vs System Interfacing

  3. Lesson 2: How to Create a Systems Integration Use Case

  4. Lesson 3: Identifying and Diagramming the Existing Systems

    1. BDAT in BAS

  5. Lesson 4: How to Use a Gap Analysis to Detail out the New Systems

  6. Lesson 5: Detailing out the Physical and Logical Integration Points

    1. The 3 Step Process for Detailing Out Physical and Logical Integration Points

  7. Lesson 6: How to Create an Integration Map

    1. 6 Steps for Creating an Effective Integration Map

  8. Lesson 7: Detailing out the Data Model and System Requirements

    1. The 4 Step Process for Defining Your System Requirements

  9. Lesson 8: Developing a Sequence of Operations

    1. The 7 Step Process for Creating a Sequence of Operations

    2. The Proven 5 Step Process for Executing Your Systems Integration Project

  10. Next Steps


I hope you all are ready to take a deep dive into the topic of Systems Integration!

Overview: A Summary of SBA's systems Integration Lessons


Lesson # 1

In this lesson I explain the differences between systems interfacing and systems integration. You will learn the differences and you will also learn the importance of a properly defined use case.

Lesson # 2

In lesson 1 I discussed how important a use case is. In lesson 2 I walk you through how to create a use case.

Lesson # 3

In lesson 2 I discussed how to create a use case. Once this use case is done you will have an idea of what systems you need to integrate. In order to do this you need to understand what systems you have in place. I will talk through this in this lesson.

Lesson # 4

In lesson 3 I discussed how to identify existing systems. Once this process is done you may realize you need additional systems. I will talk you through how to perform a gap analysis and how to identify the new systems you may need.

Lesson # 5

Lesson 4 described how to identify all of the systems you need to enact your use case. In this lesson I will detail out how to handle the physical and logical connections that are needed to make your use case work.

Lesson # 6

Lesson 5 went through detailing out the physical and local integration points. In lesson 6 I walk through creating your final integration map.

Lesson # 7

Lesson 6 gave us a solid picture of our integrated system. Now it's time to make sure our data types match up and that our system requirements are covered.

Lesson # 8

Lesson 7 took us prepared us with a solid data model and robust system requirements. In this final step we detail out our sequence of operations and get ready to hand the package over to our operations group to execute.



Lesson # 1: Level setting on what Systems Interfacing is vs System Integration

Systems integration and systems interface two often confused terms and the perfect place to start the conversation around systems integration. To often folks approach a systems interfacing problem with a systems integration solution. This results in confusion, scope difficulties and cost overruns that didn't need to exist in the first place.

Therefore, we are going to start this series by defining each of these terms and then detailing out how they are different.


What is Systems Interfacing?

Systems interfacing is the simple bridging of two separate solutions using a common format. The fact is most of the "systems integration" folks do is actually systems interfacing.

Do you want to bring your lighting systems into your BAS so you can see their status? That is interfacing.

At the end of the day, folks will spend thousands of dollars to get "systems integration" done that is really simple systems interfacing that can be accomplished for quite a low-cost.

How low a cost you ask? Let me give you an example.

Say I have a lighting system with a BACnet/IP interface and a BAS that supports BACnet/IP as well. How much should I budget to integrate these two?

You should be saying it depends on the use case. If you said that, good job it does depend on the use case. And the use case is what determines if you need an integration or an interface.

For the sake of simplicity let's say we simply want to see the lights on the graphic for each room. That is a simple interface, we are simply mapping data from a separate system.

So then how much would that cost? Would you be surprised to know that I can map 1000 light fixtures into a BAS in under an hour? Before you think that I am some integration genius, let me tell you that hundreds of other folks have done the same thing.

How do I know that? I've worked on their systems and asked them how long it took!

A proper protocol will make a system interface super quick and easy.

So the question then becomes, what the heck is systems integration?


What is Systems Integration?

Systems integration is the process of bringing two separate solutions together so that they act as a single solution. Throughout this series I am going to walk you through a scenario most of you face everyday, integrating two separate BAS systems together. In order to keep this vendor agnostic we will simply refer to these systems as system A and system B.

Now here's the deal, when is tying two separate BAS's together considered systems integration?

If we can connect two BAS's via BACnet/IP isn't that simply systems interfacing? Good question!

Remember what I said, it's all about the use case.

Well in this particular scenario we have a customer who really likes system A. Unfortunately due to procurement rules, budget, their manager (you pick!) they have been told they need to go with system B.

How can this customer get system A to work seamlessly with system B?

This is the challenge folks face everyday, with different naming conventions, data structures and all the other nuances systems integration can be a nightmare!

This is the scenario that systems integration handles. When trying to get a BAS to act as a single front-end for multiple other BAS's most folks just map in points and call it a day (systems interfacing).

This leads to finger-pointing, late night job site visits, and high service bills. At the end of the day you want it to just work!


Lesson #2: How to Create a Systems Integration Use Case

Da, da, da....

Well, that was weird, making a trumpet noise announcing the start of the article doesn't work quite as well in text..

How to create a systems integration use case.

We in the BAS world tend to have a bad habit. We like to do things are way and often do not look outside our industry for new methods and approaches. The use case is a perfect example of this.

How many times have you seen use cases formatted according to the CSI MasterFormat. Sure all the parts and pieces are there, but at the end of the day, most of these glimmering pieces of structural perfection are... junk.

They are about as useful as me at an art show, sorry art lovers, I don't get art, never will.

So, why don't we suspend disbelief for a moment and assume that we in the BAS world can do use cases a different way, and by different way I mean the way the rest of the world "does" them.


What are the pieces of a use case?

If you remember our scenario in our first article we are going to tie two BAS together into a single user interface. This use case scenario is surprisingly common in today's BAS world.

Our first step to creating this use case is to identify a few key things.

  1. What systems or people are involved?
  2. What does success look like?
  3. What is the goal of the use case?


What systems are involved?

If you remember earlier in the article I mentioned some unfamiliar terms. One of those terms was the term actor. I want you to think of a use case a play. The use case is going to tell the actors what do at certain points in the process.

So at this point you may be thinking an actor is a person, you're partially correct. An actor, according to most use case documentation, defines a role played by a user or system that interacts with the subject.

Logically that brings us to our next question. What is a subject?

A subject is the system or systems that should perform a task based on the use case scenario.

Ok, so time for our first question. Who are our actors and who are our subjects? I want you to take a second and think this through, a lot of people mess up here and its important to identify the correct actors and subjects up front.

So, pause for a second look a way from the screen and think through who your actors and subjects are. Remember we are thinking through the use case of two BAS tying into a single user interface.

Ok you done?

Great, so your list probably looks something like this.

Actor(s): BAS 1, BAS 2, Technician, Supervisor, Common User

System(s): New BAS Graphical User Interface (GUI)

At this point we have our actors and systems identified now we need to determine how to put these pieces together.


How do you put these pieces together?

This part is often called your narrative. It is the narrative that will form your use case and will tell how the different actors communicate with the system.

We know that we want a user to be able to use the new GUI to be able to access both BAS. Do you know what we call that? We call that our main success scenario (MSS). Our MSS is our success criteria.

A use case should have one MSS.

If you write a use case and you have more than one MSS you are most likely combining use cases. It is critically important that you separate your use cases to focus on one MSS.

You see, systems integration is complicated enough, the idea is that your use cases will be built for a single purpose. That way when you create the integrations you can segment your use cases. This will allow you to troubleshoot, code, and support your use cases individually.

So then, how many use cases do we have with the single GUI scenario. Off the top of my head I can think of several.

  • User Logs into the single GUI
  • User logs out of the single GUI
  • User modifies data in the single GUI
  • User runs reports in the single GUI

Now you may be thinking, oh come on Phil, it's a simple integrated BAS GUI. I'd caution you to pause anytime you start to think this way. You need to think through each scenario.

For example, if the new GUI needs a login, which login does it use?

Does it use BAS 1's credentials or BAS 2?

Does the new GUI log user actions?

If so where?

How does it tie to IT systems?

And those are just the set of questions for the first scenario.

So, lets build out a use case.


Building the Use Case

Building out a use case isn't very hard. In this scenario we are going to build out two use cases:

  • User logs into the single GUI
  • User modifies data in the single GUI


User logs into the single GUI UC#1

Actors: BAS Technician, BAS 1 and BAS 2

Systems: Single GUI, BAS User Databases

Main Success Scenario: User Logs Into Single GUI

Description: The BAS Technician will be prompted for a login at the single GUI. The user can use his/her login credentials from BAS 1 or BAS 2. Upon the GUI authenticating with BAS 1 or BAS 2 the user will be granted access to the application.


User modifies data in the single GUI UC#2

Actors: BAS Technician, BAS 1 and BAS 2

Systems: Single GUI

Main Success Scenario: User modifies data in the single GUI

Description: Once the BAS technician is logged into the single GUI (see use case 1 user logs into the single gui), the user will be able to access BAS point data and modify that data. The single GUI will confirm and log any data modifications.

Ok, this use case has something glaringly wrong with it. Can you tell me what that is? I'll give you a hint, it occurs in the last sentence.

Give up? Well, here is the problem. Use case #2 is actually two use cases. The modification use case is good, but at the end of the use case I added confirm and log any data modifications. 

Now at first glance this may not seem like a big deal. It actually may seem like I am splitting hairs and being anal retentive. However, do you know how the single GUI will log data modifications?

Will it log them in BAS 1's database?

How will the confirmation happen?

Do you see how this could lead to finger-pointing at a job site?

The BAS technician for BAS #1 says "It wasn't my job to log any data modifications, your use case clearly says the new GUI will log data modifications."

In the BAS techs defense the use case does say that, but is that what you want?

I will leave you to ponder that question.


Finalizing the use case

With our use cases mapped out we should now be ready to move onto our next step.

Wait! Stop!

We aren't ready yet! Do you know why? Because we haven't gotten our stakeholders buy-in.

Stakeholder, there's a hundred-dollar word for you! A stakeholder is a person who can be impacted by the use case. To often I've seen, cause I would never do this right :-D, people go and create use cases that are absolutely beautiful.

And these use cases float their beautiful selves right to the garbage can! This happens because the use case creator did not take the time to meet with stakeholders in order to get "buy-in".

In order to avoid a ton of headache after the fact I encourage you to meet with your stakeholders in order to ensure that your use cases have their "buy-in".


Lesson #3: How to Identify and Diagram Existing Systems

In the world of enterprise architecture system mapping is a common event and in the enterprise IT world system integration is a daily event. I argue, that in the BAS world, systems integration is going to become an increasingly important task.

Yet, there is a problem. No formal process exists for systems integration in the BAS world!

But, why should we reinvent this process when a perfectly good process exists in the IT world.

In, the IT space this process is called mapping the AS-IS architecture. AS-IS architecture means the current architecture as it currently is in the business. There are four main domains, or focus areas, that an IT mapping session will focus on.

Those are the Business, Data, Application, and Technology domains. These domains are often abbreviated to the acronym BDAT. I believe, based on my experience, that any systems integration effort should focus on all 4 domains.

But, what does that look like in the BAS world?



Believe it or not, there are business, data, application and technology systems in the BAS space. What might this look like in our simple 2 BAS into a GUI scenario? Let's move through each of the systems.



Believe it or not BAS can have business value. For example, does a certain business group rely on reports from the BAS?

There's nothing quite as fun as going through an integration effort only to find out that you missed a key report that the facilities or energy management groups require.

  • In this category you want to find out:
  • What business groups use the systems?
  • What do they use the systems for?
  • Is there a unique capability that needs to remain or be replicated?



It's all about that data!

Seriously, the whole reason we are pursuing a single GUI is to make data easier to access and manipulate! So then, what do we need to know in this section?

We need to understand:

  • How is data stored?
  • What format is the data in?
  • How is the data collected?
  • How is the data accessed?



At the end of the day the two BAS are applications. However, each one of the BAS have their own applications as well. Some BAS allow you to configure their databases and programming directly from the BAS and some require external software.

In this category we want to identify:

  • What are Applications being used?
  • What Dependencies do these applications have?
  • How these applications can share data (API's and protocols)?



Technology makes the world go round! Well, it at least lets the BAS run!

So when we say technology what are we talking about?

We are talking about hardware and connections.

In this category we identify the following information:

  • What are the hardware requirements?
  • What does the physical and logical topology (device layout) look like?
  • How are the systems connected to the network?
  • Are the systems scalable?


Putting it All Together

At the end of this exercise we will have clearly defined the BDAT systems that our two BAS are dependent on.

By answering these questions we will  have an accurate picture of our AS-IS environment.

With this information we are able to understand what our constraints are within our current environment. Constraints are hard limitations that we must adhere to because of our technologies.

For example, since both of our BAS use SQL databases we are constrained to using a SQL database or using some sort of database translator. Knowing these constraints will become invaluable as we move through the next several steps of the systems integration process.


Next Steps

So there you have it folks. That is my step-by-step process for approaching systems integration projects.

If you started this series with limited information and, after reading this, you realized that there is much more to building automation systems that you'd like to learn. I have a simple solution for you...

Purchase our comprehensive digital book, Building Automation Systems A to Z. Expand your skills and grow your career with this deep dive into the world of BAS. 





Phil Zito

Written by Phil Zito

Want to be a guest on the Podcast?