Towards Strategic Information Systems Change Management
Rūta Pirta
Institute of Information Technology, Riga Technical University, Kalku Street 1, Riga, Latvia
1 INTRODUCTION
Enterprise architecture (EA) represents an
enterprise’s operating and business model, including
several interrelated layers (domain/view specific
architectures, for example, application architecture,
information architecture, technology architecture).
The layers consist of elements that are constantly
changing, because of business environment
dynamics, business processes improvement, new
technologies, changes in the regulations and other
internal and external factors that influence an
enterprise. As these layers are interrelated, changes
in elements of one layer affect elements in other
layers. The changes in enterprise business processes
cause modification of enterprise Information
Systems (IS), for example, new functionality,
updated existing functionality and new interfaces.
These modifications can be systematically managed
following an engineering change management
(ECM) process. The ECM process guidelines in
accordance with the best practices are defined and
described in several international methodologies and
frameworks. However, empirical observations made
by the author in different enterprises and state
institutions and several research works (Hanschke,
2009), (Erlikh, 2000), (Goknil et al., 2014) share an
opinion that IS changes are not always handled
properly and their impact is not fully understood.
Nowadays, the one of the major problem is that
failure to comprehend the wider impact of the
changes frequently results in sub-optimal
architectural decisions having particularly adverse
effect on EA (Tang and G.lau, 2014). The wrong
architectural decisions cause inefficiencies such as
poor IS performance, wrong interfaces, bad data
quality, doubled data input and sub-optimal IS
support to business processes. The importance of
adequate change governance is highlighted in
several research works (Pulkkinen, 2006),
(Diefenthaler and Bauer, 2013), (Hanschke, 2009),
(Lautenbacher et al., 2013) and also by an empirical
evidence. Pulkkinen (2006) emphasizes that finding
the right strategies for ICT investments and the
implementation of any technologies takes careful
planning at the managerial level. Both private
business and public organizations face the
challenges of rapidly evolving technologies and
business environments.
In this paper the initial idea of strategic IS
change management using EA landscapes and EA
risks and goal domains is proposed. The envisioned
approach will suggest comparing different EA
landscapes (existing landscape, planned landscape
and ideal landscape) to evaluate changes, their
impact on related processes and data flows and to
generate architectural recommendations about
implementation of the changes in EA to meet the
ideal EA landscape. The main focus of this paper is
the problem domain analysis, what includes an
overview of the related research and exploration of
motivational examples drawn from empirical
observations made at several companies and state
institutions. Based on the problem domain analysis,
a preliminary solution design is performed by
defining the relevant concepts and future research
questions to be explored.
The rest of the paper is structured as follows.
Section 2 provides brief background information and
reviews the related work. Section 3 states the
research problem and reports the motivational
examples observed in practice where suboptimal
architectural decisions are taken. Section 4 includes
outline of the research objectives and section 5
includes the planned research design. Section 6
identifies the current research stage. Section 7
defines the expected outcome. The paper closes in
Section 8 with the conclusions.
2 STATE OF THE ART
Engineering change (EC) and its management
(ECM) have several definitions, according to (Jarratt
et al., 2004), an engineering change is an alteration
made to parts, drawings or software that have
already been released during the product design
process. The change can be of any size or type; the
change can involve any number of people and take
any length of time. Wright (1997) also defines EC
3
Pirta R..
Towards Strategic Information Systems Change Management.
Copyright
c
2015 SCITEPRESS (Science and Technology Publications, Lda.)
similarly: “An EC is a modification to a component
of a product, after that product has entered
production”. ECM refers to the organization,
control, and execution of engineering changes
(Jarratt et al., 2011) and covers the product life cycle
from the selection of a concept to the wind-down of
production and support (Hamraz et al., 2013). IS are
subject to EC as a part of the overall EA.
EA and its management are topics receiving
ongoing interest from academia, practitioners,
standardization bodies, and tool vendors (Buckl and
Schweda, 2011). The Open Group (2009) defines
EA to be „A coherent whole of principles, methods,
and models, that are used in the design and
realization of an enterprise’s organizational
structure, business processes, IS, and infrastructure”.
According to (Pulkkinen, 2006), EA is a well suited
tool for interconnected planning of business
strategies, models and structures, and IT
architectures. EA can be used for analysis in
different ways and thus can support the decision
making process that has to cope with an increasing
number of changes, the clarification of the extent of
changes and the complexity of these changes
(Lautenbacher et al., 2013). Previous investigations
(Pulkkinen, 2006), (Armour et al., 2006), (Armour et
al., 1999), (Armour and Kaisler, 2001), (META
Group Inc., 2002), (Spewak, 1993), (Wegmann,
2003) show that a better governance of IT
architectures and the whole organizational ICT both
in large private companies and in public
organizations can be ensured with the EA approach.
EA includes several dimensions/views/layers
(further in this paper referred as layers). The four
layers that are usually considered in literature are
(Pulkkinen, 2006):
1. Business Architecture (BA). BA depicts the
business dimension (Business processes, service
structures, organization of activities).
2. Information Architecture (IA). IA captures the
information dimension of EA; high level
structures of business information and, at a more
detailed level, the data architecture.
3. Systems or Applications Architecture (SA/AA).
SA/AA contains the systems dimension, the
information systems of the enterprise. Some
conventions call it the Applications Architecture
or Portfolio, the latter stressing the nature of the
information systems as a business asset.
4. Technology Architecture (TA). TA or the
technology dimension covers the technologies
and technological structures used to build the
information and communication systems in the
enterprise.
Other frameworks such as the Zachman framework
and TOGAF include additional dimensions/views/
layers, for example, people, time, motivation.
In the recent years, the interdisciplinary topic of
EC and ECM has gained increasing popularity
within systems engineering benefiting also from the
rise of attention towards concepts such as concurrent
engineering, simultaneous design, product platform
development, mass customization, and configuration
management (Hamraz et al., 2013). According to
(Hamraz et al., 2013) the goals of ECM are to avoid
or reduce the number of engineering change requests
(ECRs) before they occur, to select their
implementation effectively when they occur, to
implement required ECs efficiently, and to learn
from implemented ECs.
Hamraz et al., (2013) identify 348 journal
articles and conference papers and 43 books, book
sections and reports about ECM. The ECM research
covers several research lines, including strategies
and methods to cope with EC. According to
(Hamraz et al., 2013) ECM researches can be
categorized in different areas (strategic guidelines,
ECM systems, impact analysis, ECM process etc.).
EA has been used as one of the methods for
systematic ECM works to analyse the IS and/or AA
changes and related architectural decisions
(Lautenbacher et al., 2013), (Hanschke, 2009).
These investigations mainly focus on gap analysis
between planned changes, e.g. planned EA
landscape and ideal implementation of IS changes in
EA, e.g. ideal EA landscape.
The gap analysis between different EA states
with the aim to support architectural decisions
related to IS change management and
implementation in EA is investigated by
(Lautenbacher et al., 2013), (Gringel and Postina,
2010), (Postina et al., 2009), (Diefenthaler and
Bauer, 2013). The term “gap analysis” is used in
context of enterprise architecture as a name for the
comparison between two architectures or strictly
speaking two states of the same architecture. The
Open Group (2009) Architecture Framework
(TOGAF) uses the terms of baseline- and target
architecture for these two states.
The approach described in (Lautenbacher et al.,
2013) uses the graph theory for analysing
differences between existing EA and target EA.
Research focuses on how to achieve the target rather
than on what the target should look like. It include
the planning process with focus on the application
architecture only, i.e. the IT applications and IT
services used to exchange data.
Diefenthaler and Bauer (2013) propose a method
ICEIS2015-DoctoralConsortium
4
that shows how the gap analysis can be performed
on two high-level EA models representing the
current and target state of an EA using semantic web
technologies. The proposed gap analysis results with
identified gaps and successor relationships what can
help to lead migration from the current EA state to
the target EA state. Ontologies are used to represent
and to reason about the architectures. The EA states
are compared in the ontology redactor Protégé.
Postina et al., (2009) and Gringel and Postina
(2010) present a tool supported approach for
performing a gap analysis on a current and ideal
landscape. Tool can compare two landscapes, -
current landscape and ideal landscape and provide a
list of the actions that needs to be done to reach the
ideal landscape. Gringel and Postina (2010) focuses
on the problem of performing a gap analysis
between two states of the application landscape,
where the current state has a pre-SOA status and the
envisioned state should be designed according to the
principles of Quasar Enterprise. In the paper is
compared the current (non-SOA landscape) with the
ideal (Ideal – SOA) landscape. The main idea of
paper is to find the answer of the question “How do I
need to restructure the current application landscape
to converge towards an ideal application landscape
designed according to the principles of Quasar
Enterprise?” In the paper the quantitative and
qualitative metrics are created to measure the
distance between the current EA landscape to ideal
EA landscape. The research mainly focuses on how
to restructure the current landscape to meet the ideal,
not how to evaluate IS changes to take the right
architectural decisions with the aim to meet the ideal
landscape. Also, before the analysis, both, the
current EA landscape and the ideal EA landscape,
needs to be created manually by the analyst and
imported into the tool.
To summarize, the proposed approaches for gap
analysis mainly cover the analysis of different EA
states (i.e., how to achieve that change will be
aligned with the ideal future EA). However, creation
of the ideal EA landscape is an open challenge.
3 RESEARCH PROBLEM
As already mentioned IS are changing continuously
according to the changes in enterprise business and
operating models and other internal and external
factors that influence the enterprise. One of the
major problems in the ECM process is that changes
are not planned, evaluated, controlled and
implemented (i.e. governed) appropriately resulting
in sub-optimal architectual decisions. Besides that,
the change management usually requires large
investments. The size and complexity of IS makes
the change management costly and time consuming.
3.1 Motivational Examples
The importance of adequate change governance is
also evident in several motivational examples
observed in practice. This empirical evidence is
gathered by working with several Latvian
enterprises and state institutions. It shows that
suboptimal architectural decisions are taken in the
ECM process. Mainly these suboptimal decisions are
made because of an inappropriate change
management, for example, lack of modelling,
inappropriate system analysis, lack of change impact
analysis or insufficient economical assessment.
The typical problems arising from inappropriate
ECM and leading to suboptimal EA are summarized
in Figure 1. The causes are grouped according to
their affiliation to the EA layers. They are observed
in different IT consulting projects during the last
three years.
Figure 1: Typical EA problems.
In order to illustrate these typical problems and
effect of wrong architectural decisions, empirical
observations made in four enterprises are presented.
The observations are made in the following
cases/projects:
1) Cases PCD.01. and PCD.02. were observed
during the IT strategy development project for a
Latvian forestry company (referred as FORG).
FORG is a relatively young company.. It
manages commercially usable forests and,
alongside with the forest management that
includes timber selling, the company engages in
other kinds of activities as well.
2) Case PCD.03. was observed during the ITC
strategy development project for a Latvian
utilities company (referred as UTL). UTL is a
mature organization. It provides different utilities
TowardsStrategicInformationSystemsChangeManagement
5
services throughout Latvia.
3) Case PCD.04. was observed during the IS
conception definition in a Latvian state
institution (referred as FYD).
4) Case PCD.05., was observed during the future
EA definition project in a Latvian state
organization.
The brief description for each case is provided,
inefficiencies in EA and the EA layers affected are
identified and reasons of these inefficiencies are
analysed. The cases are analysed from the change
management perspective.
3.1.1 Geographic Information System
Performance Problems (PDC.01.)
The Geographic information system (GIS) was used
in the medium-size Latvian forestry company
FORG. Although traditionally the main GIS
objective is to visualize geospatial data, FORG took
a decision to implement in the GIS a Felling
management module what includes the following
functionality: felling timber evaluation, felling
timber data management, reporting, logging
instructions maintenance, felling workflows
management etc. The reporting functionality was
implemented in GIS although at the same time
FORG used a BI tool for centralised reporting. The
GIS high-level conceptual architecture is presented
in Figure 2. According to the expert evaluation, the
gap between the existing EA and an ideal EA is
highlighted. It shows that the Felling management
module although satisfying the additional
functionality requested by the users was
implemented inefficiently from the architectural
point of view.
Figure 2: FORG GIS functionality gaps.
As the result of the described architectural
decisions, the following problems were identified:
FORG constantly had more than 100 outstanding
change and problem requests regarding different
corrections/additions in the GIS (estimated to
reach 9 man years labor).
The GIS performance problems were identified:
system’s response time in regional offices
reached several minutes.
The GIS functionality was partly doubled in
others FORG IS and the overall FORG AA
integration level was low, so the same data must
be input in several IS, what resulted in poor data
quality.
Because of low data quality, the BI tool was also
used just partially - only for operational purposes
rather than for business analysis.
Information security risks – the operational data
was partly stored outside the system (temporary)
due to the performance problems. The
inappropriate data storage can lead to
unauthorized access risks. As not all operational
information was stored in the GIS database, the
data backups were made only partly what can
lead to the data loss.
The following EA layers were affected:
BA – more than 15 FORG business processes did
not have adequate IS support to perform them in
a time-effective manner;
AA – similar functionality was not concentrated
in a strategic IS while some the centralized tools
were not used in appropriate capacity.
TA – GIS IT infrastructure was designed to
provide traditional GIS functionality and, after
the new functionality was added and the amount
of transactions increased significantly, it was not
able to ensure system’s continuous operation.
3.1.2 Ineffective Human Resources (HR)
Management Business Processes
(PDC.02.)
FORG used an “of-the-shelf” enterprise resource
planning (ERP) system, what originally provided
also a HR management module. However, the
module was not implemented and FORG used a
separate HR system for HR management purposes.
The HR system had a “self-service” functional
block, where employees can see and update their
own employment data and also plan vacations.
Although, according to the best practice, it is
recommended to centralize similar functionality in
ICEIS2015-DoctoralConsortium
6
one IS, FORG took decision to implement the
vacation management (requesting, approving etc.)
functionality a Document management system
(DMS) rather than in the HR system.
As the result of the described architectural
decisions, the following problems were identified:
FORG employees need to plan vacations in the
HR system’s “self-service” module, but requests
and approvals are handled in DMS, what made
the process less transparent and ineffective.
Both systems were not integrated, so the users
needed to set vacation statuses manually in the
HR system, when the approval from their
supervisor was received in DMS.
The following EA layers were affected:
BA – the HR management business processes
were not effective, FORG employees needed to
perform several manual activities although
FORG did have IS supporting the processes.
AA – similar functionality were not concentrated
in strategic IS. The IS development and
maintenance costs also were higher (comparing
with the case if the HR module had been
implemented in the ERP system).
IA – the FORG HR data structure and quality
was suboptimal.
In both FORG’s cases (PDC.01. and PDC.02.) the
functionality, what was not aligned with the
system’s design and usage objective, were
implemented. Besides that, AA development goals
were not considered what resulted in suboptimal
architectural decisions. Mainly, these decisions were
made because of inappropriately evaluated change
requests. At time of the project, FORG had more
than 280 outstanding change requests. The company
does not have such a position as Enterprise architect
or Information systems architect. All change
requests are divided in three groups (changes/IS that
are related to manufacturing processes, changes/IS
that are related to new products and changes/IS that
are related to planning processes) and evaluated by a
separate programme manager. The main problem is
that each programme manager evaluates changes
that are included in his programme but the common
view on all FORG changes, their relations and
impact to the current and future EA is missing. It is
also observed that the economic assessment is not
performed (for example, even for large IT
investments business cases are not written), so there
is a risk that IT investments are not cost-effective.
3.1.3 Cost-ineffective Solution
Implementation for Workflow
Management (PDC.03.)
To better manage industrial business processes and
related workflows, the UTL decided to implement a
workflow management system. Although UTL had
already implemented a network information system
what also included network related workflow
management functionality and was widely used in
several UTL’s units, the company decided to
implement a new system. Besides the network
information system, UTL also had a local workflow
management system in one of the units, what was
used to manage unit specific workflows and related
documentation. The new system was chosen by
centralized IT function representatives. The solution
was rated by Gartner as a one of the leading
industrial workflow management systems for
utilities companies, however, the system’s standard
functionality significantly exceeded UTL business
needs.
As the result of the described architectural
decisions, the following problems were identified:
Users were not satisfied with the system, so the
system usability was low. The end users were
perplexed by myriad of features and un-needed
data input fields;
Improper system’s usage because of unneeded
functionality;
The solution capital expenditure was high, as the
solution was designed for complex asset and
workflow management.
The following EA layers were affected:
BA – industrial business processes management
was cost-ineffective;
AA – similar functionality were implemented in
three different systems because the existing
systems were not terminated. Besides that the
unit specific workflow management system had
performance problems, because it was not
originally intended for industrial documentation
management.
Although UTL had the centralized IT function and
the ITIL compliant change management process was
implemented, UTL did not develop the IT
investments business cases and IT management did
not asses if the IT investments value is optimal.
Besides that UTL did not analyse possibilities and
potential of the existing systems that provided the
similar functionality. Thus, the overall AA analysis
was not performed at an appropriate level. A unified
TowardsStrategicInformationSystemsChangeManagement
7
UTL IT strategy was also missing and the AA
development goals were not set.
3.1.4 Ineffective Information Flow
Management (PDC.04.)
FYD had several departments with different
functions and locations. According to Latvian
regulations, every department is responsible for
providing citizens with different kind of information.
The information concerns different data entities and
is presented in various data formats. FYD had
established a unified EA and its development vision
including the IT strategy. The IT function was
centralized and IT governance processes were
implemented (following the ITIL guidelines). The
unified AA included also a centralized customer
portal and a content management system (CMS).
Nevertheless every department had decided to
implement at least one citizens facing web site with
different design and navigation. These web sites
were not linked with the portal and there are no
integration among them. The unified CMS system
was not used. Additionally, geospatial information
was published in the web site in a static format (for
example, the .jpg maps) although an interactive GIS
system for serving end-users was implemented.
As the result of the described architectural
decisions, the following problems were identified:
Suboptimal information flow management due to
the decentralized information maintenance and
locally needed IT competence to publish
information on the web sites;
Partial usage of the GIS system’s data publishing
functionality;
Data security risks due to the decentralized web
sites management (lack of IT competence in
departments).
The following EA layers were affected:
BA – the FYD functions what required the
information management processes were
ineffective, because department-specific
information mostly were kept locally and shared
with other departments on request, what makes
the process time-consuming. This was a major
issue because the FYD functions are interrelated
and data must be shared to perform them
correctly. This influences citizens’ wait time in
the case of citizen facing functions.
AA – the CMS functionality were not fully used
and the locally published data were mainly kept
in spreadsheet files.
IA – the FYD data structure was suboptimal with
redundant data input.
The FYD change management process had
shortcoming looking from the organizational aspect.
The FYD had strictly separated holders of
information resources (IR) (business units) and
holders of technical resources (TR) (IT unit). Each
FYD department were responsible for their own data
and its publishing, so the unified view of
organization’s IA was missing. The architectural
decisions were taken without complex EA analysis,
too.
3.1.5 Time Consuming Access to Electronic
Services (PDC.05.)
Similar problems are also observed in nation-wide
governmental IS when state’s ICT infrastructure and
services are viewed from the EA. An Eastern
European country (referred as CTRY) is providing a
wide range of e-services both at state and
municipality level. Usage of e-services at the
municipality level varies significantly. Major cities
offer a wide range of different e-services and their
usage increases constantly while the usage of e-
services at small municipalities is low. Although the
state provides a shared e-services platform, what
constantly updates and where many state and also
municipalities e-services are deployed, the
municipalities also tend to other platforms. The
major cities have established their own e-services
platforms. Some of the smaller municipalities use
the shared solution while others use a third private e-
services environment. Besides that, some e-services
are available also in municipalities’ home pages.
As the result of the described architectural
decisions, the following problems were identified:
Because currently citizens are not able to access
all state and municipalities e-services in one
place, finding and accessing e-services is time
consuming (especially in situations when citizen
need to receive a number of differently located e-
services). The related services do not have cross-
platforms links, so the e-services must be
searched in global search engines. To consume e-
services in different platforms, separate
authentication is required, too;
Maintenance costs for several platforms usually
exceed the costs of using a centralized platform,
especially in this case because the shared
platform maintenance costs are administered by
the state.
The following EA layers were affected (here EA
means the state’s ICT architecture):
ICEIS2015-DoctoralConsortium
8
AA – similar functionality were implemented in
several unrelated platforms and local home
pages;
BA – the “one stop shop” concept is not used for
providing state and municipalities services for
the citizens.
The CTRY had not defined EA at the state level.
Only some solution-specific development goals were
set, but in most cases they were not aligned with
state and municipalities EA development needs and
goals. The organization what was responsible for
maintenance and development of the shared
solutions mainly performed tasks that were related to
technical resources maintenance, but the IT
governance processes were not fully performed.
Besides that, the unified guidelines were not set on
how and where the e-services must be deployed.
4 OUTLINE OF OBJECTIVES
The objective of the planned research is to ensure
that the IS changes are implemented according to the
envisioned EA and its development goals. The
specific objectives are:
to practical relevance of strategic IS change
management with regards to EA;
to conceptualize strategic IS change management
in the EA framework;
to develop a method for controlling change
implementation with regards to the current and
ideal IT landscapes;
to elaborate a method for strategic change
planning to attain the ideal IT landscape.
to perform empirical validation of the elaborated
methods.
5 RESEARCH METHODOLOGY
A research method to be taken to address
aforementioned research and practical challenges
follows the nested design science problem solving
approach (Wieringa, 2009).
The research design in terms of regulative cycles
is shown in the Figure 3.
The research will consists of three interrelated cycles
– the engineering cycle EC1 and two research cycles
RC1 and RC2. The engineering cycle consists of
investigation and definition of practical problems
including the analysis of empirical observations,
after what the solution design and implementation
will be done.
Figure 3: Research design in terms of regulative cycles.
After the engineering cycle, the two research
cycles RC1 and RC2 will be completed. These
cycles correspond to two key activities of strategic
IT management (Hanschke, 2009), namely, strategic
IT planning and strategic IT control. The planned
research will cover both of these processes. The
challenging part of IT management includes IT
planning from the ideal IT landscape creation
viewpoint. Therefore, initially in RC1 we will
assume that the ideal IT landscape is defined in the
enterprise’s IT strategy and a method for comparing
the planned landscape (including IS change) with the
ideal landscape will be elaborated. In RC2 we will
propose a method for creating the ideal EA and
aligning the IS changes with it.
6 STAGE OF THE RESEARCH
In this paper the initial stage of the research is
presented – the problem domain analysis and outline
of solution design. Following tasks were done to
define the problem domain and planned solution
design: (1) the literature analysis; (2) empirical
evidence analysis; (3) the problem domain
definition; and (4) the research methodology and
plan development.
Main goals of this stage are to:
• identify and define the problem domain – the
goal is set to gain theoretical and empirical
evidence to planned research-related problems,
to specify problems and evaluate their
importance;
• identify and assess existing solutions and related
researches – the goal is set to explore related
TowardsStrategicInformationSystemsChangeManagement
9
researches, proposed solutions and asses if they
have limitations to solve identified problems
completely;
• develop the future research methodology – the
goal is set to perform adequate future research
planning, set main stages, goals, activities and
results.
Currently we are in the beginning of the research 2
nd
stage – development of the method for strategic IS
change control. We have developed an outline of the
planned solution, still many unresolved issues exists
what needs to be solved to completed the outline.
7 EXPECTED OUTCOME
The main planned results will include two methods:
(1) the method for strategic IS change control and
(2) the method for strategic IS change planning and
also guidelines for the IS change evaluation
according to strategic EA development plans.
Achieving these results requires addressing
several research challenges summarized in Figure 4.
The figure defines the main concepts involved, their
relationships and associated research questions. It is
assumed that the change management process is
driven by change requests concerning modification
of some of the enterprise applications. The changes
in applications are associated with changes in other
layer of EA. EA has multiple states including the
current EA, planned EA and ideal EA. Development
of the ideal EA is guided by IT strategy, reference
models and best practices though is not always
attainable due to various constraints. The change
requests need to be mapped to the current enterprise
architecture to contextualize them, to evaluate their
impact and to select an appropriate implementation
approach. Transformation of the current EA into the
planned EA is performed to accommodate the
change according to the approach chosen. The gap
between the planned EA and the ideal EA needs to
be minimized.
The research questions name various research
and technical challenges associated with strategic IS
change management. Some of these challenges can
be addressed by using and adopting existing
methods. For example, the IT strategy definition,
change impact analysis, IT and business alignment,
IT investments evaluation, change management
process implementation and controlling. The
expected outcome is the newly developed methods
on strategic IS change control and planning what
will address the research questions:
1) How to control that change will be implemented
according to defined ideal EA?
2) How to map the change request with current EA
and transform it to planned EA?
3) How to compare the planned EA with the ideal
EA?
4) How to generate the recommendations for
change implementation?
5) How to define the ideal EA?
6) How to meet the ideal EA?
7) What are the best practices that can be used for
suggestions?
8) How to differ and classify the best practices
used for each EA type/class?
9) What are the reference models that can be used
for suggestions?
10) How to differ and classify the reference models
used for each EA type/class?
Figure 4: Research questions.
8 CONCLUSION
The paper sets stage for research on strategic change
management for IS with respect to the overall EA. In
this paper the initial steps of the research are
presented: the problem domain analysis and the
outline of the solution design. The complete solution
design will be developed in the next research steps.
In order to illustrate the effect of wrong architectural
decisions, the typical practical problems arising in
EA because of suboptimal architecture decisions in
the ECM process are presented. The main
conclusions arising from the initial research are:
1) The research problem domain is recognized in
related research works as well as observed in
practice.
ICEIS2015-DoctoralConsortium
10
2) The related research mainly focuses on the
analysis of different EA states (i.e., how to
achieve that change will be aligned with the ideal
future EA). However, creation of the ideal EA
landscape is an open challenge.
3) The suboptimal architectural decisions in the
ECM process cause a number of problems in all
EA layers.
4) The key typical problems arising from
inappropriate ECM and leading to suboptimal
EA are the following: data redundancy, low data
quality and reability, ineffective business
processes, cost inefficient operating model,
partial usage of applications’ functionality,
performance and security issues.
5) To prevent the mentioned problems, the
enterprises need to have complex vision on EA
development, the EA development goals must be
set and the introduced changes in any EA layer
must to be aligned with this vision and goals.
Enterprise architecting should be performed by
comparing and analysing different EA layers,
states, landscapes and their relations (including
gap analysis between the current EA state and
existing reference models).
REFERENCES
Pulkkinen, M. (2006). Systemic Management of
Architectural Decisions in Enterprise Architecture
Planning. Four Dimensions and Three Abstraction
Levels. Proceedings of the 39th Annual Hawaii
International Conference on System Sciences
(HICSS'06), p179-188.
Diefenthaler, P. & Bauer, B. (2013). Gap Analysis in
Enterprise Architecture Using Semantic Web
Technologies. Proceedings of the 15th International
Conference on Enterprise Information Systems
(ICEIS), in print.
Hanschke, I (2009). Strategic IT Management. A Toolkit
for Enterprise Architecture Management. München:
Hanser Fachburch.
Lautenbacher, F. et al. (2013). Planning Support for
Enterprise Changes. In: Grabis, J.et al. (eds.), The
Practice of Enterprise Modeling, 6th IFIP WG 8.1
Working Conference, PoEM 2013, Riga, Latvia, 2013,
Lecture Notes in Business Information Processing.
Riga: IFIP International Federation for Information
Processing. p54-68.
Armour, F. J., Kaisler, S. H. and Liu, S. Y. (1999). A big-
picture look at enterprise architectures. IT
professional. 1 (1), p35-42.
Armour, F. J., Kaisler, S. H. and Liu, S. Y. (1999).
Building an Enterprise Architecture Step by Step. IT
professional.1(4), p31-39.
Armour, F. J., Kaisler, S. H. (2001). Enterprise
Architecture: Agile Transition and Implementation. IT
professional. 3(6), p30-37.
Meta Group Inc. (2002) Enterprise Architecture Desk
Reference. [Online] Available from:
http://web.stanford.edu/~bvincent/Strategy/Enterprise_
Architecture_Report. [Accessed: 27th June 2014].
Spewak, S. H. (1993). Enterprise Architecture Planning:
Developing a Blueprint for Data, Applications, and
Technology. New York: John Wiley and Sons.
Wegmann, A. (2003). On the Systemic Enterprise
Architecture Methodology (SEAM). In: CAMP, O. et
al. (eds.), Proceedings of the International Conference
on Enterprise Information Systems 2003 (ICEIS 2003).
Angers.
Buckl, S. and Schweda, C. M. (2011). On the State-of the-
Art in Enterprise Architecture Management Literature.
Technical Report. [Online] Available from:
https://wwwmatthes.in.tum.de/pages/qmobnr2wocn2/
BS11-On-the-State-of-the-Art-in-Enterprise-
Architecture-Management... [Accessed: 25th July
2014].
The Open Group. (2009). TOGAF Version 9 Personal
PDF Edition [Online] Available from:
http://www.kingdee.com/news/subject/10togaf/pdf/TO
GAF_Manual_G091.pdf. [Accessed: 25th July 2014].
Gringel, P. and Postina, M. (2010). I-pattern for gap
analysis. In Engels, G., Luckey, M., Pretschner, A.,
and Reussner, R., (eds), Software engineering 2010,
Lecture Notes in Informatics. Bonn, p281–292.
Hamraz, B., Caldwell, N. H. M. and Clarkson, P. J. (2013)
A Holistic Categorization Framework for Literature on
Engineering Change Management. Systems
Engineering (16). p473-505.
Jarratt, T. A. W., Eckert, C. M. and Clarkson, P. J. (2004).
Engineering change. In: Clarkson, P.J. and Eckert,
C.M. (eds), Design process improvement Springer.
New York: Springer, p262–285.
Wright, I. C. (1997). A review of research into
engineering change management: Implications for
product design, Design Studies 18, p33–39.
Jarratt, T. A. W. et al. (2011). Engineering change: An
overview and perspective on the literature, Reseach in
Engineering Design 22(2), p103–124.
Postina, M., Sechyn, I., and Steffens, U. (2009). Gap
analysis of application landscapes. Proceedings of
13th Enterprise Distributed Object Computing
Conference Workshops, p274–281.
Erlikh, E. (2000). Leveraging Legacy System Dollars for
E-Business. IT Professional, 2(3), p17-23.
Goknil, A. et al., (2014). Change Impact Analysis for
Requirements: a Metamodeling Approach,
Information and Software Technology, in press
Tang, A., Lau, M. G. (2014) Software architecture review
by association. Journal of Systems and Software 88,
February 2014, p87–101.
Wieringa, R. (2009). Design science as nested problem
solving. Proceedings of the 4th International
Conference on Design Science Research in
Information Systems and Technology. Pennsylvania.
TowardsStrategicInformationSystemsChangeManagement
11
