2011 IEEE Conference on Commerce and Enterprise Computing
ENTERPRISE ARCHITECTURE AS INFORMATION TECHNOLOGY
STRATEGY
Tiko Iyamu
Department of Informatics, Tshwane University of Technology, Pretoria South Africa
Abstract— Many organizations adopt cyclical processes to
articulate and engineer technological responses to their
business needs. Their objective is to increase competitive
advantage and add value to the organization’s processes,
services and deliverables, in line with the organization’s vision
and strategy. The major challenges in achieving these
objectives include the rapid changes in the business and
technology environments themselves, such as changes to
business processes, organizational structure, architectural
requirements, technology infrastructure and information
needs. No activity or process is permanent in the organization.
To achieve their objectives, some organizations have adopted
an Enterprise Architecture (EA) approach, others an
Information Technology (IT) strategy approach, and yet others
have adopted both EA and IT strategy for the same primary
objectives. The deployment of EA and IT strategy for the same
aims and objectives raises question whether there is conflict in
adopting both approaches.
The paper and case study presented here, aimed at both
academics and practitioners, examines how EA could be
employed as IT strategy to address both business and IT needs
and challenges.
Keyword: Enterprise Architecture, IT, Business, Strategy,
Development and Implementation.
I.
INTRODUCTION
Enterprise Architecture (EA) and Information
Technology (IT) strategy are important and critical
components in the organisation that deploys them.
Technologists and the business employees understanding of
the concepts of EA and IT strategy are of high importance.
There is huge reliability and high expectation of both EA and
IT strategy where they are deployed. According to Ross, et al
[1], Enterprise Architecture is the organising logic for
business processes and IT infrastructure reflecting the
integration and standardization requirements of the
company’s operating model. As a result of the expectations,
alignment between the two concepts requires better
understanding in order to achieve its objectives and value
add. Potentially, the understanding has impact on the
development and implementation of both EA and IT strategy
in the organisation that deploys them [2]. Lack of
understanding could also lead to incompatibility and
confused views on the definitions, objectives, processes and
phases that are required in the development and
implementation of the EA and IT strategy. In addition, it
could deprive the participants of possibility to achieve best
practice, through a failure to take the holistic view of what
must be done in the development and implementation of EA
as an IT strategy. Hence this study focuses on the
relationship between EA and IT strategy.
978-0-7695-4535-6/11 $26.00 © 2011 IEEE
DOI 10.1109/CEC.2011.33
Development, implementation and practice of EA greatly
depends on the strategy it employs [3]. The focal actors in
the EA approach include technical and non-technical factors
such as technology, process and people. Through the
domains, the study examined how EA is employed as a
strategy in the organisation. This include understanding of
the roles, impact and influence of non-technical factors on
the development and implementation of IT strategy in the
organisation. Strategy is directional, from one state to the
other. People are the main instrument and focal actor of
strategy, which is inseparable from technology, process,
rules and regulations [4]. IT strategy defines the necessary
autonomy that enables an identification of common
processes and technology. Iyamu and Adelakun [5] defines
IT strategy as the technical design which serves as the road
map over a period of time for the implementation of
information technology and information systems by people
using a formal process. They further argued that IT strategy
consists of the technology artefacts, which determines the
technological solutions based on the organisation’s goals and
objectives, through its information systems strategy.
Development and implementation of EA require in-depth
understanding of technical needs and business requirements.
This is due to the specialised nature of the concepts.
Kilpeläinen [6] argue that the deployment of EA requires
high know-how. Many organisations wholly rely on IT on
their daily operations and competitiveness. In the view of
[7], EA clinically improve the implementation of IT. As
business processes change, projects are initiated and
technology grows, making EA effective solution in the
implementation of IT strategy. The EA and IT strategy
collaborative work requires institutionalisation. In the study
[8] institutionalisation is defined as the process where a
practice is assimilated into the norm. It is not easily
disassociated, dismantled or re-designed. According to Wolff
& Sydor [9], senior leadership recognises that the intelligent
use of IT is important for an organisation to realise its
mission, goals and objectives. The primary aim of the study
is to examine how EA could be employed as IT strategy to
address both business and IT needs and challenges. In
achieving this, the study explored the domains of EA to
ascertain its relationship with IT strategy. IT professionals,
Consultants and academics would gain from the study. It is
of particular interest to IT executives mainly because of their
investment on both EA and IT strategy.
The remainder of this paper is organized into four main
sections. The first section covers the research approach that
was applied, which includes qualitative case study and data
collection. In the second and third sections, the paper
presents and discusses the empirical findings and data
analysis, respectively. Finally, the paper concludes with
82
Authorized licensed use limited to: Universidad Nacional de Colombia (UNAL). Downloaded on January 21,2023 at 17:21:08 UTC from IEEE Xplore. Restrictions apply.
highlights of the contribution of the empirical findings of the
study.
II.
RESEARCH METHODOLOGY
The study investigated how EA could be deployed as IT
strategy. In such a context, an interpretive research approach
was appropriate in order to understand the relationship
between EA and IT strategy within the social-technical
context of the organisation.
The interpretive approach focuses on reality. Interpretive
approach helps to gain knowledge of reality through social
constructions such as language, shared meanings, tools, and
documents [10]. In an interpretive research, there are no
predefined dependent and independent variables, but a focus
on the complexity of human sense-making as the situation
emerges [11]. The interpretive researcher assumes that
reality can only be accessed through social constructions
such as language, consciousness and shared meanings.
A qualitative, case study approach was applied to
examine how EA could be deployed as an IT strategy.
Qualitative approach was employed based on its premises in
the field of IS, that it is most suitable for interrogating
complex issues such as this study. According to Boucaut
[12], qualitative research is a very useful method for
complex situations and theories. The nature of the study
entails that materials are drawn from different sources. Case
study approach allows materials to be drawn from structured
and semi-structured interviews with identified and
volunteered players, documentary sources and ad hoc
observational and experience-based notes [13]. The case
study used in the study is a financial institution. The
organisation was selected on the basis of prima facie
evidence that it has successfully deployed EA as IT strategy.
The elements defined in [14] and [15], model of IS success
was validated as the criteria for success. This was considered
as being important to the delivery of EA in the organization.
The case study was adopted to gain an insightful qualitative
interpretation of EA on how it could be deployed to
complement IT strategy in the organisation.
The organisation used in the case study, a financial
institution has been in operation for more than 100 years.
The organisation has about 20,000 employees on its payroll.
The organisation has one of the largest IT divisions in the
corporate organisations in South Africa. At the time of the
study, there were 870 of employees in the IT division. The
organisation had 9 main divisions including the IT, which
was the smallest of the divisions. There were 6 main
departments, namely, Systems Development; Programme
Office; Infrastructure Services; Technology Management
and Architecture; Human Resources; and IT Finance in the
IT division. Each of the departments had it roles defined and
managed by a dedicated manager. All the managers were
reporting to the Chief Information Officer (CIO), who was
the Head of the IT division. The Technology Management
and Architecture department was managed by the Chief
Technology Officer (CTO).
Data sources included semi-structured interviews and
documentation. A total of 23 interviews were conducted.
This number was reached heuristically, i.e., the decision to
stop adding respondents was taken when nothing new was
being learnt from the interviews and a state of theoretical
saturation was achieved. Three main questions were used in
the interviews, they include: how was EA developed and
implemented in the organisation? What were the factors
which influences the development and implementation of the
EA in the organisation? What are some of the impacts of the
EA in the organisation? A set of balanced respondent
demographics was a key factor in achieving a true reflection
of the situations. Targeted respondents were from different
units and were at various levels of the organisational
structure within the Business and IT departments. They
included Analysts, IT Architects, IT Managers, IT Project
Managers, IT Executives and Business Managers. The
interviewees were selected on the basis of their experience of
the topics of EA, IT strategy, IT management and
organisational issues. Each of the interviewees has been in
the organisation for at least 5 years and at least 3 years in
their current positions. These criteria were to ensure rich
data.
Questions were asked around the understanding of EA
and IT strategy; how EA and IT strategy were developed and
implemented; the perception of the impact of EA and IT
strategy on the organisation; and the levels of those, in the
organisational hierarchy, involved in the development and
implementation of EA in the organisation. Other questions
include: how the organisation could best align its technology
investments with business strategy and goals; how IT
strategy delivery could be ensured through EA; how the
technology platform support the organisation’s growth plans.
An understanding was reached with the interviewees to
preserve the anonymity of their identity. This enthusiastically
encouraged them to participate in the interview, as well as, to
grant the permission to use a tape recorder. The recorded
interviews were transcribed and interviewees were requested
to confirm the transcripts. The data was analysed using
interpretive approach.
III.
FINDINGS
From the empirical data gathered from the case study,
five factors were found to be key on the technical and nontechnical relationship, and how EA could be deployed as an
IT strategy. The factors include governance, evolution, IT
and Business strategies articulation, operationalising of
principles and business information modelling:
A. Governance
To the organisation, governance issue was strategic.
Implementation of IT strategy through the EA approach
makes information governance a very vital role. The
governance formulates policies which defined the
information processes required to ensure that information
was protected, information quality was maintained and that
information was modelled accordingly. The articulation of
these requirements was the rational and selling-point by the
promoters in the organisation. It was critical to adopt a
consistent approach to identify, deploy and support
83
Authorized licensed use limited to: Universidad Nacional de Colombia (UNAL). Downloaded on January 21,2023 at 17:21:08 UTC from IEEE Xplore. Restrictions apply.
reflections from the empirical data on the domains of EA
show that organisation will be more successful if able to
create a unified business and IT strategies. This involves
establishing an architecture process that addresses the
organisation's key business, information, application, and
technology strategies. This includes business and technology
functions and processes. This enables the implementation
strategy to support business competitiveness.
The effective use of EA, particularly the domains of
business and information architectures were a competitive
differentiator and were considered during the business
strategy planning process. All major business initiatives were
meant to articulate the alignment of business requirements
with IT capabilities; and how the capabilities were
operationalised when the corresponding IT solutions had
been implemented. The approach synchronizes the business
strategy with IT strategy.
The primary aim of the IT division was to enable and
support the business systems. How this aim was articulated
was important. Thus, the IT division articulated to achieving
the operational excellence in providing a portfolio of services
to the organisation and manage the introduction of major
applications and infrastructure solutions through its strategy.
This include the consolidation of the organisation’s billing
systems to enable client fulfil their financial obligation in a
one-stop approach. In articulation, IT strategy was derived
from the business strategy as a useful activity, which defines
and documents the IT strategy in the organisation. This
makes the business-of-IT an important component in the
organisation. On this basis, IT was better managed and was
subdivided into domains as defined by the EA. Focus on
articulation of business and IT strategies helps shaped
productivity and improved efficiency through specialisation
as categorised by the domains of EA.
technologies and processes in the organisation. Many of the
employees felt this was possible only through governance.
EA defines and categorises all information within the
organisation. The information was shared with other
institutions, including the general public. Information was
critical in the activities of the organisation as it was the
determining factor in its business processes. It was therefore
prioritised and as a result required governance to ensure
efficient and effective management.
EA was used to identify and develop appropriate
governance structures for the development and
implementation of IT strategy in the organisation. The
quality of information was governed according to principles,
standards, policies and procedures. These include Metadata,
Integrity and Authenticity. Buy-in was critically instrumental
to the success of EA deployment. Otherwise, the EA team
was sure to receive no or less support from the stakeholders
and the rest of the employees.
B.
Evolution
The evolutionary character of EA ensures ongoing
planning, training, changes to business processes and IT
infrastructure, analysis, organisational norms to support the
development and implementation of IT strategy in the
organisation. EA had failed if it didn’t take into account its
potential impact on the business strategy. Effective business
processes’ use of IT strategy was a competitive differentiator
and was always considered and prioritised during business
strategic planning. All major business initiatives were
articulated in accordance and alignment to EA capabilities.
They were operational only when the corresponding IT
strategy solutions had been implemented.
The business strategic planning was established and
integrated to digest the rapid changes in the organisation.
This was dictated by IT strategy and facilitated by EA. The
business strategy links with EA ensures and facilitates
executable. The success or failure of EA was hinged on the
involvement of technology, people and process. The business
owns the processes and was, supported by the EA team
through technology. The architects facilitated and assisted
with understanding of the principles, standards and policies
through trainings and workshops. However, this proved to be
difficult as the compatibility and alignment between EA and
IT strategy was not easily articulated.
The business requirements drive EA development. These
requirements were to span a number of technology
categories whose usage was under the governance of the
domains. The groupings of technologies were intended to be
logical and were dependent on the organisation’s objectives.
The business stakeholders were fully aware of the criticality
of their involvement in EA deployment. As such, they
sometimes took the advantage to personalise their interests
rather than the interest of the organisation.
D. Operationalization of Principles
The organisational principles were formulated based on
the business needs and technology practices. The primary
aim was to control processes and activities within the IT
division. The architects in the different domains defined,
designed and implemented processes and activities within
the architectural principles.
There was thrives on technologies and processes change.
But change combined with unyielding competitive forces
could cause tremendous confusion and complexity. This is
avoidable - in the context; principles provide stabilizing
market force, engineered by EA. The EA stabilizing strength
motivates for institutionalisation. Each domain had its
predefined principles, which were formulated to achieve the
aims and objectives of the organisation. A good example is
the business architecture, which reflects process orientation,
development and operations deliverables. Based on the
principles, standards and policies were developed and set by
the architects in order to sanctify complexity, uniformity and
consistency in the deployment of technologies, processes and
activities in the organisation. There were potentials that the
organisation’s dependency on reusability on business and
technology artefacts could increase. As such, the reusability
principle was developed, and standards and policies were
C. IT and Busness Strategies Articulation
Change impact not only business processes and
relationship with partners, but it also affects information and
technology infrastructures supporting the systems. The
84
Authorized licensed use limited to: Universidad Nacional de Colombia (UNAL). Downloaded on January 21,2023 at 17:21:08 UTC from IEEE Xplore. Restrictions apply.
adopted for the purpose of governance. Business architecture
was organized along the lines of process orientation,
services, and operations’ centre of excellence within set
principles.
Change to processes and activities in the various domains
were significantly addressed through principles, standards
and policies. This was said to be of value add to the
processes and increased efficiency of activities in the
organisation. According to one of the senior managers,
“since we adopted the architectural standards and
principles, productivities have increased and many things
are stable and have normalised”. The empirical data
confirmed the importance and criticality of principle. For
example, the organisation wanted to know why users should
be concerned with industry principle, when should a user
adopt a standard, how should users choose among multiple
standards in the same area etc. The standards and principles
help clears up debates and selections of products and
services. Standards and principles were also used on
compliance evaluation.
E. Business Information Modelling
In achieving the organisation’s requirements of
competitive advantage, change and improvement, modelling
of business information were identified as critical. The
organisation’s information modelling strives to capture and
model data entities and their relationships in a top-down,
enterprise, comprehensive, and detailed fashion. The
techniques and tools demands resource-intensiveness,
rigorousness and fine-grained analyses to deliver on the
promise of information resource management (eliminates
redundancy, common definitions, claimed ownership, and
access rules) to meet the needs of all users. This was one of
the organisational strategies which IT strategy intended to
address through information architecture. The odds of
successful implementation of the organisation’s business
information modelling within a timeframe explored shifting
of information sharing opportunities, which required
business buy-in and specialised skill.
Evidently, the premise that data is one of the most stable
aspects of an organisation still holds true, from information
architecture perspective the value of modelling the enterprise
became an issue of scope. As such, there was need to focus
on exposing critical linkages, externally, with business
partners (competitive differentiator) and internally, across
business units (information sharing). The data was hosted by
technology as defined by the technical architecture domain
and accessed according to the principles and standards set by
the application architecture domain.
Information architecture challenges the assumption of
cooperate modelling that all data has value for the
organisation. Through information value network modelling,
key information that could be leveraged to create value for
customers was explored and analysed. Information
architecture sought to uncover information within the
enterprise that defined structured modelling constructs (e.g.,
tacit knowledge).
The above findings were analysed along the domains of
EA. The analysis is presented in the next section.
IV.
ANALYSIS
The analysis was carried out at two different
interconnected levels. The first level focused on the
conceptual level of the development and implementation of
EA. At the second level, analysis was conducted to examine
how EA is employed as IT strategy to address both business
and IT needs and challenges.
The analysis explored how EA provided the organisation
with methodology for modelling what business and
technology functions were performed, who performed them,
how the functions were performed, when and where the
functions were performed, and most importantly, why the
business needs to perform these functions. The analysis of
EA deployment as an IT strategy was first discussed
conceptually within generalisation of the domains, followed
by individual domain.
The Technology Management and Architecture
department, who performed tasks and functions of EA was
divided into four units, namely, Foundation (Business),
Services (Information), Application and Infrastructure
(Technical). Each of the units constituted 4 to 6 architects,
which was led by an architecture manager.
EA was developed and implemented through its
domains: business, information, application and technical
architectures. Each domain developed consistent set of
principles that reflected the collective and common will of
the organisation as they were articulated architecturally. This
was to enable incremental and iterative approach to
transitioning to formal modelling, while allowing it to
influence immediate decision making, consistently and
efficiently. Also, the principles were used as evaluation
criteria in the absence of detailed models that directs
decision making more discretely and comprehensively.
Special skills were needed in development of EA. Not all
IT specialists could be architects without the opportunity to
learn and practice the tools and techniques of EA or its
domains. A lack of skill results to poor performance and
inability to recognize and deliver the potentials of the
architectures. Even where the process was understood, there
were evidences that the potentials and objectives of EA were
not realized. It thus appears and was acknowledged by some
of the senior managers who confessed that experienced
architects are critical in achieving success in the future.
The development and implementation of EA was done in
phases (as depict in Figure 1 below). They convey logical
sequence and were based on relationships and dependencies
among the phases, rather than a linear sequence of events.
The rationale for the logical sequence included: (i) business
architecture as a model that was essentially business-driven,
and the modelling of the impact of the organisation visioning
on the operations of the business; (ii) information
architecture focuses on how information could be best
leveraged, exploited, or otherwise used to provide business
value. The information architecture was dependent on a
certain level of business architecture modelling to determine
how and where the business derives its value; (iii)
application architecture was dependent on business and
information architectures. This is because it comprises of the
85
Authorized licensed use limited to: Universidad Nacional de Colombia (UNAL). Downloaded on January 21,2023 at 17:21:08 UTC from IEEE Xplore. Restrictions apply.
necessary information and requirements needed to support
the business, and to provide the business with complete
solutions to satisfy the business vision; and (iv) the approach
to which technical architecture was dependent on business
strategies and business information, including infrastructure
requirements, and governance and procedures places it
logically after business, information and application
architectures.
The organisation used in the case study had external
trading partners and customers, which had access to its
critical information on a real-time basis. This had impact on
the way businesses were conducted. The business
architecture made a particular contribution in this regard.
The organisation struggled to consolidate their systems,
mainly because of the uniqueness in their business functions.
Clients in the old system could not pay accounts and bills
owed to the organisation in one-stop. The business
architecture provided the capability to consider different
strategies in the delivery of external services. It also gave the
organisation a better method for answering many questions,
including the following: Where and how could external
trading and partnership provide the greatest impact on
products and service delivery? Where and how could
external trading and partnership increase the value of
products and services to customer? When and what
information could be leveraged to create or increase value to
suppliers, internal operations, and customers? Based on the
answers derived, the organisations established priorities in
implementing strategies.
The development and implementation of EA was
iterative and periodical when it came to fulfilling the
organisational strategic mandate. The space of the periodic
was driven by the continued business needs, as well as the
rapid changes of the technology. For example, the
organisation had a policy which state: the end-of-life of all
technology including servers shall be between 3 and 5 years.
One of the interviewees explained the policy as follows: it is
the company’s requirement to replace any server which has
reached its end-of-life, otherwise, compatibility becomes a
major issue”.
The development and implementation of EA was done
within the premises that it will have impact and influence on
both business and IT divisions in the organisation. The
business and information architectures leaned more on the
business divisions while the application and technical
architectures were more of IT issues. EA codifies functional
requirements, and provides for discipline, systematic design
and implementation of process engineering and performance
improvement in the business and technology environments.
The relationship between the domains of EA and IT
strategy are now analysed as follow:
A. EA as IT Strategy
To gain a more accurate view and better understanding of
how EA was deployed as IT strategy, the analysis was done
on individual domains starting with the business architecture.
Figure 1 below illustrates the primary elements of each of the
domains as deployed in the organisation. These elements
were of high relevance in the analysis. The discussion that
follows should be read with Figure 1 so as to make sense of
it as well as gain better understanding of the development
and implementation of EA in relation to IT strategy in the
organisation.
Figure 1. EA as IT Strategy
B. Business Architecture as IT Strategy
The business architecture (BA) relies on the
organisational strategy to execute its mandates. The business
strategy was developed annually, sometimes on an adhoc
basis. The business strategy was based on the vision of the
organisation. The BA defines the “high-velocity” (real-time)
information, which passed between key business processes
and the integration requirements. This was enabled by the
underlying application and technical architectures, to achieve
both business and IT needs.
This domain acts as an expression of the organisation’s
key business strategies and tactics, and their impact or
interaction with business functions and processes as defined
by the architect. The domains typically consisted of the
current and future state models of business functions,
processes, and information value chains. It leads to the
information and application architectures and defines the
business design for sustainable competitive advantage. It was
considered as successful in some business divisions. In other
divisions within the organisation, the business architecture
was considered as too academic. As a result, the participation
of the employees was divided. Many of the employees had
their personal interpretation of the subject. This was
attributed to individuals’ fear that they could be exposed of
their weaknesses. This was perceived to threaten jobs and
positions.
It was used to coordinate, modelled all processes across
the organisation, uniformly. This also included analysis of
business processes as well as the business-of-technology.
The business-of-technology is referred to as the investment
and manageability of IT services to the organisation.
The business architecture primarily designed and
developed models in order to provide guidance for business
operations that were impacted by business strategies. These
models typically consisted of current and future state models
of business functions, processes and information value
86
Authorized licensed use limited to: Universidad Nacional de Colombia (UNAL). Downloaded on January 21,2023 at 17:21:08 UTC from IEEE Xplore. Restrictions apply.
chains within the networks. The roles and responsibilities
were to analyse, translates the needs of the business into
specifics, as well as communicate and validate requirements
for changes to business processes, policies and information
systems.
and increase information velocity across the organisation. It
also provides guidance for business operations, which impact
particular business strategies. The application architecture is
sequentially developed and implemented based on the
foundation of both business and information architectures.
C. Information Architecture as IT Strategy
Based on the business of the organisation, information
was most strategic in the daily operations of the organisation.
Information was a key component to all the systems in the
organisation at the time. The information architecture coordinated the use, reuse and sharing of the organisation’s data.
It was intended to strategically model, classify and leverage
information needed to support and enabled systems across
the organisation. Information architecture focused on
identifying and standardizing innovative ways to acquire, use
and store information in the organisation.
The information architecture was the “information supply
chain”, an extension of the business architecture in the
development and implementation of EA. It was a businessstrategy-driven set of artefacts that describes and models the
enterprise’s information supply chain and value chain, which
was referred to as information flows, business events and
linkages. The information architecture extends beyond the
organisational boundaries to external sources and targets, to
enable rapid business decision-making and information
sharing. The external sources included financial and
insurance institutions, government sectors and individuals.
The information architecture primarily included: a catalogue
of authentic sources of information (e.g. organisation’s and
commercial databases, research companies, and news
media); classes of relevant business information and their
value to the enterprise; information governance processes to
support policy development and information management
principles and practices that attempted to address:
information security and accessibility;
privacy and
confidentiality; information quality; integrity and
authenticity, archival cycles, business resumption planning,
and ownership, information management roles and
responsibilities. These elements were considered strategic to
the organisation.
In the organisation, the development of information
architecture establishes the value and importance of using
information effectively by employers and employees across
lines of business (LOB), as well as the need to achieve
collaborative excellence with external partners and
customers. Through its governance, the information
architecture focuses on constructing information models to
meet business requirements and engineering, including
detecting the gaps where business-critical high-velocity
information was not reaching customers, suppliers, and
partners. The information architecture models provided
guidance concerning the organisation’s information assets to
knowledge workers, information processors, software
developers, infrastructure managers, and executives.
Similar to business architecture, the information
architecture encourages decision makers to explore external
trading and partnership to, optimise information value
chains; plan application architectures and systems portfolio;
D. Applicaton Architecture as IT Strategy
Application architecture determines the strategic
direction of application related issues, including
development and methodological approach such as
deployment and manageability in the organisation.
Application architecture serves as a tool for identifying and
driving reuse throughout the existing and planned
architecture. It was intended to serve as an agent in
managing application strategy within information systems
supporting business transaction and information processing
in several ways. The strategic intends includes selection,
deployment and integration of systems in the organisation.
Application architecture was the strategic arm of the IT
strategy in the organisation. It was applied as the framework
to govern how application is designed, implemented,
measured and evaluated within the organisation. It was a
representation of required functionality to fulfil business
requirements and logics, as well as to satisfy business and
information architectures’ requirements. Application
architecture decision making was guided by both business
and information architectures, primarily to identify needed
functionalities and opportunities to reduce complexities,
improve efficiency and maintain application portfolio. It was
supported by technical architecture principles, which impact
the selection, design, and implementation of software
packages, application components and business objects.
Some of the key elements include enhancing inventories by
established models of relationships of applications to other
applications, information dependencies, supported business
processes and required infrastructure patterns. It modifies
existing application models, which was based on the future
functionality, processes and the strategies of business and
information architectures.
In the organisation, the scope of application architecture
includes collection of integrated information systems
(applications and components, build, buy or reuse), required
to satisfy business needs. The strategic process was guided
by business and information architectures in terms of needed
functionality and opportunities for reuse, and by the detailed
technical architecture design principles and standards. This
also impacts the selection, design, development and
implementation of software. A gap between the existing
application’s functionality and the functionality needed to
satisfy business and information architectures requirements
was defined by application architecture. It also develop
migration framework for moving the existing application
toward the strategic intent.
Overall, the application architecture was viewed as an
ongoing representation of the existing and planned
information systems required to support the ever-changing
business strategies and consequential business processes,
information, and application requirements. This was based
on IT strategy to enable the business of the organisation.
87
Authorized licensed use limited to: Universidad Nacional de Colombia (UNAL). Downloaded on January 21,2023 at 17:21:08 UTC from IEEE Xplore. Restrictions apply.
E. Technical Architecture as IT Strategy
The organisation’s strategic direction in the area of
technology was determined by the technical architecture.
This includes software, hardware, networks and integration
mechanism. In the organisation, the largest challenge was
implementing the technology infrastructure strategy. Unlike
the business, information and application architectures, the
technical architecture was not directly tied to discrete
business
processes,
information,
and
application
requirements resulting from new business strategies or the
consequent tactics. It stands separately, but underpins them.
The technical architecture (TA) created a framework
which represents the logical technical domains and their
relationships to each other, referring to existing frameworks
and modifying them accordingly. The framework categorises
technology, product and configuration standards. It was
primarily used for product evaluation and as reference point,
rather than creates from the scratch or reengineers the wheel.
The framework was documented and guided by principles.
Technical architecture outlines the lifecycle and
appropriate use of all hardware and software products in the
organisation. It models the technology environment,
including infrastructure configuration standards and
guidelines for the selection, deployment, integration,
configuration and management. The models provide both
view of the recommended technology and a basis for
assessing the impact of new or replacement technologies
within the context of the whole enterprise technology
infrastructure (rather than just within the context of the
specific technology being considered).
In the pursuit of the strategic intents, gap analyses are
conducted in all the domains of EA. This is also illustrated in
Figure 1.
V.
CONCLUSION
The contribution of the study arises from implications for
the decision makers responsible for sponsorship and
investment on IT to support business changing needs and
processes. These decision makers need to understand the
criticality of executive buy-in so as to dynamically deploy
EA as IT strategy. They also need to gain better
understanding of the impact of EA as an IT strategy in order
to be able to measure its value. It is critical for the
stakeholders to understand that the domains of EA cannot be
developed or implemented in isolation.
The other contribution of this study is its aims to be of
significance to decision makers, professionals, including
managers and employees of organisations within the IT
department, and IS researchers. It is expected that the key
contribution will arise from the understanding of the
fundamental elements through which EA complement IT
strategy. Through this, a better understanding of the
contribution of EA as IT strategy is gained.
REFERENCES
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
Ross, J.W., Weill, P. and Robertson, D. 2006. Enterprise Architecture
as a Strategy: Creating Foundation for Business Execution. Harvard
Business School Press, Boston, Massachusetts.
Chung, M. and McLeod, G. 2002. Enterprise Architecture,
Implementation, and Infrastructure Management. Proceedings of the
35th Hawaii International Conference on System Sciences.
Khoury, G.R. and Simoff, S.J. 2004. “Enterprise Architecture
Modelling using Elastic Metaphors”, First Asia-Pacific Conference
on Conceptual Modelling (APCCM 2004), Dunedin, New Zealand,
pp. 65-69.
Pereira, C.W, and Sousa, P. 2004. “A Method to Define an Enterprise
Architecture using the Zachman Framework”, ACM Symposium on
Applied Computing, 2004, pp. 1366-1371.
Iyamu, T. and Adelakun, O. 2008. The Impact of non-Technical
Factors on Information Technology Strategy and E-business,
Proceedings of the 12th Pacific Asia Conference on Information
Systems (PACIS), pp 1214-1222, Suzhou, China.
Kilpeläinen, T. 2007. Business Information Driven Approach for EA
Development in Practice. 18th Australasian Conference on
Information Systems Business Information Driven EA, pp 447-457.
Schekkerman, J. 2004. ‘Enterprise Architecture Validation. Institute
of for Enterprise Architecture Developments'. (June 2009).
http://www.enterprise-architecture.info/Images/Extended
Enterprise/Enterprise Architecture Validation Full version.pdf.
Iyamu, T. 2009. The Factors affecting Institutionalisation of
Enterprise Architecture in the Organisation, Proc. Conference on
Commerce and Enterprise Computing (CEC09), IEEE Computer
Society, July 2009, pp. 221-225
Wolff, S. and Sydor, K. 1999. Information Systems Strategy
Development and Implementation: A Nursing Home Perspective,
Journal of Healthcare Information Management, vol. 13, no. 1, pp. 212.
Walsham, G. 1993. Interpreting information systems in organisations,
Chichester; John Wiley & Sons.
Kaplan, B. and Maxwell, J. A. 1994. Qualitative Research Methods
for Evaluating Computer Information Systems. In: J.G. Anderson,
C.E.
Kaplan, B. and Maxwell, J. A. 1994. Qualitative Research Methods
for Evaluating Computer Information Systems. In: J.G. Anderson,
C.E.
Yin, R. K. 2009. Case Study Research, Design and Methods, 3rd ed.,
California, Newbury Park; Sage Publications.
DeLone W, McLean E. 1992. Information Systems Success: The
Quest for the Dependent Variable. Information Systems Research, vol
3, no 1.
DeLone W, McLean E. 2003. The DeLone and McLean Model of
Information Systems Success: A Ten-year Update. Journal of
Management Information Systems, vol 19, no 4.
88
Authorized licensed use limited to: Universidad Nacional de Colombia (UNAL). Downloaded on January 21,2023 at 17:21:08 UTC from IEEE Xplore. Restrictions apply.