This is article #3 in the Systems Integration series, and in this article, we are beginning to dive through the process of identifying the systems landscape. This process is critical to adequately assess the time, effort, and cost that each of our use cases will require. Up to this point, we have identified the difference between systems interfacing and integration, and we have identified our use case.
You see, at the end of the day a use case may not provide enough value to justify the cost.
However, if we haven't identified the systems that are required then we may not know that cost.
This series is focused on the rather "simple" integration of two different building automation systems which we call system A and system B.
The purpose of our integration is to provide a single graphical user interface (GUI) for our building operate to use instead of having to use both system A and B.
While this integration is "simple" the processes we use throughout this series will scale to even the most complex integration.
With that being said, let's dive into lesson #3.
Summary of Lesson #3
In lesson #3, I cover the subject of identifying existing systems. This is also called, mapping the system landscape. In this lesson I will cover why this mapping is done and how it will be done.
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
There you have it, a clear process for performing an AS-IS assessment of your existing systems. When you go through this exercise it is important that you address each domain.
This is not an exhaustive list of the questions you should be asking for each domain. I encourage you to begin to build out your own library of questions and checklists as you move through the process.
I personally have over 100+ questions in each of the BDAT domains that I've built up over the years.
In the next part of this series, I discuss how you can use a gap analysis to detail out your new systems. You won't want to miss this article as it is packed with value bombs!
Ok, so question for you:
In the comments below please pick a domain and share one of the questions you ask during the AS-IS assessment.
Love podcasts?
Check out the sister to this article, Smart Buildings Academy's podcast on systems integration:
