As this is my 100th post on my blog, I decided to write an article which is rather different than the previous ones. It was quite difficult to decide the topic for this post as there are so many aspects of the Database Technology that can be discussed. Finally, I decided to write on the significance of integration in software systems of today and specifically on database systems as I find it a very trending topic.
Before proceeding with the article, I would like to express my gratitude to all of you that support my Community efforts by visiting my blog and expressing your ideas via your comments. It is really a great experience when technical discussions are initiated via your comments.
After all, this is the purpose of this blog: to exchange knowledge with fellow members of the broader Technical Community.
Thank you very much for your support!
I hope you enjoy the article!
In these modern times we live in, there are thousands (if not millions) of Software Systems for almost anything that can be automated using different sets of algorithms. These can vary from simple systems that can just be forms allowing data input and reporting, to sophisticated enterprise systems that perform complex tasks such as monitoring other systems and services, reporting on their health, taking corrective actions and so on. In this post I am going to talk about Enterprise Systems and specifically Relational Database Management Systems (RDBMs) within the Enterprise.
In the Enterprise, there is always the need for integration. Integration can be defined as the set of practices and procedures that are used for building large systems that consist of other smaller systems that can be called subsystems.
Having several "isolated" systems in the enterprise cannot be so efficient and can be quite costly both in terms of resources and money, as it increases the administration and maintenance effort. In such cases different professionals deal with each system separately thus making the entire process quite complex as there is always the requirement for collaboration between these systems.Additionally, each system lives in its own world making it difficult to collaborate with other systems.
It is not random the fact that the majority of large software systems in the market, provide Application Programming Interfaces (APIs) allowing their integration with other systems. Furthermore, along with these APIs, you can also find in the market ready-made API implementations for many of these systems. These implementations can be found under different flavors such as: middleware, web services, source code libraries, etc.
In the RDBMS world you can often find these API implementations as Data Providers. To this end, if you are using RDBMS A you can interconnect it with RDBMS B via a provider. The significance of Data Providers is huge!
Some examples of such integrations include: creating a linked server in SQL Server targeting another RDBMS in order to access the data from within SQL Server, retrieving data from different RDBMSs in PowerPivot, building an SSIS package that retrieves and transforms data from several data sources and so on.
With Data Providers, you can do many things. Using these API implementations, the system that supports their usage (host) can never be isolated in the Enterprise, as you can always interconnect it with other systems (guest), in our case, other RDBMSs.
Someone might say: “But why integrating SQL Server with another RDBMS?” Here’s a simple explanation. Consider the scenario where you host a Data Warehouse in SQL Server. Data warehouses typically contain vast volumes of data in order to be able to perform analysis against this data, that is Business Intelligence (BI). An Enterprise environment can consist of hundreds of systems. It is highly likely that some of these systems are built on different technologies and their data is organized in different RDBMs than SQL Server. If you want to load this data and perform BI on it using the SQL Server Data Warehouse engine, how can you achieve that without a set of proper Data Providers? The answer is simple; you cannot do this without a Data Provider! Without Data Providers you will not be able to retrieve data from other RDBMSs. Of course, in real life, most Enterprise systems have their own Data Providers thus allowing access to other systems via API implementations. These providers are developed by either the vendor that owns the “host” RDBMS or the vendor that owns the “guest” RDBMS or both. Most of the times, Data Providers are developed by all the involved vendors.
So, a professional with the required knowledge and by using the Data Providers, can always integrate these systems thus allowing the Enterprise’s operations to run on a more efficient way. This professional needs to have a broad range of database skills, not only restricted on a specific RDBMS, but rather have a breadth of knowledge on all the involved RDBMSs. Of course, the professional can always have an expertise on a specific RDBMS and basic knowledge on other RDBMs in order to be able to perform the integration. After all, besides the additional functionality (which is what that actually makes the difference), the standard RDBMS concepts are implemented in most RDBMSs.
To this end, when evaluating different software systems (and in this case, an RDBMS) that are to be used in an Enterprise environment, it is always vital to ensure that these systems provide API implementations or at least an API that can allow integrating the system with other critical systems within the Enterprise.
As we move forward, we see that the Enterprises become even more demanding on the efficiency of their Software Systems as these are the backbone that supports the everyday operations of the Enterprise. The lack of collaboration between Software Systems within the Enterprise can negatively affect the everyday operations and that is why it is vital that these systems should interact between them via API implementations.
That is why Integration is the Key!
Read more on this article...