=Paper=
{{Paper
|id=Vol-3397/maw2
|storemode=property
|title=Enterprise Architecture at Frankfurt University of Applied Sciences
|pdfUrl=https://ceur-ws.org/Vol-3397/maw2.pdf
|volume=Vol-3397
|authors=Carla Hofmann,Sarah Ragowski,Lorenzo Petricone,Wolfgang Kubisch,Jürgen Jung
|dblpUrl=https://dblp.org/rec/conf/emisa/HofmannRPKJ23
}}
==Enterprise Architecture at Frankfurt University of Applied Sciences==
https://ceur-ws.org/Vol-3397/maw2.pdf
Models at Work - Enterprise Architecture at Frankfurt
University of Applied Sciences
Carla Hofmann1 , Sarah Ragowski1 , Lorenzo Petricone1 , Wolfgang Kubisch1 and
Jürgen Jung1
1
Frankfurt University of Applied Sciences, Nibelungenplatz 1, 60318 Frankfurt am Main
Abstract
Similar to many other companies, the IT department at Frankfurt University of Applied Sciences is
responsible for providing and supporting a set of applications that are used by different organisational
units. There are still some insecurities, for example undefined responsibilities, or no clear understanding
about the business fit of the whole application landscape. The current architecture is a result of uncon-
trolled growth, which also leads to missing documentation, as well as a missing Enterprise Architecture
model. The following case study has the objective to analyse and document the Enterprise Architecture
of the university. The purpose of this model is to make the university’s landscape more transparent,
enabling conscious and fact-based decisions for future software applications against the as-is landscape
and relevant needs of the organisation. To achieve this, a Business Capability Map, a Business Object
Model, an Application landscape and a Business Support Matrix were created as artefacts.
Keywords
enterprise architecture, university, BCM, BOM, Application Landscape, BSM
1. Purpose and Requirements
The models were created during a class on Enterprise Architecture Management (EAM) at
the Frankfurt University of Applied Sciences (UAS). Students learned methods and tools for
managing Enterprise Architecture (EA) and had to apply them in a case study assignment. The
case study was conducted together with the IT department of the Frankfurt UAS, known as
Campus IT, as the IT team aims at applying a structured approach for business-driven IT in
the future. Consequently, the head of the IT department participated at the lectures and was
providing input for the case study.
The current situation of the Frankfurt UAS looks quite similar to the one in other companies.
The IT department is responsible for providing and supporting a set of applications that are
used by different organisational units (e.g. central administration and faculties). However, there
are still undefined responsibilities and there is no clear understanding about the business fit of
the whole application landscape. In many cases, the responsibility is seen with Campus IT, as
they provide the applications. But the question arises whether the responsibilities should not
rather lie with the organisational unit or even with the professors who use the applications in
13th International Workshop on Enterprise Modeling and Information Systems Architectures (EMISA) 2023
Envelope-Open carla.hofmann@stud.fra-uas.de (C. Hofmann); sarah.ragowski@stud.fra-uas.de (S. Ragowski);
petricone@stud.fra-uas.de (L. Petricone); wolfgang.kubisch@cit.fra-uas.de (W. Kubisch);
jung.juergen@fb2.fra-uas.de (J. Jung)
© 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License Attribution 4.0 International (CC BY 4.0).
CEUR
Workshop
Proceedings
http://ceur-ws.org
ISSN 1613-0073
CEUR Workshop Proceedings (CEUR-WS.org)
order to ensure clear responsibilities. Furthermore, there is no clear governance for introducing
new software systems so that the current architecture is a result of uncontrolled growth.
Of course, there are various reasons for explaining the current situation, such as legal
constraints or lack of alternatives in the past. Due to the dynamic evolution not everything was
documented properly and an EA model is missing. For that reason, we had the task to analyse
and document the EA of the university.
The main purpose of the model was to make the university’s landscape more transparent,
enabling conscious and fact-based decisions for future software applications against the as-is
landscape and relevant needs of the organisation. It starts with the question of which capabilities
the university actually has. The next question which was addressed is the distribution of
the responsibilities among the organisation. At this point, it is important to find out which
applications are supporting respective business capabilities. This opens the doors for needed
analysis of the application landscape, like investigating for monolithic systems or redundancies.
In addition, it was also a requirement to find the flow between the applications.
The following artefacts were expected as part of the case study:
• Business Capability Map (BCM) as a standard framework for documenting functions at a
university and required applications’ functionality
• Business Object Model (BOM) for classifying data processed in applications
• Application landscape to gain an overview of the applications at the university and their
interactions
• Business Support Matrix (BSM) for documenting applications’ support of business capa-
bilities
During the creation of the model, the analysis was expected to result in an improvement
plan. The improvement plan then could be analysed by the Campus IT, the unit responsible
for the digital infrastructure, to determine the feasibility of certain points. For this work, the
primary audience was the Campus IT and the university management. Beside the Campus IT,
other organisational units, like the digitization department, of the university have an interest in
the final results.
2. Context and Challenge
The resulting models were created in the context of an EAM class at the Frankfurt UAS. Students
worked as a team of enterprise architects, aiming to create an architecture model of the university.
Work started with a case study description referring to the current situation at the university.
The technical context was the case study assignment given by the IT department of the Frankfurt
UAS to provide transparency on the IT department’s application landscape. The main contact
(e.g. the customer) was the head of the Campus IT.
A couple of challenging tasks and uncertainties needed to be handled as the team acted like
enterprise architects but were still in their role as students.
One main challenge was to get all information needed to receive a detailed view of the
application landscape. The lack of information was basically caused by our role as external
enterprise architects with no insight into internal processes and without access to relevant
sources. Necessary information had to be obtained through employees of the university, which
required additional time. The insufficiency of information was also caused by missing documen-
tation in general. In this case, it was not possible to get the required insight from the existing
documentation. Therefore, the only way to obtain the knowledge was through interviews with
employees who know more details about respective applications.
Furthermore, in the application landscape, the business responsibilities and owners are often
unknown or not properly defined, leading to scattered gaps and ambiguities in the models.
Based on the social context of an EAM course at the university, the model was created in a
given period of time (3 months). This limited available time has also made it more complex to
fulfil the task.
3. Activities and Effort
To create the resulting model, it was first necessary to develop a theoretical understanding of
the fundamentals of EAM. For this purpose, research and review of existing EA documents for
higher education were conducted. Furthermore, interviews were performed with the professor,
the client, and employees to obtain information on specific topics which could not be detected
by research. Discussions and brainstorming were also used to develop a common understanding
regarding the model.
Different tools were used for creating the models, such as Mindomo (an online mind mapping
tool), which allows the joint creation of mind maps and is thus a helpful tool for the brainstorming
process. Furthermore, draw.io was used to visualise the different models. The visualization of
the models focused on their contents, which is why they were kept as simple as possible. Excel
was also one of the tools used, especially for the creation of the BSM.
Work started with a Business Motivation model in order to shape a common understanding
of the university and its objectives. It was created using Mindomo so that the team could collect
their ideas remotely. Various sources, including the university’s target definition and strategy,
have been consulted.
As a next step, a BCM and a BOM were created by the team. First versions have been done
with Mindomo, but the team later on switched to other tools. The BCM was influenced by
existing maps and by knowledge about activities at the university. We incorporated the students’
perspective (e.g. teaching, examination management) but also general-purpose capabilities (e.g.
human resources, facility management). Besides the knowledge about this particular university,
other capability maps in the university context have been used as a reference, like the map of
UCISA UK HE model [1]. After having a stable version, the capabilities have been transferred to
an Excel template. This can be handed over to the customer and used as a common repository.
Furthermore, information on software applications including description and responsibilities
(e.g. contact information) have been added to the Excel template.
After completing data gathering, a BSM (showing applications supporting respective busi-
ness capabilities) has been created by inserting a pivot table. It was used for visualising and
analysing application support at the Frankfurt UAS. Since Excel has only limited capabilities for
graphical formatting, a business capability tree has been created with draw.io. This resulted in
redundancies, but was necessary for an adequate presentation in PowerPoint.
Each model’s validity was evaluated and validated by the professor and the client through
student submissions and presentations. These submissions happened multiple times during the
semester, in order to present the progress and get feedback. In addition, the final results were
presented to the chief administrative officer of the university, one of the key stakeholders. For
this purpose, after setting a date, a presentation was created which was adapted according to
the target group, the stakeholder, in order to present the developed contents to him. Through
his feedback, the results could be validated one more time and the relevance of the topic became
clear once again.
4. Resulting Model
In this chapter, the resulting model will be presented. The models are the BCM, the BOM, the
application landscape and at least the BSM. However, they will not be shown in their entirety,
but excerpts will be. The models originated from a project at the Frankfurt UAS and their
original language is German. For this work, parts were translated into English.
Throughout the images, the colours were used to indicate to which category some elements
belong. Blue is for guiding, green for core and yellow is for enabling. Guiding means that the
capabilities define somehow how the business has to develop. It contains the leading functions
of the university. The capabilities generating added value are categorised as core, whereas
non-added value creating categories are called enabling. Enabling is also known as supporting,
meaning that they are needed for the business, but are not central. These concepts, how they
were used in this work, were inspired by Roger Burlton [2].
4.1. Business Capability Map
The BCM documents the business functions of the university (e.g. what is done at the university).
It is organisation agnostic, this means that no individual departments or organisational units
are reflected. However, there might be cases where the capabilities overlap with departments.
The capabilities were categorised as guiding, core or enabling.
The excerpt seen in Figure 1 from our findings shows the core capabilities (level 1) like
research and the underlying capabilities (level 2) like publish. As research is a vital part of a
university’s portfolio, it was assigned to the core capabilities. The same holds true for teaching.
Also, student administration and student counselling have an important role and are directly
adding value. A maybe controversial decision we made is to put IT Management into core. The
operation, maintenance, and other administrative tasks of applications are a direct-added value
for all employees, students and other parties alike. This shows how essential these capabilities
are for a modern university, making it a perfect candidate for core.
In the following few lines, some level 2 capabilities whose meanings are ambiguous are
described in more detail. First one being research program development. Before the research
can be conducted, the feasibility and the way the research will be conducted, the framework
and the details are determined which happens during the development of the research program.
Second, the research administration manages all research that is planned or done at the university.
Third, in student administration, application management refers to the management of potential
students who have applied to study. In the next steps, new or already existing students are
Figure 1: Capability Map – Core Capabilities
divided into their respective courses and exercises. Finally, grades are assigned to individual
students at the end of the semester, which is done with performance management. At the end
of a student’s studies, the degree is distributed, depicted above by degree distribution.
Here we also want to emphasise that there is not only one possibility to categorise these
items. Above it was mentioned that IT Management fits well into the core capabilities. The
reason for that was the direct-added value to the university. There might be other capabilities
that some would put into other categories. One could possibly see course administration as core
capability. However, these capabilities are setting the direction or the strategy of the course.
This was for us a clear indicator for a guiding capability. To break it down, we basically asked
ourselves three questions for categorising the capabilities into the three categories. Guiding:
Does it define how the business develops?, Core: Does it add direct-added value?, Enabling: Is
it needed, but is not central?
4.2. Business Object Model
This type of model depicts the so-called business objects of the Frankfurt UAS. Furthermore,
the relationships between the single objects are drawn to make clear how they interact among
each other.
In the example shown in Figure 2, one can see a small section of the BOM. Here, some core
business objects of the Frankfurt UAS are shown. To make this graph easier to understand,
especially in later analysis, the objects were coloured in the colours of the three capability
categories in which they occur most frequently. This may not be confused with the capabilities
themselves, but should show that these business objects correlate with the business capabilities.
For example, the business object teacher is connected to the capability event execution, which
is a core business capability. Like a teacher, a student is also an entity interacting with other
business objects. This can be the application for a study course or the usage of the consultation
offer. Each business object can be specified by attributes, for example, the business object
student can be described by the attributes name, date of birth and matriculation number.
Figure 2: Business Object Model – Excerpt
4.3. Application Landscape
The next step was to list the applications at the university and depicted them in a chart. In
addition to that, data flows were drawn with the business objects as data. This makes sure to
gain an overview of the applications and their interactions.
For brevity reasons, this shwos also only an extract of the complete model. The first diagram,
as seen in Figure 3, shows the data flow from the e-learning platforms, campUAS and Moodle,
to embedded applications. campUAS is a second Moodle instance, hosted by a different provider
and will replace the old Moodle instance. Panopto is a video streaming system and Speexx
Campus is an interactive platform for learning languages. The data is exchanged, in order for
the users to watch and upload videos or save progress in their language learning activities.
The second graph, as seen in 4, is a depiction of how data is passed between various library
systems. The library management system is used to manage the locally available books and
media. DBIS and hebis-Portal are online databases for books, which can be accessed by students.
In order to access the databases, the Library Management Tool therefore exchanges data with
DBIS and hebis-Portal. Furthermore, the Library Management Tool can show a list of the other
two systems’ inventory.
Figure 3: Data Flow E-Learning Platforms
Figure 4: Data Flow Library Systems
4.4. Business Support Matrix
At this point, it is important to bring the gathered information together in order to get a
better picture of the university. This is done by creating a BSM, where the capabilities and the
applications are joined. With this tool, it is possible to recognise redundancies and monolithic
systems in the structure.
The following excerpt from the BSM in Table 1 summarises the applications used in the core
capabilities, indicated by an x. The analysis, for example, shows that there are redundancies in
the course division. This capability describes the administration of the students on who will
be assigned to which course or practice lessons. As Moodle and campUAS are both used as
e-learning platforms, one could be removed from the stack. From previous knowledge gathering,
it is known that Moodle is replaced by campUAS, meaning this redundancy can be ignored at
that place. However, what could be improved is the usage of HISQIS, a university information
system used university-wide for all students and all examination offices, as it is a monolith.
For example, whether HISQIS should necessarily be used for students’ applications has to be
evaluated in the next steps.
Table 1
Business Support Matrix - Core Capabilities Excerpt
Application
Business Business
campUAS Confluence GitLab HISQIS Moodle Zoom
Capability (Level 1) Capability (Level 2)
IT Security
IT Management
Management
Operation and
x
Maintenance
Tool Supply x
Research Publish
Research
Administration
Research Conduct x
Research Program
Development
Student Application
x
Administration Management
Course Division x x x
Matriculation /
x
Exmatriculation
Performance
x x
Management
Student
Career Counseling x
Counseling
Counseling for
Stays Abroad
x x
and for
Students Abroad
Course
x
Counseling
Psychosocial
Counseling
Writing
x x
Counseling
Degree
Teaching x
Distribution
Event Execution x x x x
Event Planning
Exam Execution x x
Exam Planning x
5. Return on Modelling Effort
Even though the students worked on the project as part of the examination of an EAM class,
the case study addressed the EA of the university and the head of Campus IT was involved
as a customer. In this role, the task was to provide information on the current situation, to
clarify open questions and to explain connections and decisions from the past. It should be
emphasised that due to decentralised structures, many decisions in the past were not made from
an economic point of view and are, therefore, difficult for outsiders to understand. The aim was
to bring these points into a comparable form of presentation and to document them. The task
of the consultants (i.e. students) was to create a basis using existing material, to complete the
documents through cyclically recurring coordination rounds with the head of the IT department
and to bring them into comparable and easily understandable form of presentation. The level of
detail can be increased almost indefinitely by the frequency of the recurring votes.
The benefits are difficult to express in measurable terms, but gaps or unexplainable duplica-
tions were already revealed in the first appointments. The neutral view from the outside has
awakened the internal focus. In the course of the project, a clear presentation of requirements
and solutions in the form of applications gradually emerged. Missing relationships or duplicates
can be presented in a simple form so that third parties can identify gaps or discrepancies without
much explanation. With a completion and final sharpening, these documents can be the basis for
financial decisions at management level as well as the strategic orientation of the IT department.
As the last act, there was a joint meeting between the advisory group, the previous customer
representative and the chancellor of the university, whose field of activity includes IT. During
this meeting, the basic idea as well as specific areas of investigation and recommendations for
action were presented. In just 30 minutes, the chancellor could be shown that this is an easy-to-
use tool with great power in terms of controlling the IT application landscape. Ultimately, this
meeting can be the decisive point for the establishment of IT architects at the university.
6. Reflection
The task of creating an EA model of the university gave us insights on why to make the effort
to create such documentation. It made it clearer why it is so important that the business side
and the IT side work together, as otherwise the two might diverge. That divergence could cause
problems in the future and make it costly to align both sides again.
Listening to other fellow students in the course faced with similar issues, one could see that
there is more than one possible approach to solve them. The understanding that there is not
only one right solution is important. This is also what the professor and the client indicated at
the beginning of the course. Although both had a vague vision of what the result might look
like, they were open-minded to unexpected solutions too. However, this uncertainty of what
the model should look like was a challenge that we were confronted with and had to learn that
there is not only one solution.
One of the biggest challenges was the search for the responsibilities for applications, business
objects and capabilities. Once the responsibility was found, questions about the used systems
could be asked. This also touches another obstacle we faced, which was finding systems and
applications used at the university. We had to find out all this information by asking our
professor and the customer (e.g. head of the Campus IT) or by researching on the internet.
Not all details or information could be found on the website, so we were also given some
documentation, which could not be accessed by students. This highlights an aspect which has
to be fulfilled in order to create a more valuable model, which is the unrestricted access to
resources and documentation about the used systems. Without it, important information might
be missing in the final model, which could lead to wrong assumptions in the later analysis.
At last, we saw that all these challenges do not exist only at our university, but are universal
to most institutions and companies. We came to this conclusion, not only from the experience
our professor shared with us, but also by abstracting single concepts and recognising them in
the context of businesses in general.
Finally, we hope to spark a discussion on how to analyse other institutions of higher education.
Maybe, our work could even act as a template, especially for the capability map, as other
universities’ maps seemed to be too individual to have common ground. We also found too
little literature on the creation of capability map in the context of universities, making this work
a well suited starting point. Furthermore, we showed a detailed and creative approach and how
to decide on some specific capabilities’ categories. One could even spot parallels to companies’
maps.
7. Evidence
While creating the resulting models, information of different sources was used. The main
sources were existing documentation from the Frankfurt UAS, for instance the official university
website and internal documentation intended for all members of the university. For example, the
application landscape with the applications at the university and the data flows between them
were mostly filled through the information from these two sources. As already mentioned, we
did not have access to all internal documents or in some cases the documentation was missing
in general. In these cases, the information source was through interviews with employees who
know more details about it. Therefore, during the creation of the models, we had interviews
with the head of the IT department, the lecturer of the class and the secretary of the computer
science teaching unit.
In order to validate the results, there were a number of meetings regarding the progress of
the created models with the lecturer and the head of the IT department during the creation
period. In these meetings, the current status of the models was presented, feedback was given,
and changes and further ideas were discussed.
At the end of the course and when all models were completed, the models were presented to
the chief administrative officer of Frankfurt UAS as one of the key stakeholders of the results.
The chief administrative officer agreed with the results and thus also validated their accuracy.
He also mentioned the relevance of the resulting models for the university, and moreover he
thought of how and where to use them to improve the application landscape of the university.
References
[1] UCISA, Uk he capability model - for the he sector, 2022. URL: https://www.ucisa.ac.uk/
Groups/Enterprise-Architecture-Group/UK-HE-Capability-Model.
[2] R. Burlton, Developing your capability architecture: It’s all about being able to get things
done, 2017. URL: http://www.brcommunity.com/a2017/b927.html.
A. Business Object Model with the business objects of the Frankfurt UAS as well as whose
relationships.
B. Business Capability Map with the business functions of the
Frankfurt UAS.
C. Application Landscape with the used applications at Frankfurt UAS and the data flow
between them.
C.1. Data flow between different applications for administration.
C.2. Data flow between different applications for authentication and contact exchange, as well as for source
management.
C.3. Data flow between different applications for digital teaching and for the library.
C.4. Data flow between different applications for invoice and evaluation, and the applications with no data
flow.
D. Business Support Matrix, where the capabilities and the applications are joined, to
recognise redundancies and monolithic systems.