OPEN ISSUES ON INFORMATION SYSTEM ARCHITECTURE
RESEARCH DOMAIN: THE VISION
André Vasconcelos
CEO - Centro de Engenharia Organizacional, INESC, Lisboa, Portugal
Carla Marques Pereira
EST-IPCB, Av. do Empresário, Castelo Branco, Portugal
Pedro Sousa, José Tribolet
CEO - Centro de Engenharia Organizacional, INESC, Lisboa, Portugal
Keywords: Information System Architecture (ISA), ISA Evaluation, Business/System Alignment, Enterprise
Information System, CEO Framework.
Abstract: Currently organizations, pushed by several business and technological changes, are more concern about
Information systems (IS) than ever. Though organizations usually still face each IS as a separately
technological issue with slight relations with business domain. This paper discusses the importance of the
Information System Architecture (ISA) as the tool for ensuring a global view on IS and for explicitly
assessing alignment between technology and business processes and strategies. In this paper, considering
the numerous topics, technologies and buzzwords surrounding ISA domain, we identify the major ISA open
issues, namely: ISA Modelling, ISA Methodology, ISA Evaluation, IS Architectural Styles and Patterns,
and IS/Business Alignment. We also present our advances in addressing some of these issues, by proposing
an approach for ISA evaluation and IS/Business Alignment measure. This approach is supported on an ISA
modelling framework and provides several indicators and measures for ISA evaluation. This approach is
applied to an IS health care project evaluation.
1 INTRODUCTION
During the last decade several important
technological progresses have been accomplished in
the computer science, as component-of-the-shelf
(COTS) software have raised and established
(namely ERP, CRM, B2B and Intranet systems), the
mobile and communication technologies have
emerged, and the integration technologies has been
raised and reinvented (where webServices stands for
integration current hot buzzword) (W3C, 2001).
Organizations, on the othe
r hand, were faced
with new business challenges in a changing business
environment – as the market globalization, the
costumer process reorientation, the need for product
innovation, the product life cycle reduction, and the
raising importance of efficient information and
enterprise knowledge handling. These new business
needs have being forcing organizations to redesign
their strategies, reengineering their business
processes and positioned efficient information
handling in every organization agenda. (Davenport
and Beers, 1995).
In spite of significant efforts and investments at
busi
ness and software levels, currently organizations
do not get the expected returns by just using the
“best” or the latest IT in the market (Boar 1999).
This paper discusses the preponderant role of the
In
formation System Architecture (ISA) in ensuring
Enterprise Information Systems (EIS) fully aligned
with organization strategy and business needs.
273
Vasconcelos A., Marques Pereira C., Sousa P. and Tribolet J. (2004).
OPEN ISSUES ON INFORMATION SYSTEM ARCHITECTURE RESEARCH DOMAIN: THE VISION.
In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 273-282
DOI: 10.5220/0002640702730282
Copyright
c
 SciTePress

The ISA topic is a quite new issue since only in
last decade the need for handling concepts that
overwhelm the description of how a system is
internally built emerged (Zachman 1987). Currently,
the ISA research field is quite confuse – considering
its immaturity and its different influences – being
quite difficult to agree in a common definition for
ISA, to set ISA major concepts, or define ISA
relations to Enterprise Architecture and Software
Architecture, among many others issues, as
explained in section 2.
This paper pretends to review and present ISA
major research issues namely ISA modelling, ISA
methodologies, ISA evaluation, IS architectural
styles and patterns, and IS/business alignment
assessment (see section 3).
In section 4, we present our research in the ISA
field and we propose an approach for ISA quality
evaluation, namely IS/business alignment,
informational entities accuracy, technological
choices, etc. This approach is further explored in our
first field experience in the Portuguese public health
care system (see section 5).
2 INFORMATION SYSTEM
ARCHITECTURE CONCEPTS
The research described in this paper is enclosed in
the organizational engineering research domain (also
known as enterprise engineering) (Liles et. al 2003).
Organizational engineering’s main focus is on the
organization, namely its internal and external
business environment and the information system
that supports business needs. The authors share the
CEO (Center for Organizational Engineering) vision
on organizational engineering research domain
described in Figure 1.
Figure 1. CEO vision on Organizational Engineering
(Vasconcelos et. al. 2001)
As described in Figure 1, Enterprise Architecture
(EA) considers all the issues relevant for getting a
coherent and comprehensible picture of enterprise
(as people, business, strategy definition, systems,
governance principles, etc.). EA is a group of
models defined for getting a coherent and
comprehensible picture of the enterprise (Tissot et.
al. 1998). EA is considered a vaster concept than
ISA, which includes business strategies and
processes, besides Information System (IS) models
that support them. Usually, at enterprise architecture
level, IS are consider “simple” resources used in
business (as people, equipment and material, etc.) –
e.g., (Eriksson, 2000) and (Marshall, 2000).
Information System Architecture (ISA)
addresses the representation of the IS components
structure, its relationships, principles and directives
(Garlan et. al. 1995), with the main propose of
supporting business (Maes et. al. 2000).
Spewak in (Spewak, 1992), argues that the ISA
description is a key step in ensuring that IT provides
access to data when, where and how is required at
business level. ISA is also important in ensuring IS
flexible, durable and business oriented (Zijden et. al.
2000), in providing the means for business, IS and
IT components alignment, and ensuring greater
efficiency using IT (Open 2001).
Quoting IEEE (IEEE 1998), the ISA level should
be high. Thus, ISA is distinguished from software
engineering topics – as representation and analysis
methods (e.g., E-R diagrams, DFD) – presenting an
abstraction of internal system details and supporting
organization business processes (Zijden et. al. 2000).
ISA usually distinguish three aspects, defining
three “sub architectures” (Spewak, 1992):
• Informational Architecture, or Data Architecture.
This level represents main data types that support
business.
• Application Architecture. Application architecture
defines applications needed for data management and
business support.
• Technological Architecture. This architecture
represents the main technologies used in application
implementation and the infrastructures that provide an
environment for IS deployment.
Informational Architecture’s major propose is
the identification and definition of the major data
types that support business development (Spewak,
1992), (DeBoever, 1997). Inmon (Inmon, 1997)
characterizes data (the support of the information
architecture) through different dimensions: primitive
vs. derived, private vs. publics and historical vs.
operational vs. provisional data. He argues that the
ISA should be influence by the data characteristics.
The second architecture level, defined by
DeBoever (DeBoever, 1997), is the application (or
system) architecture. This architecture defines the
main applications needed for data management and
business support. This architecture should not be a
definition of the software used to implement
systems. The functional definition of the
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
274

applications that should ensure access to data in
acceptable time, format and cost is this architecture
main focus (Spewak, 1992). Application architecture
defines the major functional components of the
architecture.
The Technological architecture defines the major
technologies that provide an environment for
application building and deployment. At this level,
the major technological concepts relevant for the IS
are identified – as network, communication,
distributed computation, etc. (Spewak, 1992).
3 A VISION ON INFORMATION
SYSTEM ARCHITECTURE
OPEN ISSUES
As stated before, ISA is a quite new research area. In
the past (until de 90’s) modelling the relations
between different information systems and business
was not an issue, since each system existed in its
standalone world. Thus, ISA was not a concern,
since software engineering approaches managed to
address most of individually information system
issues.
With network and communication evolutions,
complex systems interfaces were implemented in
order to ensure data synchronization. The
maintenance costs raised, the problems derived from
redundant data became a major issue (and cost) for
organizations.
In the 90’s, the information systems growed-up,
and became part of each enterprise’s department
business. The database management systems
transformed file replication in database replication
(Inmon, 1997). The traditional software engineering
approaches failed to answer these new needs and
several ISA research topics emerged.
In this section we present an overview on
currently ISA major open research topics. The ISA
research topics list described next was not developed
through a statistical literature review, since these
topics are open issues and some of them are not yet
addressed in literature. The topics presented were
driven not only from literature review but mostly
from our field experience on the area, namely
considering several real organizations ISA problems.
Our goal is to establish a common research
ground for this area in order to develop our
investigation and cooperate with other researchers in
the field.
3.1 ISA Modelling
The representation and graphical manipulation of a
model on some thing or concept is a critical tool for
discussion and abstraction. ISA modelling is concern
on the conceptual definition of ISA major notions
and its representation in a graphical way.
EAB (Enterprise IT Architecture Blueprints) is a
reference research in this topic. Boar verified that IT
architectures do not have a repeatable, coherent,
non-ambiguous and easily perceptible
representation. He proposed a set of blueprints for IT
Architecture drawing in a systematic, coherent and
rigorous way (Boar 1999). However, introducing 61
new notions and icons, not supported in any norm,
or standard language, organizations, in order to use
EAB, are forced to have an high knowledge and
experience on EAB (turning out its acceptance and
adoption difficult).
In the 90’s, software architecture had similar
concerns, namely there was not a consensus in
software architecture concepts. IEEE formed a task
force that defined IEEE 1471 norm: “Recommended
Practice for Architectural Description of Software-
Intensive Systems”, that provides a conceptual
framework for software architecture (IEEE 1998).
Based on IEEE 1471, Open Group proposed a
framework for ISA design and evaluation: TOGAF –
The Open Group Architectural Framework. This
framework, among other things, proposes a technical
reference model that defines a taxonomy for
coherent, consistent and hierarchical description of
the services provided by the application platform.
TOGAF framework focus is mainly technological,
not addressing ISA at informational and application
levels. Moreover, TOGAF framework does not
introduce any modelling blueprints, but a set of IT
notions and principles.
The clarification of the major concepts that are
relevant for ISA modelling is a fundamental step in
order to have a formal and simultaneously
comprehensible and useful (conceptual and
technological) tool for ISA representation, namely at
informational, application and technological levels.
However, currently, there is not any language,
mechanism or tool that addresses all ISA concepts.
The identification of such concepts and base notions
for ISA representation, are a vital step in ISA
semantic manipulation and for all the research in the
area.
The relation between the different concepts in
ISA sub-architectures (informational, application
and technological) and business is also an open
issue. In IS/business alignment assessment is crucial
to navigate between these abstractions levels – for
example, if a business process is changed for some
OPEN ISSUES ON INFORMATION SYSTEM ARCHITECTURE RESEARCH DOMAIN: THE VISION
275

reason (e.g., business process reengineering) it is
important to navigate to the systems and infer which
informational entities, applications and technological
components may need changes.
3.2 ISA Methodology
A major research topic in ISA is focused on the
definition of methodologies for Information System
Planning.
Spewak proposes a methodology – Enterprise
Architecture Planning (EAP) – able to define
application architecture from informational and
business requirements (Spewak, 1992). Using
Spewak methodology and Zachman framework
several institutions have been proposing adaptations
that best answer to its needs – interesting case
studies are Information System Architectures in the
American Federal Government (FEAF 1999), DoD
Technical Reference Model (DoD, 2002), Treasury
Enterprise Architecture Framework (FEAPMO,
2002), among others. Though Spewak methodology
is the most known information system planning
approach, it has several problems that make it quite
difficult to use in real problems. Namely, Spewak
approach defines applications based only in relations
between data and business activities, not considering
current technologies or existing solutions, which
turn out his approach quite inapplicable in most
situations.
Other approaches for IS planning have been
proposed by several consultant firms as IBM (Hein,
1985), SAP (Miller, 1998), Microsoft (Lory 2003).
However most of these approaches are technological
dependant on the technology that the firm is selling.
Approaches as CIMOSA (AMICE 1993) and
RM-ODP (International 1995) try to address the
enterprise architecture and the system architecture
simultaneously.
3.3 ISA Evaluation
The quality measure of the ISA is another research
topic in this area. The quality measure is concern on
inferring the ISA accurateness to a business model,
existing technologies, and corporate strategy.
ISA evaluation is an important research topic
since currently there are only adhoc and non
methodological ways to evaluate if an ISA fits
enterprise business and enterprise strategy. The ISA
evaluation is also an important topic for assess if
new information systems are align with current ISA
at informational, application and technological
levels.
Traditionally ISA evaluation is accomplished
using common financial ratios (Wagner, 2003).
However these approaches proved to be very
difficult to use, since IS benefits quantification is a
not a simple task. Giaglis presents an approach for
quantifying IS benefits (Giaglis, 1999). A central
point in IS evaluation is IS/Business alignment
assessment, present in section 3.5.
3.4 IS Architectural Styles and
Patterns
The identification of design patterns and best
practices in ISA is an important topic in order to aid
the information system architect in the creation of an
ISA.
In software engineering research field software
engineers when defining a software system use
software architecture best practices (Gamma, 1995).
The definition of architectural styles and patterns
transform software architecture from an art into
standard engineering practices.
In traditional architecture (as building
architecture) the use of patterns is the natural way to
define new architectures (Jacobson 2002).
Currently in ISA there are no patterns or
architecture styles for all sub-architectures
(informational, application, and technological).
However there are some best practices that are
becoming patterns. For example, at technological
level the three tier architecture is a quite used pattern
(where data, business logic and presentation are
separated in different components) (OOPSLA,
2001).
Though ISA is still much of art instead of an
engineering effort and therefore this research area is
still in its infancy.
3.5 IS/Business Alignment
In the Critical Issues of Information Systems
Management (CIISM, 2001) report, the alignment of
Information Systems (IS) with Business represents
54.2% of the Information Systems Managers’
concerns and in the same study, the IS Alignment
takes second place as the factor that most contributes
to the IS’ success in the organization.
Taking this into consideration, we define
Alignment among Business, Systems and
Information as a way to quantify the coherency level
in relation to the business necessity, the systems
offer and information management (Pereira, 2003).
However, in order to evaluate the coherency level
among these components two important points must
be attended: (i) the architecture must be correctly
defined and contemplate all the relevant situations
for the organization (see section 2) and; (ii) to this
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
276

architecture the rules that guarantee the alignment
must be applied (see section 4).
Attending to the previous paragraph, the
interdependency between Enterprise Architecture
and Alignment is unquestionable, since the first one
is the mean to the second one and to achieve the
wish of having an “aligned organization”,
definitively, the architecture definition and ensuring
its alignment might not be a necessary or sufficient
condition, but is surely the best way to guarantee it.
Other important point, it is ISA evaluation
presented in section 3.3. Understanding how
IS/Business is aligned/misaligned contributes to the
architecture assessment as a component of that
evaluation.
In next section we describe our approach to
some of these research topics.
4 OUR APPROACH
In this section we describe how we are addressing
some of the open issues described in section 3,
specifically ISA Modelling (3.1), ISA evaluation
(3.3), and IS/Business align assessment (3.5).
4.1 ISA Modelling
In order to model the enterprise the Organizational
Engineering Center (or CEO, for short, in
Portuguese) proposed the CEO framework
(Vasconcelos et. al. 2001) for modelling enterprises
using a restricted set of business objects. The CEO
framework was defined as an UML profile (UML
1997).
Although the CEO framework could not be used
to define a complete ISA, it presented some
interesting extensions to represent dependencies
between businesses and systems. The business
objects defined in the framework are goals for
strategy modelling; processes for business process
modelling, resources for business resource
modelling, and blocks for IS modelling. The CEO
framework also ensures consistency, easy of use and
provides mechanisms to maintain integrity with the
ultimate goal of reducing the “impedance mismatch”
between business and IT architectures.
Recently, CEO framework founding concepts at
Information System level where investigated and an
UML profile for ISA modelling at informational,
application and technological levels was proposed
(Vasconcelos et. al., 2003). Figure 2 presents the
current core concepts of the CEO framework (at ISA
level).
process
is supported
has >
is implem ented
is used >
< CRUD
re la te s
operation
part of
re late s
exists
«process »
«IS B lock»
IS B lo c k
«Inform ation Entity»
In fo r m a tio n
Entity
«IT Block»
IT B lo c k
IS S e r v ic e
«IS Service»
IT S e rv ic e
«IT Service»
«operation»
Business
Service
«Business Service»
Figure 2. CEO UML Meta-model Extensions for ISA
(Vasconcelos et. al., 2003)
The core concepts in the CEO framework profile
are:
• Business Process – a collection of activities that
produces value to a customer;
• Information Entity – any person, place, physical thing
or concept that is relevant in the business context and
about which is possible and relevant (for the
organization) to keep information;
• IS Block – a collection of mechanisms and operations
organized in order to manipulate data;
• IT Block –infrastructure, application platform and
technological/software component that realizes (or
implements) an (or several) IS Block(s).
These blocks can be further specialized; for
instance at technological level CEO defines IT
Infrastructure Block (representing the physical and
infra-structural concepts), IT Platform Block
(representing the collection of services needed for
implementing and IT deploying applications), and IT
Application Block (representing the technological
implementation of an IS Block). Please see
(Vasconcelos et. al., 2003) for further detail.
4.2 IS/Business Alignment Assessment
The IS/Business Alignment Assessment is based on
three dimensions deriving from the Enterprise
Architecture’s components: Business Architecture,
Information Architecture and Application
Architecture.
In this approach, understanding the relationships
that exist among the architectural components and
the possibility of measuring the alignment as the
result of three possible misalignments, is the key that
enables us to evaluate the IS/Business Alignment as
the misalignment:
• between Business Process (BP) (part of
Business Architecture) and Information
(part of Information Architecture);
OPEN ISSUES ON INFORMATION SYSTEM ARCHITECTURE RESEARCH DOMAIN: THE VISION
277

• between BP (part of Business Architecture)
and Applications (part of Application
Architecture);
• between Applications (part of Application
Architecture) and Information (part of
Information Architecture).
In Figure 3, we present the rules that allow us to
quantify the alignment. As mentioned, the
Alignment is based on three dimensions, and these
individually quantified allow us to quantify the
alignment as one (Pereira, 2003).
Figure 3: IS/Business Alignment’s Rules
Following are presented the formulas that allow
us to quantify the alignment; these formulas are
based on the rules presented in the Figure 3. As
mentioned, the Alignment is based on three
dimensions that individually quantified allow us to
quantify the alignment as one.
For the Alignment between Business
Architecture and Information Architecture the
formula defined is,
3/_
⎟
⎠
⎞
⎜
⎝
⎛
++=
ntE
nErP
ntP
nPE
ntE
nEcP
AIAlinAN
where:
• nEcP represents the number of entities created by
only one business process (Rule 1.1)
• nPE represents the number of processes that create,
update and/or delete (CUD) at least one entity (Rule 1.2)
• nErP represents the number of entities that are read
(R) by at least one process (Rule 1.3)
• ntE, number of total entities
• ntP, number of total processes
For the Alignment between Business
Architecture and Application Architecture the
formula is,
2/11_
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
⎟
⎠
⎞
⎜
⎝
⎛
−+
⎟
⎠
⎞
⎜
⎝
⎛
−=
ntP
nBPwAS
ntS
nASwBP
AAAlinAN
, where:
• nASwBP represents the number of application
systems without any business process associated (Rule 2.2
negation)
• nBPwAS represents the number of business process
without any support by an application system (Rule 2.1
negation)
• ntS, number of total application systems
• ntP, number of total processes
Relative to the Alignment between Application
Architecture and Information Architecture we have,
2/11_
⎟
⎟
⎠
⎞
⎜
⎜
⎝
⎛
⎟
⎠
⎞
⎜
⎝
⎛
+
−+
⎟
⎠
⎞
⎜
⎝
⎛
−=
nGAnGM
nGM
ntE
nEMA
AIAlinAA
,where:
• nEMA represents the number of entities managed by
more than one application system (Rule 3.1 negation)
• nGM represents the number of cases managed
manually (Rule 3.2 negation)
• nGA represents the number of cases managed
automatically among application systems
Business
Architecture
Information
Architecture
Application
Architecture
- Rule 3.1 - An entity is managed by
only one application system
- Rule 3.2 - The data management
should be automatic among the
application systems
-Rule 1.1 - All entities are created (C) only
by one process
- Rule 1.2 - All processes create, update
and/or delete (CUD) at least one entity
- Rule 1.3 - All entities are read (R) at least
by one process
- Rule 2.1 - Each business process should be
supported by at least one application system
- Rule 2.2 - All application systems must be
associated with at least one business process
• ntE, number of total entities
With the formulas presented it is possible to
quantify separately each one of the dimensions
presented in the alignment, being the level of
alignment obtained by the average of the obtained
values for each one of those dimensions.
4.3 Assessing ISA quality indicators
Aiming the identification of ISA quality attributes
and the identification of a methodology for inference
on the ISA suitability for a business model and other
restrictions, several prototype studies are being
accomplished.
We are using the UML profile for ISA, described
in section 4.1, in order to model the AS-IS ISA,
representing the current architecture.
We also defined several indicators and metrics at
business and system level for evaluation of IS/IT
projects. In order to infer the ISA Suitability for the
organization some indicators were defined:
• Functional Overlapping indicator, defined as:
∑
∑
FnewFold
, where:
Fnew – function implemented by the propose project
Fold – function implemented by the propose project that
already exist in other systems in the organization
• Integration indicator defined as:
CostsojectCostnIntegratio Pr
• Technology change indicator defined as:
∑
∑
ITNewIT
, where:
NewIT – new technology introduced by the project that
is not used in other existing IS of the organization
IT – technology proposed by the project
• Informational Entity Overlapping indicator, defined as:
CUD
CUD
IEnewIEexist
∑
∑
, where
IEexist
CUD
– informational entity Created, Updated or
Deleted by the systems proposed but already exist in
other organization systems
IEnew –informational entity Created, Updated or Deleted
by the systems proposed.
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
278

• Informational entity model compatibility indicator,
defined as:
∑∑
≠ newModelf
IEIE
.Re
, where
Modelf
IE
.Re≠
– Informational entity, which attributes
differed from Information entity reference model.
IEnew – informational entity Created, Updated or Deleted
by the systems proposed.
We have defined several other ISA evaluation
indicators considering financial, project, business
processes, systems interfaces, among other specific
topics – for further detail please refer to
(Vasconcelos et. al., 2004).
The approach described in (Vasconcelos et. al.,
2004) revealed to be useful when evaluating new IS
projects that should be part of a previously defined
ISA. However the approach was not very accurate
when measuring IS/business alignment. We address
this issue in next section.
4.4 An integrated ISA evaluation
approach
In order to measure the ISA quality, we realized that
in the approach described in previous section the
business/system alignment measure was poorly
accomplished (for example the approach does not
shows if an entity is created by multiple business
processes). Thus, in this paper, we will present an
approach to integrate the concepts beyond the
IS/Business formulas described in section 4.2 in the
approach described in 4.3, in order to have a global
ISA evaluation approach.
Thus, in addition to the quality indicators
described in section 4.3, we propose to integrate the
concepts presents on the alignment formulas as a
detail view of the Functional Overlapping and
Informational Entity Overlapping indicators.
By this we are trying to improve the ISA
evaluation as set of several dimensions and one of
those dimensions is the alignment among business,
systems and information.
Applying the alignment formulas to the ISA
evaluation can help us to understand it not only as a
horizontal and global assessment but also as a
composition of some restricted and vertical views.
In the following section, we show the first
experience’s results using the alignment formulas
onto a Portuguese project.
5 FIRST EXPERIENCE
This section presents our first attempt to apply the
integrated ISA evaluation approach described in
section 4.4 in evaluating a project in the Portuguese
Health Care System.
The project proponent is a large Portuguese
hospital with about 5000 employees (1000 medical
doctors). In the past, the hospital information
systems’ (IS) grown as independent information
islands (according to hospital health care units). The
project proposal described here focus on a particular
business process: the drug management process, see
Figure 4.
«resour ce»
Drug Therapy
«Cli nical pr ocess»
Dr ug
Preparat ion
«resour ce»
Pat ient
«resour ce»
Physici an
«Cli nical pr ocess»
Prescribe Drug
Treatment
«resou rce»
Pharmacist
«resour ce»
Dr ug
«Administ rati ve process»
Drug Warehouse
Management
«resource»
Dru g
«Cli nical pr ocess»
Dr ug
Admi ni s tr a ti o n
«resour ce»
nurse
«resour ce»
Pat ient
«resour ce»
Drug Therapy
Figure 4. Drug Management Business Process
This business process consumes and produces
several informational entities as drug, patient, drug
prescription, health care professional,
administrative/management personnel and drug
supplier. The drug and drug prescription
informational entities add additional attributes and
alter the format of existing ones. Figure 5 presents
the Drug informational entity.
E ntity N am e Drug Inform ational E ntity n. º
11.1
Id e n tifie r name
Type Thing
Description Substance used for m edical purposes sold on pharmacies,
produce in laboratories or in the pharm acy.
Relations
is prescribe by an physician (12.1)
is used in a patient (1)
is prepared by a pharmacist (12.3)
nurse (12.2) may ensure patient is having correctly the
drug
Figure 5. Drug Informational Entity
Currently this business process is badly
supported throw the Hospital Drug System (HDS)
that only supports the pharmaceutical activities and
poorly supports physicians and nurses’ activities.
This project is expected to deliver an IS that
supports the full business process and thus reducing
prescription mistakes (mostly cause by paper based
physician prescription), minimizing nurses wasted
time in “copying” drug prescription from paper to
the system and reducing process time by 30% to
60%. The proposed integrated drug management
system (IDMS) application architecture is described
in Figure 6.
OPEN ISSUES ON INFORMATION SYSTEM ARCHITECTURE RESEARCH DOMAIN: THE VISION
279

«IS B lock»
Drug
Preparation
«IS B lock»
Drug
P rescription
«IS B lo ck»
ID M S
«IS B lo ck»
Drug Patient
Adm inistration
Figure 6. Proposed integrated drug management system
(IDMS) application hierarchical view
Considering the evaluation indicators, integrated
with the IS/Business formulas, we developed the
project evaluation. In this section, only some of the
ISA quality indicators are described.
In terms of ISA, the IDMS presents some
functional overlapping with the HDS, once it will
implement some operations that already exist in the
HDS such as drug creation, search, update and
delete as well as drug prescription functions. Thus,
the functional overlapping indicator
(
∑∑
FnewFold
) presents a value near 0.4 (meaning
that about 40% of functions already exist in current
systems).
Project Integration costs are very high (40% of
project cost), 70% of which are related with the
integration between HDS and IDMS.
At technological level, IDMS is based on
different technologies than the reference model ones
(namely the IT platform and server hardware),
presenting a technology change indicator of 0.5
(meaning that about half of project technologies are
new technologies for the organization).
The IDMS presents an informational entity
overlapping indicator (
CUD
CUD
∑
)
of 1, meaning that all the informational entities
create, updated or deleted in the proposed system
already exist in other organization systems, which
justifies the project high integration costs.
IEnewIEexist
∑
Considering the global ISA, the IDMS presents a
interface disregarding indicator near 1, meaning that
almost all interfaces provided by the IDMS do not
respect at technological level the standard defined in
the hospital ISA plan.
We also realized that 31% of entities are created
by more than one process (Rule 1.1, Figure 3) and
this happens because the same entity is partial used
by several processes. Some processes (9%) never
created/updated/deleted at least one entity, being
against Rule 1.2, but this result is justified because
these are the processes that elaborate the statistics
reports. In the alignment between business processes
and information, Rule 1.3 was fully satisfied, all
entities are read at least by one process. As final
comment about this type of alignment we have a
level 80% of alignment and if we consider the
Functional Overlapping and Informational Entity
Overlapping indicators, the alignment result sustain
the indicators previously presented as a way of
identify where the problem is.
We do not present here the analysis for the other
two types of alignment, for page limitation reasons.
Considering the previous indicators the project
proposal (as presented before) was rejected.
However, considering the possible incomes of
having the drug management business process fully
supported, some suggestions were required in order
to re-evaluate the project proposal. Currently we are
waiting for the “new” proposal.
6 CONCLUSIONS
This paper describes our vision on major
information system architecture open issues. We
started by presenting ISA concepts and ISA relations
with other edging research areas (as software
architecture and enterprise architecture). Consi-
dering the technological and conceptual mess on
ISA area this paper establishes a common referential
for ISA hot research topics, namely: ISA Modelling,
ISA Methodology, ISA Evaluation, IS Architectural
Styles and Patterns, and IS/Business Alignment.
Besides setting a vision on ISA domain, we
describe our current approach to ISA evaluation.
This approach is based on our previous work and, in
this paper, we combine it with IS/business alignment
measures. The proposed approach was used for
evaluating an IS health care project.
This first experience confirmed that the approach
provides the tools (namely measures) for evaluating
and ISA considering existing IS and business
processes. However, in this first evaluation, we
notice some difficulties in putting together all the
different measures in order to have a final evaluation
grade. Thus, we are now working on combining all
the measures in a fully integrated approach.
Currently we are planning to build an ISA best
practices database and integrate this knowledge in an
ISA Computer Aided Evaluation methodology and
tool.
5 ACKNOWLEDGEMENTS
The research presented in this paper was possible
thanks to the support of Saúde XXI and several
Portuguese health care organizations.
REFERENCES
AMICE, 1993. CIM-OSA Open System Architecture for
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
280

CIM, 2
nd
Revised and Extended Edition, Springer-
Verlag.
Boar, Bernard, 1999, Constructing Blueprints for
Enterprise IT Architecture, John Wiley & Sons.
Computer Sciences Corporation, 2001. Critical Issues of
Information Systems Management,
http://www.csc.com/aboutus/uploads/CI_Report.pdf
Davenport, T.H. and Beers, M.C. 1995. Managing
Information About Processes, Journal of Management
Information Systems, 12(1), pp. 57-80.
DeBoever, L., 1997. Enterprise Architecture Boot Camp &
Best Practices: A Workshop, Meta Group.
Dod, 2002. Department of Defense Joint Technical
Architecture.
Eriksson, Hans-Erik and Penker, Magnus. 2000. Business
Modeling with UML: Business Patterns at Work, OMG
Press, Wiley Computer Publishing
FEAF, 1999. Federal Enterprise Architecture Framework,
version 1.1.
FEAPMO, 2002. The Business Reference Model - A
Foundation for Government-wide Improvement.
http://feapmo.gov/
Gamma, E., Helm, R., Johnson R., and Vlissides, J., 1995.
Design Patterns-Elements of reusable Object-Oriented
Software, Addison-Wesley, New Jersey, ISBN 0-201-
63361-2.
Garlan, D. et al., Architectural Mismatch (Why It’s Hard to
Build Systems Out of Existing Parts), Proceedings 17th
International Conference on Software Engineering,
Seatle, WA, April 23-30 1995, pp.170-185
Giaglis, G.M., Mylonopoulos, N.A. and Doukidis, G.I.
(1999) The ISSUE Methodology for Quantifying
Benefits from Information Systems, Logistics
Information Management, 12, 1-2, pp. 50-62.
Hein, K., 1985. Information System Model and
Architecture Generator, Volume 24, Numbers 3/4, pp.
213.
IEEE Architecture Working Group, 1998. Recommended
Practice for Architecture Description – Draft IEEE
standard P1471/D4.1, IEEE.
Inmon, W. H., Zachman, John A. and Geiger, Jonathan G.
1997. Data Stores, Data Warehousing, and the
Zachman Framework, McGraw-Hill
International Telecommunication Union,
Telecommunication Standardization Sector, 1995.
Recommendation X.904: Information Technology –
Open Distributed Processing – Reference Model:
Architectural Semantics.
Jacobson, M., Silverstein, M., Winslow, B., 2002. Patterns
of Home: The Ten Essentials of Enduring Design,
Taunton Press.
Liles, D. H., Johnson, M. E., and Meade, L., 2003 (access
date), The Enterprise Engineering Discipline,
http://arri.uta.edu/eif/ent_eng.htm.
Lory, et. al., 2003 (access date). Microsoft Solutions
Framework Version 3.0 Overview,
http://www.microsoft.com/technet/treeview/default.asp
Maes, Rik, Daan Rijsenbrij, Onno Truijens, and Hans
Goedvolk, Redefining Business – IT Alignment
Through a Unified Framework, White Paper, May
2000.
http://www.cs.vu.nl/~daan/
Marshall, Chris. 2000. Enterprise Modeling with UML,
Addison Wesley
Miller, S., 1998. Asap Implementation at the Speed of
Business: Implementation at the Speed of Business
(Sap), Computing McGraw-Hill.
OOPSLA 2001, Workshop on The Three Tier Architecture
Pattern Language, Conference On Object-Oriented
Programming, Systems, Languages and Applications,
http://oopsla.acm.org/oopsla2001/.
Open Group, The Open Group Architectural Framework
(TOGAF) – Version 7, November 2001
Pereira, Carla Marques and Sousa, Pedro. 2003. Getting
into the misalignment between Business and
Information System, In 10th European Conference on
Information Technology Evaluation. ECITE Press
Spewak, Steven H. and Hill, Steven C. 1992. Enterprise
Architecture Planning: Developing a Blueprint for
Data, Applications and Technology, Wiley-QED
Publication
Stevenson, Dennis A., 1995, Enterprise Architecture,
http://users.iafrica.com/o/om/omisditd/denniss/text/ea4
domai.html
Tissot, Florence, and Wes Crump, , 1998. An Integrated
Enterprise Modeling Environment, P. Bernus, K.
Mertins, G. Schmidt (Eds.), Handbook on Architectures
of Information Systems, Springer, pp.59-79, ISBN 3-
540-64453-9.
UML Proposal to the Object Management Group, 1997.
http://www.rational.com/uml
Vasconcelos, A., A. Caetano, J. Neves, P. Sinogas, R.
Mendes, and J. Tribolet, 2001. A Framework for
Modeling Strategy, Business Processes and
Information Systems, Proceedings of 5th International
Enterprise Distributed Object Computing Conference
EDOC, Seatle, USA.
Vasconcelos, A., Mendes, R., and Tribolet,J., 2004. Using
Organizational Modeling to Evaluate Health Care IS/IT
Projects, Proceedings of 37th Annual Hawaii
Internatio-nal Conference On System Sciences
(HICCS37), USA.
Vasconcelos, A., Sousa, P., and Tribolet, J., 2003.
Information System Architectures: Representation,
Planning and Evaluation, Proceedings of International
Conference on Computer, Communication and Control
Technologies Orlando, U.S.A..
Wagner, W, 2003 (access date). IS Management and
Evaluation of Alternate IT Architectures,
http://www91.homepage.villanova.edu/william.wagner/
MBA8520/itevalb.ppt.
Zachman, John, 1987. A Framework for Information
System Architecture, IBM System Journal Vol.26 Nº 3,
OPEN ISSUES ON INFORMATION SYSTEM ARCHITECTURE RESEARCH DOMAIN: THE VISION
281

p.276 – 292
Zijden, S., Goedvolk, H. and Rijsenbrij, D., 2000.
Architecture: Enabling Business and IT Alignment in
Information System Development.
http://www.cs.vu.nl/~daan/
ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION
282