THE PROFILES OF PROJECTS SUPPLIED BY A FULL-SCALE

ICT-SERVICES PROVIDER

Ari P. Hirvonen

TietoEnator Oyj, P.O.Box 203, FIN-40101 Jyväskylä, Finland

Jarmo J. Ahonen

School of Information and Communication Technology, Seinäjoki Polytechnic, Kampusranta 9, FIN-60320 Seinäjoki, Finland

Mirja Pulkkinen

Information Technology Research Institute, P.O.Box 35, FIN-40014 University of Jyväskylä, Finland

Keywords:

Methodologies, large-scale provider, architecture management, software engineering, requirement engineer-

ing, consulting

Abstract:

The role of modern ICT-services providers has changed from easily deﬁned system engineers to full-scale

providers. The types, or proﬁles, of projects supplied by such providers are not very well understood. In

this article a company speciﬁc analysis of a set of projects is presented. The analysis clariﬁes the types of

projects and discusses the features of those types. Five distinctive proﬁles of projects were found excluding

the maintenance. Some of the proﬁles were unexpected and seem to reﬂect the changing nature of the system

engineering market. This change shows that changes to existing methodologies and new methodologies are

required in order to offer proper methodological support for modern full-scale ICT-services providers.

1 INTRODUCTION

In the modern business environment the traditional

role of information system engineering companies

has changed quite dramatically. One of the changes

has been the emergence of full-scale ICT-services

providers. Such providers have a much larger reper-

toire of services than companies providing traditional

information system development.

It seems that the changed variety of services reﬂect

the changed use of information systems. Informa-

tion systems are not any more used only to perform

very restricted tasks (DeMichelis et al., 1998). In

the current business world information systems span

different organizations and act as strategic business

tools (DeMichelis et al., 1998)(Johansen, 1988)(Rob-

son, 1997)(Ward and Peppard, 2002). That develop-

ment has created pressures for ICT-providers: it is no

longer enough to be very good in implementing sin-

gle information systems. From the experience of the

company analyzed in this paper it seems to be the case

that in order to get implementation deals the provider

has to have a much larger understanding of the busi-

ness environment and provide additional services.

The types and proﬁles of such services are not,

however, very well understood. It is common to char-

acterize those services as consulting, and that con-

sulting is further divided into management consult-

ing (Block, 2000), management ICT-consulting (Rob-

son, 1997)(Spewak, 1992)(Ward and Peppard, 2002)

and technical consulting, for which there are some

tools and approaches like (The Open Group, 2002),

(Armour et al., 1999b), (Armour et al., 1999a), and

(NCR, 2003). Such division is not accurate enough

because different types of projects require different

skills from the provider’s employees and act in differ-

ent roles in the overall business of the provider.

In this article we report a study performed inside

a single full-scale ICT-services provider. The aim of

the study was to obtain a better understanding of the

actual business. Such understanding is required in

order to be able to develop new methodologies and

process models. Those new methodologies and pro-

cess models should reﬂect the real business require-

ments. This is a very important consideration because

existing methodologies or frameworks, like (Zach-

man, 1987), (Sowa and Zachman, 1992), and (Put-

man, 2001), do not reﬂect the changing business well

enough.

In Section 2 we will outline the research setting and

the data collection, in Section 3 we will outline the

data, in Section 4 an analysis of the data is done. In

Section 5 we will provide a brief conclusion and dis-

cuss future research.

123

P. Hirvonen A., J. Ahonen J. and Pulkkinen M. (2004).

THE PROFILES OF PROJECTS SUPPLIED BY A FULL-SCALE ICT-SERVICES PROVIDER.

In Proceedings of the Sixth International Conference on Enterprise Information Systems, pages 123-130

DOI: 10.5220/0002632001230130

 SciTePress

2 RESEARCH SETTING AND

DATA COLLECTION

This study is a part of a larger, company-wide effort.

The aims of the effort are methodology development

and process improvement. One of the basic steps is

gaining a better understanding of the real business and

projects of the company. The company is one of the

ﬁve biggest full-scale ICT-services providers in Eu-

rope.

The basic reason for the effort was that it seemed

that the existing information system and/or software

engineering methodologies and approaches do not re-

ﬂect the changed business environment encountered

by a full-scale provider. The methodologies and other

approaches have to be changed in order to improve

the overall performance of the company. The selected

improvement methodology was process improvement

and methodology development.

Because the variety of the projects performed by

a full-scale ICT-services provider include much more

than pure software engineering or maintenance, it is

necessary to understand the types of projects provided

in order to be able to improve. The selected approach

to improvement was method development, process

modeling and improvement.

One way to get better understanding of the projects

is to analyze the different types of work and work dis-

tribution between those types. After evaluating the

project plans of several projects and having discus-

sions with project managers, the selection of differ-

ent types of work was decided. Project phases were

considered to represent the different types of work.

The selected phases are outlined in Table 1. The table

includes the shortcuts used for denoting the phases

in ﬁgures. Actual work distribution (provider’s ef-

fort) between phases was queried from project man-

agers. The questions included the size of the project

(provider’s effort as working days) and the relative

distribution of effort between different project phases.

3 COLLECTED DATA

In this section we brieﬂy describe the data and pro-

vide a short analysis on the found project types. A

more detailed discussion on the types of projects is

provided in Section 4. The data consists of 49 projects

and their metrics. A brief summary of the data is as:

number of projects = 49, mean size (working days) =

370, cumulative size (working days) = 18 506, me-

dian size (working days) = 155, minimum size (work-

ing days) = 10, and maximum size (working days) =

5 500.

The summary shows that the average size of

projects in the dataset is not very large, the average

size is the same as one and a half year’s work of an

individual. The distribution of size is shown as a box-

plot in Figure 1. The ﬁrst impression of the mean and

the median of size is that the size of the projects is

surprisingly small. That seems to reﬂect the changing

nature of the business as will be discussed later on.

10 20 50 100 200 500 1000 2000 5000

Figure 1: Boxplot of the size of the analyzed projects

(provider effort).

One of the basic analysis methods is to look at the

distribution of different variables. In addition to Fig-

ure 1 which shows the sizes of projects, the boxplot in

Figure 2 shows the distribution of effort in different

projects. The boxplot is very interesting, especially

because the plot suggests that there are clearly differ-

ent groups (or clusters) of projects.

Figure 2 suggests that the number of clusters is

four or ﬁve. In order to ﬁnd out the actual number

of clusters we used the Partitioning Around Metoids

-technique described in (Kaufman and Rousseeuw,

1990). In that analysis we tried the cluster numbers

three, four, ﬁve, and six; contrary to our prior expec-

tations, the most ﬁtting number of clusters was ﬁve.

The clusters were separated by using the built-in

method provided by R version 1.7.0 on Windows NT.

The number of cases in each cluster are shown in Ta-

ble 2. In our opinion the clusters represent the real

types of projects although the number of cases in a

cluster is fairly small in some cases: two clusters have

only six members and one cluster has only four mem-

bers.

The boxplot of the work distribution in cluster

“Strategic consulting” is shown in Figure 3. The most

important phases are understanding of the current sit-

uation, target deﬁnition and strategic planning. The

average effort required by understanding the current

situation and target deﬁnition is over 60 % of the total

effort. It seems that the effort in strategic consulting

projects is in deriving the target situation from the cur-

rent situation. The explains the work distribution in a

natural way.

The second cluster is “Process consulting”, which

is normally considered to provide ICT-related con-

sulting for business process re-engineering. The box-

plot of the work distribution in this cluster is shown

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

124

Table 1: Identiﬁed project phases.

Name of the phase Description Shortcut

Project planning and management Effort used for planning and managing the project plan

Quality deﬁnition Effort used for deﬁning the target quality qde

Understanding the current situa-

tion

Effort used for understanding the current situation or the context of

the project

und

Target deﬁnition Effort used for deﬁning the outcome or target of the project tdef

Strategic planning Effort dedicated for strategic issues, i.e. strategic planning str

Technology architecture design Effort used for designing the technology architecture of the target

system (includes the deﬁnition of technology architecture of an en-

terprise level approaches)

t.a

Application portfolio design Effort used for the design of application portfolio a.po

Design of application architecture Effort used for designing the architecture of and application or an

individual system

a.a

Design of information architec-

ture (organizational level)

Effort used for designing organizational level information achitec-

tures

i.a

Business process design Effort used for business process reengineering or design p.pro

Requirements engineer-

ing/Speciﬁcation

Effort used for requirements engineering and high-level speciﬁcation

of the target system

r/s

Design Effort used for designing a system des

Implementation Effort used for implementing (including programming) a system impl

Unit/component testing Effort used for unit/component testing u.t

Integration testing Effort used for integration testing i.t

System testing Effort used for system testing s.t

Education and other activities re-

lated to taking the system into use

Effort dedicated into taking the system into actual use use

Customer satisfaction query Effort used for measuring the satisfaction of the client/customer c.s

Project closing Effort used for project closing activities p.clo

Other Effort used for other activities oth

in Figure 4. The majority of work is distributed be-

tween understanding the current situation, target deﬁ-

nition, strategic planning, technology architecture de-

sign, and business process reengineering. It is worth

noting that not a single phase required more than 20%

of the effort in average, as is shown in Figure 8.

The third cluster “Architecture consulting”, shown

in Figure 5, is a much more speciﬁc case. Most of the

effort is spent for understanding the current situation,

target deﬁnition, and application portfolio design. In

some cases effort is spent also for technology archi-

tecture design. It is not known what the phase “other”

means in this case.

The most outstanding type of projects is “require-

ment engineering”, shown in Figure 6. Almost all of

the effort is concentrated in the creation of require-

ments. This is the most speciﬁc type of projects.

The ﬁfth type of projects is the system engineer-

ing (or system implementation) project, shown in Fig-

ure 7. The work distribution shown in Figure 7 is

very near the classical one discussed in literature, e.g.

(Pressman, 2000), (Sommerville, 1998), and (Boehm,

1988). The most interesting feature is the surprisingly

small amount of effort dedicated for requirements.

There is, however, an explanation for this, as will be

discussed in the next section.

Table 2: The number of cases in clusters.

Name of the cluster Number of cases

Strategic consulting 6

Process consulting 13

Architecture consulting 6

Requirement engineering

and speciﬁcation

System engineering 20

4 ANALYSIS

The found clusters prompted us to perform further

analysis of the projects. This analysis is based on in-

depth discussions with project managers, specialists

and consultants responsible for the analyzed projects.

Those specialists agreed on the classiﬁcation and con-

sidered it a natural one. The analysis provided in this

section is based on the achieved consensus based on

those discussions.

4.1 Strategic Consulting

This cluster consists of projects that set the direc-

tions for the whole client organization. This type of

THE PROFILES OF PROJECTS SUPPLIED BY A FULL-SCALE ICT-SERVICES PROVIDER

125

plan qde und tdef str t.a a.po a.a i.a b.pro r/s des impl u.t i.t s.t use c.s p.clo oth

0 20 40 60 80 100

Figure 2: A boxplot of the relative distribution of work into different phases.

plan qde und tdef str t.a a.po a.a i.a b.pro r/s des impl u.t i.t s.t use c.s p.clo oth

0 10 20 30 40 50 60

Figure 3: A boxplot for the cluster “Strategic consulting”.

projects form the ﬁrst step and the starting point of

enterprise wide ICT-architecture and solution devel-

opment.

This type of strategic development is a continuous

process. The continuous nature of strategic planning

makes it natural that there are parallel and simultane-

ous development within the operative units of an en-

terprise. Typically this type of projects are conducted

in order to solve some speciﬁc strategy, vision, and

business model enablement problem or development

issue.

The client participation in this type of project con-

plan qde und tdef str t.a a.po a.a i.a b.pro r/s des impl u.t i.t s.t use c.s p.clo oth

0 20 40 60 80

Figure 4: A boxplot for the cluster “Process consulting”.

sists of senior management or senior specialists from

strategic management and business leadership. The

consultants who represent the provider must be very

experienced people with good communication skills

and social competence. They have to employ the busi-

ness vocabulary with the client’s top management and

provide the client with additional business value by

pointing out new or cost-cutting uses of ICT. There-

fore this type of projects act as the essential starting

point for all other types of projects.

This type of project does not aim for a techni-

cal system. The aim is to create an abstract sys-

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

126

plan qde und tdef str t.a a.po a.a i.a b.pro r/s des impl u.t i.t s.t use c.s p.clo oth

0 10 20 30 40 50

Figure 5: A boxplot for the cluster “Architecture consult-

ing”.

plan qde und tdef str t.a a.po a.a i.a b.pro r/s des impl u.t i.t s.t use c.s p.clo oth

0 20 40 60 80 100

Figure 6: A boxplot for the cluster “Requirement engineer-

ing and speciﬁcation”.

tem of business concepts, humans, and technology.

These projects may span a long time, but their results

are often compact and concise like strategic deﬁni-

tions, vision, descriptions of services, or a high-level

road-map for the future. These results require good

business domain knowledge from the consultant and

proper understanding and commitment of the partici-

pants.

4.2 Process Consulting

When the strategic issues have been solved, the prac-

tical planning and implementation of the client’s busi-

ness models and service processes can be started.

That planning and implementation is normally per-

formed in business development projects. This type

of projects often include knowledge and change man-

agement. The implementation of the strategic aims of

the client may require business process re-engineering

in order to create ICT-enabled processes, business

models and services.

plan qde und tdef str t.a a.po a.a i.a b.pro r/s des impl u.t i.t s.t use c.s p.clo oth

0 20 40 60

Figure 7: A boxplot for the cluster “System implementation

project”.

This type of projects involve the operational man-

agement of the client. Therefore the improvement of

communication between the client’s operational busi-

ness management and ICT-management is an impor-

tant issue. The most important issues to be tackled

in this type of project are still soft issues, not tech-

nology itself. This type of consulting uses business

vocabulary combined with technology-oriented con-

siderations. The deliverables of this type of project

are more formal than the deliverables of strategic con-

sulting.

The provider has created a methodology with no-

tations and process-models for the process consult-

ing subtype of these projects. The requirements for

the consultants are not as strict in this type of project

as they are in strategic consulting. Exhaustive under-

standing of the business domain and excellent social

skills may be compensated by more technical knowl-

edge and proper working practices.

Both strategic consulting and process consulting

are performed by special consultancy groups in the

company. Strategic consulting and process consult-

ing are important to full-scale ICT-service providers

because these projects focus on the client’s strategic

issues and increase the awareness of the client’s top

management of the provider and open new business

opportunities. In many cases such consulting is the

starting point of large business development projects.

In the modern world such projects require information

systems development and the beneﬁts to the client

mean implementation projects for the provider.

It must be noted that the potential for the additional

value of ICT-utilization is highest here. Therefore

good deliverables and honest attitude in strategic con-

sulting and process consulting are essential for both

the client and a full-scale ICT-sevices provider like

the analysed one.

THE PROFILES OF PROJECTS SUPPLIED BY A FULL-SCALE ICT-SERVICES PROVIDER

127

4.3 Architecture Consulting

The type of projects, architecture consulting, can be

seen as the ﬁrst step in actual information systems re-

lated work. The focus of this type of projects may

be in system portfolio management, planning the sup-

port for new or modiﬁed business processes, planning

of the ICT-solution, technology adaptation, security

improvement and management, and many other tech-

nology oriented issues.

This type of projects shift the focus from the higher

management to the ICT-personnel of the client. This

type of projects are guided by speciﬁc semi-formal

methodologies with notations and process models.

That methodology has been internally developed by

the analysed provider. Knowledge of the business do-

main is still required by the consultants, but this is the

ﬁrst type of projects in which technical knowledge

has risen to a dominant role. Technical specialists,

system architects and even system development spe-

cialists often contribute to this type of projects.

This type of projects acts as the bridge between the

more abstract strategic or process consulting projects

and traditional information systems development ac-

tivities. This type of projects is very important to the

analyzed provider and the client because the proper

needs and opportunities for actual system engineering

are deﬁned in this type of projects.

4.4 Requirements Engineering

In many sources modern system development or soft-

ware engineering is considered to constitute an iter-

ative or incremental development process which re-

peats several cycles with requirements engineering,

speciﬁcation, analysis, design and implementation.

The publicly known methodologies like RUP (Jacob-

son et al., 1999), OMT++ (Jaaksi, 1998)(Jaaksi et al.,

1999) and Catalysis (D’Souza and Wills, 1999) are

based on this approach. In many cases that is not,

however, true any more. The business environment

has changed in ways which make such incremental

projects more and more uncommon.

From the perspective of a full-scale ICT-services

provider the analysis part (this part is considered to

include requirements engineering, speciﬁcation and

high-level analysis) is willingly splitted into a sep-

arate projects. The price of this type of projects is

often based on the amount of work (hours) required.

This minimizes risks because the need for this type of

projects is high when the ﬁnal requirements and spec-

iﬁcations of the target systems are vague and the esti-

mation of the size of the ﬁnal implementation projects

are practically impossible to be performed.

One additional beneﬁt of performing this type of

projects separately has clearly been noted by clients.

The separation of the requirement engineering from

the system engineering project enables clients to ask

several tenders from providers for the actual imple-

mentation because the analysis results describe the

target system in such a detail that providers are able to

prepare proper tenders and the client is able to com-

pare those tenders.

It is interesting to note that European Union legis-

lation suggests that the distinction between consult-

ing, analysis and system implementation should be

clearer. Such regulation would directly support the

separation of requirements engineering from imple-

mentation projects — especially in the public sector.

In this type of projects, the client’s representatives

are from various business ﬁelds. Requirements en-

gineering is formal and supported by methodologies

and rich notations like UML (Booch et al., 1999).

The analyzed provider uses an in-house developed

methodology for this type of projects. The skills re-

quired from the provider’s personnel are methodol-

ogy knowledge and understanding of the business do-

main. At least some understanding of the notations is

required from the client’s representatives also.

4.5 System Implementation

This type of projects consists of the activities tradi-

tionally associated with the information system engi-

neering. The main activities are design, implemen-

tation, testing and taking-into-use. It is more and

more often the case that this type of project does not

include the analysis phase because those phases are

performed in a requirement engineering project. The

provider performs most of the work, but the partici-

pation of the client is practically required in testing,

project management and the clariﬁcation of the un-

clear parts of the requirements. The participating rep-

resentatives of the client are normally the same as in

requirement engineering projects.

The key competencies of providers are project

work, methods, and implementation technology

skills. Staff is required to have at least elementary so-

cial talents and cooperative capabilities. Some knowl-

edge of the business domain is also needed.

The turnover provided by this type of projects is

very important for a full-scale provider. In the case of

the analyzed provider, for example, the implementa-

tion projects constitutes the largest part of the whole

business.

4.6 The Continuum of Projects

In Figure 8 the distribution of work is shown. The

numbers used are the project type speciﬁc means for

every phase. There is an important issue proposed by

the ﬁgure. It seems that the different types of projects

form a natural continuum of work.

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

128

plan qde und tdef str t.a a.po a.a i.a b.pro r/s des impl u.t i.t s.t use c.s p.clo oth

0 20 40 60 80

1 1 1

1 1 1 1 1 1

2 2 2 2

3 3 3 3 3 3 3

4 4 4 4 4

4 4 4 4 4 4

1 = strategic consulting, 2 = process consulting, 3 = architecture consulting, 4 = requirement engineering and speciﬁcation,

5 = system implementation

Figure 8: The distribution of work compared between types.

The distribution of work shown in Figure 8 illus-

trates the empirically evident fact that the types of

projects found may be considered to form high-level

phases of the general business of a full-scale ICT-

services provider. The general ﬂow of business appar-

ently follows a natural cycle. The provider performs

strategic consulting to the customer, and after suc-

cessful strategic consulting the provider may be given

a contract for process consulting which may, in turn,

be followed by architecture consulting. Architecture

consulting leads to the need for information system

development, which means requirement engineering

projects and ﬁnally system implementation projects.

In other words: the business of a full-scale provider

follows a cyclic meta-level process in which the dif-

ferent types of projects form the phases of the pro-

cess. That way of performing business is more and

more systematic and the required methodologies and

notations are developed step-by-step. It is, however,

interesting to note that there are no full-scale method-

ologies aimed for this new way of looking at the busi-

ness of a full-scale ICT-services provider — or at least

we are not aware of such methodologies. Therefore

the development of an internal methodology was ini-

tiated.

The aim of the internal methodology is to provide

support for the complete high-level cycle. Different

types of projects would act as phases of the over-

all customer management process. The methodology

should provide a coherent and clear backbone for all

types of projects performed by the provider.

A more technical issue is the separation of analysis-

oriented phases and the implementation-oriented

phases of normal information systems implementa-

tion projects. That separation is getting more and

more common. The separation will provide new

challenges for modern software engineering method-

ologies like RUP (Jacobson et al., 1999), OMT++

(Jaaksi, 1998)(Jaaksi et al., 1999) and Catalysis

(D’Souza and Wills, 1999), which currently assume

an iterative or incremental approach to the system en-

gineering work. In such cyclic approaches it is as-

sumed that the provider is able to incrementally work

with different phases and easily return to require-

THE PROFILES OF PROJECTS SUPPLIED BY A FULL-SCALE ICT-SERVICES PROVIDER

129

ments if there are some uncertainties in the design

phase. In the emerging business models that is no

longer possible due to the separation of phases and

the use of competing providers. This will present new

challenges to methodology developers both in the in-

dustry and in the academia.

5 CONCLUSION

It must be noted that our results are from a single

provider and may not represent other providers and

markets. In addition to that, the number of projects

analyzed is not very large and fresh data from other

companies and markets should be acquired in order

to make the results more reliable.

The most important result of the analysis of the

projects is that the types of projects form a high-level

process that constitutes the client-provider relation-

ship. The proﬁles of projects and their relationships to

each other have consequences to the organization of a

provider’s activities. Those providers that take this

into consideration will have a competitive advantage.

The clusters of projects represent the changing na-

ture of the business. In order to get new system en-

gineering projects a provider has to be good in con-

sulting also. That is not very easy because there are

no existing methodologies or process models which

could be used for the management, measurement and

improvement of the provider’s business.

In addition to the need of a holistic methodology

for providers there is a real challenge to the existing

engineering methodologies. Modern methodologies

assume working practices that are less and less com-

mon in the business environment of a large full-scale

ICT-services provider. Methodology developers from

both the academia and the industry should develop

new methodologies that will be better suited for the

changing business environmet.

REFERENCES

Armour, F. J., Kaisler, S. H., and Liu, S. Y. (1999a). Build-

ing an enterprise architecture step by step. IT Pro,

pages 31–39.

Armour, F. J., Kaisler, S. H., and Liu, S. Y. (1999b). Look

at enterprise architectures. IT Pro, pages 35–42.

Block, P. (2000). Flawless Consulting, A Guide to Getting

Your Expertice Used. Jossey-Bass/Pfeifer, 2nd edi-

tion.

Boehm, B. (1988). A spiral model of software development

and enhancement. IEEE Computer, 21(5):61–72.

Booch, G., Rumbaugh, J., and Jacobson, I. (1999). The

Uniﬁed Modeling Language User Guide. Addison-

Wesley, New York.

DeMichelis, G., Dubois, E., Jarke, M., Matthes, F., My-

lopoulos, J., Schmidt, J. W., Wood, C., and Yu, E.

(1998). A three faceted view of information systems.

Communications of the ACM, 41(12):64–70.

D’Souza, D. and Wills, A. (1999). Objects, Components,

and Frameworks with UML: The Catalysis Approach.

Addison-Wesley, New York.

Jaaksi, A. (1998). A method for your object-oriented

project. Journal of Object-Oriented Programming

(JOOP), 9(10):17–25.

Jaaksi, A., Aalto, J.-M., Aalto, A., and Vättö, K. (1999).

Tried & True Object Development: Industry-Proven

Approaches with UML. Cambridge Univerity Press,

Cambridge.

Jacobson, I., Booch, G., and Rumbauch, J. (1999). Uni-

ﬁed Software Development Process. Addison-Wesley,

New York.

Johansen, R. (1988). Computer Support for Business

Teams. The Free Press.

Kaufman, L. and Rousseeuw, P. J. (1990). Finding Groups

in Data: An Introduction to Cluster Analysis. John

Wiley and Sons, New York.

NCR (2003). Global Information Technology Plan-

ning GITP. National Cash Register Corp.

http://www.ncr.com/services/cons_it_gitp.htm Ac-

cessed May 14th, 2003.

Pressman, R. S. (2000). Software engineering: a practi-

tioner’s approach. McGraw-Hill, London, 5th euro-

pean adaptation edition. Adapted by Darrel Ince.

Putman, J. (2001). Architecting with RM-ODP. Prentice

Hall.

Robson, W. (1997). Strategic Management and Informa-

tion Systems: An Integrated Approach. Prentice Hall,

London, 2nd edition.

Sommerville, I. (1998). Software engineering. Addison-

Wesley, Harlow, 5th edition.

Sowa, J. and Zachman, J. (1992). Extending and formal-

izing the framework for information systems architec-

ture. IBM Systems Journal, 31(3):590–616.

Spewak, S. (1992). Enterprise Architecture Planning. De-

veloping a Blueprint for Data, Applications and Tech-

nology. Princeton University Press, Princeton.

The Open Group (2002). TOGAF Version 8,

The Open Group Architecture Framework

"Enterprise Edition". The Open Group.

http://www.opengroup.org/architecture/togaf/, visited

January 1st, 2003.

Ward, J. and Peppard, J. (2002). Strategic Planning for In-

formation Systems. John Wiley & Sons, 3rd edition.

Zachman, J. A. (1987). A framework for information sys-

tems architecture. IBM Systems Journal, 26(3):276–

292.

ICEIS 2004 - INFORMATION SYSTEMS ANALYSIS AND SPECIFICATION

130