to eliminate these dependencies at once in order to
reduce the complexity of using data sources in gov-
ernmental processes. However, the solution which is
suggested by modularity theory, i.e., the definition of
architectural rules, was not feasible because of the
governmental structure. The different data sources
are controlled by different governmental entities, who
can decide independently on the implementation of
design parameters. Declaring an architectural rule for
a design parameter therefore requires an agreement
between all governmental units responsible for a data
source. However, since most units rely heavily on
legacy systems to provide data services, changes to
the implementation of design parameters are not eas-
ily realized. Therefore, it is difficult to reach such an
agreement if an organization which can impose rules
to these governmental units is not in place.
Consequently, the e-government organization de-
veloped a platform to consolidate data sources and
provide uniform data access. Similar to the PBC
case discussed in Section 3.1, an abstraction layer was
developed to offer the required functionality with-
out exposing the complexity of the layer offering
these services. This abstraction layer provides ser-
vices from the information layer to governmental pro-
cesses, which are considered to be on the functional
layer. The platform is based on two existing data
sources from the federal government. Data from these
data sources will be augmented with data available in
data sources from other governments (e.g., geograph-
ical data, which is offered by regional governments).
The first data source which is used focuses on data
concerning organizations. In this data source, data
such as registration number, official addresses and le-
gal statute of enterprises can be obtained. We will re-
fer to this data source as the Data Source for Organi-
zations (DSO). The Federal Public Service Economy
is responsible for this data source. The second data
source offers data concerning individuals. It refers to
data such as employment and social status of citizens.
We will refer to this data source as the Data Source
for Individuals (DSI). This data source is governed by
a separate organization created by the federal govern-
ment. The platform will maintain this distinction, and
offer its data services grouped in an Enhanced Data
Source for Organizations (EDSO) and an Enhanced
Data Source for Individuals (EDSI).
Since the EDSO relies on the DSO for its data,
and the EDSI relies on the DSI, they need to consider
the implementation of these data sources. Many im-
plementations of design parameters are quite differ-
ent. For example, the DSI has webservices available
to query its data. As a result, these webservices can
be used to develop webservices in the EDSI. These
webservices are not directly offered in their original
form. Instead, a facade pattern is used. This en-
ables the creation of a uniform web service syntax
throughout the platform. Otherwise, a dependency
on the data syntax design parameter would be intro-
duced. In contrast, the DSO has no webservices avail-
able. It is a mainframe which operates using batch
requests. Therefore, a copy is made from the origi-
nal DSO every night. This copy is then augmented
with data from other governmental authorities, and
used as a central database on which the services from
the EDSO are provided. In order to simplify data ac-
cess, the new platform provides three data delivery
methods which will be available for all data sources:
data repositories, an online application and webser-
vices. Customized data repositories are large data
files, which are copied to the process owner. Af-
ter this initial data provision, automatic updates are
transferred when data changes. These repositories are
offered to enable process owners to incorporate the
data from the new platform in their processes, with-
out having to implement a webservices-based data ac-
cess. Since many organizations are accustomed to us-
ing their own data sources in their processes, a cus-
tomized data repository can be implemented without
many changes in the processes. However, the unau-
thorized data sources which have been collected by
the organizations themselves will then be replaced
with authentic data. The online application allows for
manual consultation of the data with a much smaller
granularity: instead of a single large data file, only the
result of a single query is returned. The same result
can be obtained automatically through the use of web-
services. Webservices offer the same data granularity,
but can be implemented to automate processes.
From a modularity perspective, the platform can
be considered as an additional module to eliminate
dependencies between data and process modules. The
DSM for the DUGP project is shown in Figure 5.
When comparing DSM of the platform in Figure 5
with the DSM in Figure 4, we can conclude that some
of these dependencies are indeed eliminated. Con-
sider for example the data syntax and data delivery.
We included an empty grey background to mark the
previous existence of these dependencies. The syntax
of webservices offered by EDSI is decoupled from the
naming conventions of the DSI by using a facade pat-
tern. As a result, naming conventions can be kept in-
ternally consistent with custom-built webservices for
EDSO. The data syntax can be considered as an archi-
tectural rule which is maintained by the e-government
organization. By adhering to this data syntax, process
owners no longer need conversions between different
data syntax versions. Another example is the data de-
BMSD 2011 - First International Symposium on Business Modeling and Software Design
58