Towards Process Orientation in Enterprise Architecture
Management
Philipp Gringel
1
, Jürgen Sauer
2
and Ulrike Steffens
1
1
OFFIS – Institute for Information Technology, Eschwergeg 2, 26121 Oldenburg, Germany
2
Department of Business Engineering, Carl von Ossietzky University of Oldenburg, 26111 Oldenburg, Germany
Keywords: Enterprise Architecture Management, Process Management, Tool Support.
Abstract: In present Enterprise Architecture Management there is a conceptual gap between very complex
methodologies on the one hand and usually methodology-agnostic query-based tool support on the other
hand. As a result, Enterprise Architecture Management is often unable to tap its full potential. Issues for
possible improvement are described in this paper. We postulate the hypotheses that the indicated
deficiencies can be corrected by using EAM tools which consider and model EAM methodologies and their
underlying activities as processes and are able to actively manage, steer and support these processes. Initial
architectural considerations for such a tool as well as a corresponding research roadmap are presented.
1 INTRODUCTION
During the past decade, many enterprises started to
implement enterprise architecture management
(EAM) (Lankhorst, 2005) to tackle increasing
complexity and to better align their IT with their
business (Henderson and Venkatraman, 1993). Since
then many software products targeting the support of
EAM have penetrated the market (Matthes et al.,
2008). The purpose of those tools is to document
and, in particular, to interconnect the different layers
(Winter and Fischer, 2007) of enterprise architecture
within a (potentially distributed) database. Different
stakeholders of EAM can then query this database
according to their respective roles.
To turn EAM into a valuable building block of
business success, however, a sound methodological
knowledge is required, which describes how to
construct, use, assess, and continuously improve
enterprise architecture. Several frameworks like for
example TOGAF 9 (The Open Group, 2009) convey
such methodological knowledge. Yet, the underlying
material is often too comprehensive and diverse for
a direct and intuitive utilization by enterprise
architects. Furthermore, it is a consequential
characteristic of such frameworks, that they have to
be customized to properly fit a specific enterprise’s
context before they can actually be used. Against
this background, today’s EAM tools are suitable to
solve partial EA problems in form of specific
queries and simple workflows. Beyond, EAM tool
usability is restricted to experts who have external
knowledge about EAM methodology and underlying
processes which are not implemented and supported
by the tools.
At the same time, today’s enterprises put a
stronger focus on managament of business processes
(BPM). One reason for this trend is that modern
business process management systems (BPMS)
enable the modelling and analysis of business
processes as well as their straightforward technical
realization, which integrates already existing IT
applications by means of so called connectors. In
most cases, a specific class of processes, for
example customer relations management (CRM), is
initially transformed with process orientation in
mind (Hippner et al., 2004). More and more
frequently, however, it can also be observed that
BPMS represent an important component of
enterprise-wide IT architecture (Slama and Nelius,
2011).
This paper motivates how a process-oriented
view on EAM and in particular a technical support
of EAM processes in EAM tools, can help to reduce
the gap between EAM methodology on the one
hand, and tool support for EAM on the other hand.
The potential overhead costs caused by a BPMS, e.g.
a person has to spend time on the system to
document her progress in the system, are expected to
145
Gringel P., Sauer J. and Steffens U..
Towards Process Orientation in Enterprise Architecture Management.
DOI: 10.5220/0004131101450151
In Proceedings of the International Conference on Knowledge Management and Information Sharing (KMIS-2012), pages 145-151
ISBN: 978-989-8565-31-0
Copyright
c
2012 SCITEPRESS (Science and Technology Publications, Lda.)
be outweighted by the monetary savings produced
on the EAM side by preventing an EA initiative to
choose wrong paths.
We describe existing weaknesses of EAM tools
and explain how these can be reduced or even be
eliminated by an appropiate process support. We
present an initial architectural design to which future
process-oriented EAM tools may refer. Furthermore
we come up with a roadmap consisting of several
open research questions, the solution of which is
either a prerequisite or an important contribution for
adequate realization of process-oriented EAM tools.
The remainder of this paper is structured as
follows: Section two lists issues of possible
improvement for EAM, as it is conceived today.
Section three elaborates on our idea of process
support for EAM and emphasizes where and why
this this process support has to be particularly
flexible. A respective architectural design is initially
sketched in section four. Before this paper concludes
with section six, we present a roadmap of research
activities that have to be carried out to adequate
EAM process support.
2 ISSUES FOR IMPROVING EAM
Recent publications identify a number of still
existing shortcomings in today’s EAM practice.
We’ve experienced similar issues in research
activities as well as in consulting projects. The
following subsections elaborate on these issues.
Later, in section three, we get back to them and
present approaches for possible solutions.
2.1 Insufficient Practices
(Lucke et al., 2010) summarize several EA
weaknesses they have identified in literature. We
partially follow their line of argumentation in this
contribution. According to (Lucke et al. 2010) EAM
initiatives often suffer from a lack of formality in
their definition, realization, and maintenance.
Potential for improvement in EA-/IT-governance is
also attested by (Franke et al., 2010).
(Buckl et al., 2010) investigate EAM from a
knowledge management perspective and come up
with an example for this lack of formality. They
state that the identification, collection, and
maintenance of up-to-date EA data are addressed in
sufficient detail only by few papers. How to
practically gather EA knowledge is not clearly
worked out and described yet.
In business reality, EAM turns out to be a
laborious task. The inherent complexity is not only a
result of internal organizational structures EAM
initiatives have to conform to, but also of the
constant change of the business environment
(markets, regulations, technological innovations,
…). The absence of precision and clarity goes
beyond specific EAM methods. It impacts the scope
of single work packages, which is often chosen too
wide (Lucke et al., 2010) or defined only roughly, so
that results are often too slow in arriving. Like this,
the benefits of whole EAM initiatives might finally
be put into question. To overcome this problem,
EAM activity time schedules that yield for results
within weeks instead of months are highly desirable.
2.2 Complex Coordination
Due to the very nature of of EAM, a new EAM
initiative will typically have implications beyond the
initiating department upon other enterprise divisions.
The integration of different EA layers (Winter and
Fischer, 2007), often reflected by corporate
divisions, requires an increase in communication of
the stakeholders involved (Lucke et al., 2010).
In this context, synchronization and alignment of
enterprise architecture lifecycles with overall
business management lifecycles, e.g. by the means
of project portfolio management, are critical success
factors of EAM (Kaisler et al., 2005). A consequent
management commitment to EAM is essential to an
EA program’s payoff. As stated in (Lam, 2004),
(Postina et al., 2009), and (Shah and El Kourdi,
2007) a lack of rigidity in the implementation of EA
governance can finally even hinder EAM. For more
other possible pitfalls in EA initiatives, we refer to
(Addicks, 2011), (Armour et al., 1999), (Lam 2004),
(Lucke et al., 2010), and (Seppänen et. al., 2009).
2.3 Lack of Measurability of EAM
Success
The quality of an enterprise architecture and its parts
should be objectively assessable utilizing metrics, to
improve the quality step by step. Research has
broght up approaches like (Addicks, 2011) and
(Kaisler et al., 2005). In addition the assessment of
the EAM initiative itself is crucial, because often the
commitment of management and budget depends on
a measurable success. Although there are research
approaches leading in this direction (Gammelgård et
al., 2007), in practice the assessment and the
measurability of EAM success are still far from
mature (Buckl et al., 2010).
KMIS2012-InternationalConferenceonKnowledgeManagementandInformationSharing
146
2.4 Rigidity
A promising EAM approach is meant to be
customizable to the specifics of the respective
company. This requirement is often formulated but
rarely met. It holds true for both the scalability of the
enterprise architecture itself and the tool support
where adaptability of tools is often lacking (Farwick
et al., 2011); (Lucke et al, 2010); (Winter et al.,
2010). Scalability, however, is a success factor,
because an EA is expected to grow and mature over
the years. Among others, (Kaisler et al., 2005) hold
the pragmatic view that only crucial artefacts of EA
should be actually documented. Best practices as
(Buckl et al., 2008) can assist with the choice of
artefacts.
3 PROCESS SUPPORT FOR EAM
Frameworks like TOGAF 9 (The Open Group,
2009), and other publications like for example
(Engels et al., 2007) assume that EAM and its
subtasks are knowledge-intensive processes
(Steffens and Uslar, 2005). Nevertheless, it is
usually assumed for EAM tool support that
stakeholders use the tools to query the integrating
EA repository, with at best tacit methodological
EAM knowledge in their minds. Following this
simple query-centric perspective, several research
works focus on the integration of heterogeneous
information sources within a company (Farwick et
al., 2011); (Fischer et al., 2007), on the database’s
fundamental modelling concepts (Frank, 2002);
(Iacob et al., 2009), on specific data analysis
(Johnson, et al., 2007) and visualization of the
results (Kruse et al., 2009); (Wittenburg, 2007), or
on a combination of the above (Buckl et al., 2008).
All in all, the question of “what” is clearly in the
foreground of such query-based EAM tools and the
related research. The shortcomings we have listed in
section two, however, demand for also answering
the question of “how”, i.e. guidelines and detailed
instructions for EAM are needed. Such guidelines
can be made explicit by the structuring use of
processes.
Since processes of many corporate divisions can
be technically supported by business process
management systems (BPMS), a potential benefit of
process-oriented tool support can also be anticipated
for EAM. The ability of accessing information in a
standard EA repository as given by standard tools
might hence be complemented by process control
delegated to a BPMS. Yet, the shift towards process-
oriented EAM raises a number of challenges with
regard to the flexible process control in a BPMS-
based support system. These challenges are
described in the following subsections.
3.1 Flexible Process Modelling
In the same manner as the documented EA entities,
EAM processes will differ in different enterprises
according to the current state of the underlying EA
and the enterprise-specific problems to be solved by
EAM support. Hence, EAM processes managed by a
process-oriented EAM tool will have to be adaptable
to enterprises’ particular characteristics. Therefore, a
process-oriented EAM tool should not prescribe
fixed EAM processes but can only provide process
templates that are customizable using EAM-specific
patterns (Buckl et al., 2008), complemented by
blueprints or suggestions for adequate reports and
visualizations.
3.2 Flexible Process Execution
As stated above, EAM processes can be regarded as
knowledge-intensive processes, whose execution
benefits from the knowledge of the executing
stakeholders. Therefore, processes within a process-
oriented EAM tool should be adaptable, at least
configurable at runtime by their respective users
(Dadam et al., 2011).
3.3 Flexible Process Schema
The process schema, i.e. the definition of an EAM
process, has to be modifiable, because it can be
expected that process flows will be improved over
time in the sense of evolving best practices. These
improvements have to flow back into the process
schema for future process executions. Analogously
to emergent EAM like proposed by (Buckl et al.,
2009); (Matthes et al., 2011) for EAM entities,
emergent EAM with regard to EAM processes is
likely to develop.
3.4 Addressing Existing EAM
Shortcomings
In section four, we will present an architecture
design draft addressing the mentioned requirements.
This draft is based on current available components
and may serve as a manufacturer-independent
blueprint for process-oriented EAM tooling. At the
same time, it can be used to conceptually identify
still existing technological gaps and hence to define
TowardsProcessOrientationinEnterpriseArchitectureManagement
147
a roadmap with open research questions that we will
elaborate on further in section five. Regardless of an
implementation of the architectural draft, the
process-oriented view on EAM contributes to the
reduction or even elimination of the weaknesses that
we have listed in section two, as we illustrate in the
following.
Precise Definition of Practices. In a process-
oriented EAM tool, the respective EAM processes
are unambiguously modelled and explicitly guide
EAM practice. Stakeholders who execute a process
can deviate from the process schema. Such
deviations can later be channelized in
methodological alternatives. The BPMS component
for process support requires a detailed process
modelling, which allows for a better and more
realistic estimation of size and effort of single EAM
tasks. This leads to work packages with an
appropriate size and to manageable EAM processes.
Coordination. The automated coordination of
different process participants is an inherent
functionality of BPMS and can be done both task
driven and cockpit driven (Slama and Nelius, 2011),
so that stakeholders from different fields of
responsibility can be appropriately involved
according to their individual workload. A BPMS
cannot only support single process steps of EAM
that are intense in communication but little creative,
e.g. collecting data from a large number of
stakeholders. It can also involve the management by
explicitly relating documented IT entities with
management entities and, possibly more important,
by delivering proper information about the current
state of running EAM process instances.
Measurability. Using automatic process control,
the measurability of an EAM function’s success can
be improved in different ways. First, an assessment
of individual tasks can be integrated into the process
schema as an inherent part. Second, against the
background of the enterprise architecture as a whole,
a periodical control of success can be established
and supported as an independent higher-level
process. Third, success control could utilize standard
monitoring and logging features of the BPMS for
statistical analyses.
Flexibility. The above requirements are already
essentials with regard to the flexibility of a process-
based EAM tooling. They can to a great extend be
met by the majority of currently available BPMS.
However, this alone won’t be sufficient, since it
neglects the important aspect of EAM tool
customizability to enterprise specifics. Therefore,
architecture draft for a process-based EAM tool
presented in section four does not only comprise a
BPMS as execution platform, but complements it
with additional components for more flexibility with
regard to enterprise specifics, e.g. with a wiki system
for EA entity and meta model evolution.
4 ARCHITECTURAL SKETCH
In the preceding sections, we motivated process
support of EAM. This section presents an
architectural draft of an enterprise architecture
process management system (EAPMS, cf. figure 1).
EA processes as well as other business processes
of the company are regarded as enterprise-specific
processes. They are composed of one or more
activities that are defined in a certain order, e.g.
sequentially, and are carried out by persons and / or
IT systems.
Figure 1: Architecture of an enterprise architecture process
management system.
The core of the suggested EAPMS is a BPMS,
which assists its users with the definition,
development, and testing of processes. Some
vendors (SAP, BonitaSoft, Inubit) of BPMS rely on
BPMN as process definition language. BPMN
models are more or less directly interpreted and
executed by the BPMS’s core, the engine. After
development and testing of new processes, a suitable
staging mechanism ensures the transition of the
processes from a development via test into
production (final deployment).
Running process instances can be monitored
(addressing 3.4. bullet point three), which provides
information on for example the number of processes
KMIS2012-InternationalConferenceonKnowledgeManagementandInformationSharing
148
handled in parallel by the system, the number of
ceasing processes, or the number of currently active
process instances of a certain type (schema).
Processes can change during operation. Hence,
the BPMS has to provide a means to modify process
schemata during active operation. Process
versioning can be used to have an engine executing
different versions of the same process at the same
time. From a given point in time onwards, only the
latest version of processes is instantiated. Archiving
mechanisms are useful to preserve access to older
process versions and to learn from the execution of
older processes (addressing 3.4. bullet point four).
A work list (or task list) informs a BPMS user
about the tasks she has to fulfill to enable a specific
process instance to progress.
The execution environment of a BPMS that is
responsible for the order and coordination of service
execution is called engine. Depending on the BPMS
used, an enterprise service bus (ESB), more or less
separated from the engine, allows to access systems
that are not part of the BPMS. Services offered by
those systems, e.g. data base operations, can be used
in process orchestration.
Furthermore, BPMS can integrate human
activities, which for example call for more complex
decisions, into a process. Rules of delegation as well
as for escalation can be applied (addressing 3.4.
bullet point two).
In addition to the BPMS, a central meta model is
a key component of the envisioned EAPMS. One
part of the meta model describes the EA itself, the
other part describes the processes to manage the EA
(EAP). This meta model is defined in an enterprise-
specific way and offers extension points to cover
future EAM requirements. Hybrid Wiki systems
(Buckl et al., 2009; Matthes et al., 2011), as
representatives of “Web 2.0” technologies
(“Enterprise 2.0” in Figure 1), offer the chance to
intuitively involve stakeholders into the
development and maintenance of the EA meta
model. This ensures the meta model to remain
relevant to the enterprise (addressing 3.4. bullet
points one and two).
An EAPMS is a socio-technical system and as
such, it explicitly takes the user into account as part
of the system. Web 2.0 technologies may be used to
create a stakeholder-specific user experience, since a
uniform user interface is neither suitable for all
possible roles, nor for all tasks. Mobile applications,
“apps”, deployed on smartphones that are for
example used by managers to approve a process step
while not in office impose different requirements
than portals that are used to interact with the
EAPMS using a web browser to finish tasks
according to the work list. Process developers are
used to work with an integrated development
environment (IDE), which may raise yet other
requirements. An IDE could also be utilized by the
enterprise architect and his team so technically
realize specific EAM processes within the EAPMS.
5 RESEARCH ROADMAP
During the conception of the architectural draft
presented in the previous section, we identified
several research activities that have to be conducted
before process orientation in EAM can be
successfully realized with support of an EAPMS.
We assume there are enterprises that already use
a “classical”, i.e. non-process-oriented, EAM tool
which has to be integrated with our approach.
Existing tools often provide either a rigid meta
model or a minimal meta model, which has to be
customized. The fact that an EAPMS contains an
additional meta model raises the question how to
deal with the most likely different models in both
systems. Adequate alternative solutions would either
be to also base EAPMS on the existing model, to
migrate one model into the other or to dynamically
map the elements of both models. The chosen
solution should be able to preserve the flexibility of
the EAPMS. The similarity of the meta models and
the flexibility of the existing EAM tool could
provide decision criteria for an adequate choice.
Closely related to the question of model
synchronization is the question of data storage. If the
already existing EAM tool is the leading system for
EA related data the EAPMS should be able to use
this data without the need of replication. However,
existing EAM tools themselves also often replicate
data, which makes the synchronization of data more
difficult. Current BPMS use connectors to easily
access external systems, sometimes without
programming effort. Analogously, special EA
connectors could, on the one hand, ease the access to
existing EA systems and, on the other hand,
integrate special EA services offered by external
systems into an overall EAM process. We predict
different integration scenarios with the EAPMS
depending on the meta model and the main focus of
already existing non-process-oriented EAM tools.
When modelling EAM processes in an EAPMS,
one has to weigh out, which activities can be
supported effectively by such a system and which
are potentially too “creative” and should take place
without process support. We expect the support for
TowardsProcessOrientationinEnterpriseArchitectureManagement
149
modelling and execution of ad-hoc processes to
improve in future BPMS – a development from
which an EAPMS would directly benefit. Regardless
of that, it has to be investigated whether and how
EAM processes differ from typical business
processes in their specific characteristics. If there are
fundamental differences, it has to be evaluated if
existing process modelling capabilities are sufficient
to define EAM processes and their specifics.
Existing languages like BPMN 2.0 (Object
Management Group, 2011) have to be evaluated in
this respect and if necessary, “annotated” with EA
specifics. Potentially the design of a domain-specific
language is necessary to meet the requirements of
EA processes. Such a language should be
complemented by an adequate modelling method,
which for example could guide the decision whether
an activity is automatable or not. It should provide
hints for the granularity of activities and for the
categorization of processes. Ultimately, such a
modelling method could also be realized as a higher-
level process, a meta process, in an EAPMS.
Blueprints and patterns can support and
accelerate knowledge-intensive processes. For this
purpose, one can think of a reference model for
EAM processes, similar to industry-specific process
models like eTOM. The reference model would
contain typical EAM processes which could be used
as a basis and be customized according to the
enterprise’s situation.
An often discussed research question in EAM is
the alterability of the meta model and the resulting
consequences for tool support. A change of the meta
model can cause costly and time-consuming changes
in for example reporting and visualization
components. In the sections above, we have pleaded
process flexibility for an EAPMS. This process
flexibility is based on an alterable process schema
and exacerbates the challenge of meta model
alterability, since a changed process schema can
imply meta model changes, and vice versa.
Hybrid wikis have been suggested as a potential
solution for emergent modelling of EA data (Buckl
et al., 2009). The transfer of this concept into the
world of EAM processes has still to be evaluated. It
seems to be promising, to condense successful
process changes or proven ad-hoc processes to new
process schemata.
As part of our research activities, we have started
to realize a sample process, “As-Is-Analysis of an
Application Landscape”, using the software “Bonita
Open Solution”. Particularly, the first steps of the
process (cf. Hanschke, 2009), which are concerned
with data acquisition activities, have been
successfully realized. We chose that process as first
item of evaluation for two reasons. First, it is one of
the typical initial processes executed during EA
initiatives. Second, we have executed As-Is-
Analyses several times in real-world consulting
projects and are therefore well acquainted to process
details. After an As-Is-Analysis has been completed,
and the To-Be-Landscape has been planned, usually
a gap analysis is conducted. As a next step, we plan
to also realize gap analysis on an EAPMS basis. For
this realization, we can fall back to existing
preliminary work (Gringel and Postina, 2010;
Postina et al., 2009).
6 CONCLUSIONS
In this paper, we identified existing drawbacks of
EAM and proposed the concept of process-oriented
EAM as a possible solution. We presented the
architectural draft for an enterprise architecture
process management system (EAPMS), which we
are currently substantiating and refining. Drafting
the architecture revealed a number of open research
questions to be solved for successfully realizing
process-oriented EAM. We have listed these
questions in order to encourage further research and
development work.
REFERENCES
Addicks, J. S., 2011. Bewertung betrieblicher
Anwendungen im Kontext ihrer Unternehmens-
sarchitektur. Dissertation, OlWIR Verlag, Edewecht.
Armour, F.J., Kaisler, S.H., Liu, S.Y., 1999. Building an
Enterprise Architecture Step by Step. IT Professional,
1(4):31–39.
Buckl, S., Ernst, A. M., Lankes, J., Matthes, F., 2008.
Enterprise Architecture Management Pattern Catalog
(Version 1.0, February 2008). Technical Report TB
0801, Chair for Informatics 19 (sebis), Technische
Universität München.
Buckl, S., Matthes, F., Neubert, C., Schweda, C. M., 2009.
A Wiki-based Approach to Enterprise Architecture
Documentation and Analysis. In Proceedings of the
17th European Conference on Information Systems
(ECIS2009).
Buckl, S., Matthes, F., Schweda, C. M., 2010. Future
Research Topics in Enterprise Architecture
Management – A Knowledge Management Perspec-
tive. In ICSOC/Service Wave 2009, LNCS 6275, 2010.
Heidelberg.
Dadam, P., Reichert M., Rinderle-Ma, S., 2011.
Prozessmanagementsysteme. Informatik Spektrum,
34(4):364-376.
KMIS2012-InternationalConferenceonKnowledgeManagementandInformationSharing
150
Engels, G., Hess, A., Humm, B., Juwig, O., Lohmann, M.,
Richter, J.-P., Voß, M., Willkomm, J., 2008. Quasar
Enterprise: Anwendungslandschaften serviceorien-
tiert gestalten. dpunkt.verlag GmbH, Heidelberg.
Farwick, M., Agreiter, B., Breu, R., Ryll, S., Voges, K.,
Hanschke, I., 2011. Automation Processes for
Enterprise Architecture Management. In Proceedings
of the 15th IEEE International Enterprise Distributed
Object Computing Conference Workshops
(TEAR@EDOC 2011).
Fischer, R., Aier, S., Winter, R., 2007. A Federated
Approach to Enterprise Architecture Model
Maintenance. In Enterprise Modelling and
Information Systems Architectures - Concepts and
Applications, Proceedings of the 2nd International
Workshop on Enterprise Modelling and Information
Systems Architectures (EMISA’07), St. Goar.
Frank, U., 2002. Multi-perspective enterprise modeling
(MEMO) conceptual framework and modeling
languages. In Proceedings of the 35th Annual Hawaii
International Conference on System Sciences, HICSS
2002.
Franke, U., Ekstedt, M., Lagerström, R., Saat, J., Winter,
R., 2010. Trends in Enterprise Architecture Practice –
a Survey. In Trends in Enterprise Architecture
Research (TEAR 2010), LNBIP 70, 2010. Heidelberg.
Gammelgård, M., Simonsson, M., Lindström, A., 2007.
An IT management assessment framework: evaluating
enterprise architecture scenarios. Information
Systems and E-Business Management, 5(4):415-435.
Gringel, P., Postina, M., 2010. I-Pattern for Gap Analysis.
In 2nd European Workshop on Patterns for Enterprise
Architecture Management (PEAM).
Hanschke, I., 2009. Strategisches Management der IT-
Landschaft: Ein praktischer Leitfaden für das
Enterprise Architecture Management. Carl Hanser
Verlag, München.
Henderson, J. C., Venkatraman, N., 1993. Strategic
Alignment: Leveraging Information Technology for
Transforming Organizations. IBM Systems Journal,
32(1):4-16.
Hippner, H., Merzenich, M., Wilde, K. D., 2004. Analyse
und Optimierung kundenbezogener Geschäftsprozesse.
In Management von CRM-Projekten, Gabler Verlag,
Wiesbaden.
Iacob, M.-E., Jonkers, H., Lankhorst, M. M., Proper, H.
A., 2009. ArchiMate 1.0 Specification. Van Haren
Publishing, Zaltbommel.
Johnson, P., Ekstedt, M., 2007. Enterprise Architecture –
Models and Analyses for Information Systems
Decision Making. Studentlitteratur, Lund, Schweden.
Kaisler, S. H., Armour, F. J., Valivullah, M., 2005.
Enterprise Architecting: Critical Problems. In
Proceedings of the 38th Hawaii International
Conference on System Sciences (HICSS 2005).
Kruse, S., Addicks, J. S., Postina, M., Steffens, U., 2009.
Decoupling Models and Visualisations for Practical
EA Tooling. In ICSOC ServiceWave Workshops.
Stockholm.
Lam, W., 2004. Technical Risk Management on
Enterprise Integration Projects. Communications of
the AIS, 13(1):291–316.
Lankhorst, M., 2005. Enterprise Architecture at Work:
Modelling, Communication, and Analysis. Springer,
Berlin.
Lucke, C., Krell, S., Lechner, U., 2010. Critical Issues in
Enterprise Architecting - A Literature Review. In
Proceedings of the 16th Americas Conference on
Information Systems (AMCIS 2010).
Matthes, F., Buckl, S., Leitel, J., Schweda, C. M., 2008.
Enterprise Architecture Management Tool Survey
2008. Chair for Informatics 19 (sebis), Technische
Universität München.
Matthes, F., Neubert, C., Steinhoff, A., 2011. Hybrid
Wikis: Empowering Users to Collaboratively Structure
Information. In 6th International Conference on
Software and Data Technologies (ICSOFT 2011).
Object Management Group, 2011. Business Process
Model and Notation (BPMN), Version 2.0.
Postina, M., Sechyn, I., Steffens, U., 2009. Gap Analysis
of Application Landscapes. In Proceedings of the
IEEE International Enterprise Distributed Object
Computing Conference Workshops, EDOCW.
Seppänen, V., Heikkilä, J., Liimatainen, K., 2009. Key
Issues in EA-Implementation: Case Study of Two
Finnish Government Agencies. In Proceedings of the
12th IEEE Conference on Commerce and Enterprise
Computing (CEC 10).
Shah, H., El Kourdi, M., 2007. Frameworks for Enterprise
Architecture. IT Professional, 9(5):36–41.
Slama, D., Nelius R., 2011. Enterprise BPM:
Erfolgsrezepte für unternehmensweites Prozess-
management. dpunkt.verlag GmbH, Heidelberg.
Steffens, U., Uslar, M., 2005. Wissensinfrastrukturen für
ein projektorientiertes Wissensmanagement. In
Wissens- und Werte-Management in Theorie und
Praxis, VDM Verlag, Saarbrücken.
The Open Group, 2009. TOGAF 9 - The Open Group
Architecture Framework v. 9.
Winter, K., Buckl, S., Matthes, F., Schweda, C. M., 2010.
Investigating the State-of-the-Art in Enterprise
Architecture Management Methods in Literature and
Practice. In Proceedings of the Mediterranean
Conference on Information Systems (MCIS 2010).
Winter, R., Fischer, R., 2007. Essential Layers, Artifacts,
and Dependencies of Enterprise Architecture. Journal
of Enterprise Architecture, 3(2):7–18.
Wittenburg, A., 2007. Softwarekartographie: Modelle und
Methoden zur systematischen Visualisierung von
Anwendungslandschaften. Dissertation, Technische
Universität München, München.
TowardsProcessOrientationinEnterpriseArchitectureManagement
151
