Print Friendly, PDF & Email

Systems Integration is a tough topic. I’ve been planning to write this series for a long time, especially since it is one of the most requested topics in my recent subscriber survey.

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. Since 2008 I’ve 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 😀

So, what will this series consist of?

Well, over the next 8 weeks I will cover the following topics.

  • Level Setting on what Systems Integration is vs System Interfacing
  • How to Create a Systems Integration Use Case
  • Identifying and Diagramming the Existing Systems
  • How to Use a Gap Analysis to Detail out the New Systems
  • Detailing out the Physical and Logical Integration Points to include:
    • Data
    • Protocol
    • System
    • Hardwired
  • How to Create an Integration Map
  • Detailing out the Data Model and System Requirements
  • Developing a Sequence of Operations

Each week I will create an individual post for each topic, except topic #1 which is included in this post.

As I create these topics I will continue to add to this series and will re-release this series when it is fully complete.

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

Summary of the Lessons

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

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: How to Create a Systems Integration Use Case

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: How to Identify and Diagram the Existing Systems

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: How to Use a Gap Analysis to Detail out the New Systems

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: Detailing out the physical and logical integration points

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: How to create an Integration map

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: Detailing out the data model and system requirements

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: Developing a Sequence of Operations

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.

The Lessons

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”.

Like this Content? There's much more...

Join the BAM nation and gain access to BAM Nation only videos, templates, and checklists. Also get notified when I post new content and take advantage of subscriber only pre-sales on my products!

Powered by ConvertKit

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?

BDAT in BAS

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.

Business

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?

Data

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?

Application

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

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.

Conclusion

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 … if after reading this information you realized that there is much more to building automation systems and you’d like a simple resource to learn more then I have a solution for you.

Click on the image below to find out more about my solution

 

Like this Content? There's much more...

Join the BAM nation and gain access to BAM Nation only videos, templates, and checklists. Also get notified when I post new content and take advantage of subscriber only pre-sales on my products!

Powered by ConvertKit

 

 

Pin It on Pinterest

Share This