## 1 Introduction  
Research of data integration has been active for a very long time and remains ongoing to this day. It is not surprising that data integration has been examined from a multitude of angles. It started with simple ideas of monolithic multi-database systems, then evolved following the popularity of federated systems [1]. The trail continued into architecture-based research with the mediator-wrapper (MW) architecture, which brought some concrete systems into existence [2; 3; 4]. At that point, the idea of NoSQL (not only SQL) systems [5] started to appear. As data were no longer just being stored in relational databases but also in schemaless formats in specialized database management systems and even files, the research community started to express data integration more in terms of data sources. Data exchange/interchange between data sources was also presented as an idea later on [6]. In parallel, ETL (extract-transform-load) processes [7] over multiple data sources for data warehousing also appeared and are to this day an active research topic [8; 9]. Research has currently been exploring the idea of data lakes and how to process such large quantities of distributed, unstructured, and heterogeneous data [10; 11]. The research landscape is also currently shifting toward graph-formatted data [12; 13; 14; 15] and data acquired from the Web [16; 17; 18]. It is clear that the research of data integration is very unlikely to abate, especially as new kinds of potential data sources continue to be created [16; 19; 20; 21; 22; 23]. The research has yet to produce a concrete, freely usable and open-ended data source integration system. In the words of [PERSON] et al. [24]:\"...it is time for data integration operators to break free of end-to-end data integration systems and be available in the open source to speed up adoption and progress.\"_  
_\"The first challenge [...] is that progress of data integration and its application in practice are hindered by the fact that there are very few quality tools with which practitioners and researchers can freely experiment.\"_  
Looking at the research's history in its entirety, it can be assessed that at a certain point, researchers took a well-meaning detour to incorporate more novel systems into the field, forsaking the essentials of tooling that [PERSON] et al. [24] mentioned. It can be observed that the last large enterprise-wide tools for data source integration were created following the MW architecture [2; 4], and that this is a good restarting point. Of course, the scientific landscape has greatly changed since the 1990s. Today, there is also a shift in discussion about the way in which views are created, or how data sources are represented. With reintroducing the MW architecture, great care is taken to conform it to modern and future requirements, making it the conduit for future scientific work regarding data. It is important to note that the MW architecture already conforms to the modern view of architectures as consisting of architectural quanta [25]. This makes it clear that the MW architecture is not a deprecated idea, but one that has been neglected by the scientific community. This paper is focused on the MW architecture for data source integration systems and some of its deficiencies. These deficiencies will be presented through the translation of different types of schemas in the system and how the allocation of these schemas affects the responsibilities of certain types of system components. This will show that some components have additional responsibilities, intruding on a flexible and scalable architectural design and making the system difficult to maintain and administrate. This paper then offers a solution to this quandary and presents the need for an additional component in the MW architecture, which will allow for flexible and scalable system componenization in terms of deployment and component management to ease real-world use. Consequently, this paper introduces the mask component as an additional component to the existing component types.