Towards a business-IT aligned maturity model for collaborative networked organizations.
ABSTRACT Aligning business and IT in networked organizations is a complex endeavor because in such settings, business-IT alignment is driven by economic processes instead of by centralized decision-making processes. In order to facilitate managing business-IT alignment in networked organizations, we need a maturity model that allows collaborating organizations to assess the current state of alignment and take appropriate action to improve it where needed. In this paper we propose the first version of such a model, which we derive from various alignment models and theories.
- Organization Science - ORGAN SCI. 01/2000; 11(2):212-226.
- [show abstract] [hide abstract]
ABSTRACT: A consequence of the growing number of empirical studies in software engineering is the need to adopt systematic approaches to assessing and aggregating research outcomes in order to provide a balanced and objective summary of research evidence for a particular topic. The paper reports experiences with applying one such approach, the practice of systematic literature review, to the published studies relevant to topics within the software engineering domain. The systematic literature review process is summarised, a number of reviews being undertaken by the authors and others are described and some lessons about the applicability of this practice to software engineering are extracted.The basic systematic literature review process seems appropriate to software engineering and the preparation and validation of a review protocol in advance of a review activity is especially valuable. The paper highlights areas where some adaptation of the process to accommodate the domain-specific characteristics of software engineering is needed as well as areas where improvements to current software engineering infrastructure and practices would enhance its applicability. In particular, infrastructure support provided by software engineering indexing databases is inadequate. Also, the quality of abstracts is poor; it is usually not possible to judge the relevance of a study from a review of the abstract alone.Journal of Systems and Software. 01/2007;
- MIS Quarterly Executive. 01/2002; 1.
Towards a Business-IT Alignment Maturity Model
for Collaborative Networked Organizations
Roberto Santana Tapia∗, Maya Daneva, Pascal van Eck, Roel Wieringa
Department of Computer Science
University of Twente
P.O. Box 217, 7500 AE Enschede, The Netherlands
Aligning business and IT in networked organizations is
a complex endeavor because in such settings, business-IT
alignment is driven by economic processes instead of by
centralized decision-making processes. In order to facili-
tate managing business-IT alignment in networked organi-
zations, we need a maturity model that allows collaborating
organizations to assess the current state of alignment and
take appropriate action to improve it where needed. In this
paper we propose the first version of such a model, which
we derive from various alignment models and theories.
In modern organizations, business-IT alignment (B-ITa)
is a hard problem that requires continuous attention. There
is a considerable literature on measuring and improving B-
ITa in single organizations (e.g., [19, 22, 24, 30]) but the
problem of B-ITa in collaborative networked organizations
(CNOs) has hardly been studied. Yet, the problem is impor-
tant because improved B-ITa entails a more efficient use of
IT in the CNO supporting the integration of enterprise ap-
plications and processes across organizational boundaries.
CNOs form the core of a new discipline [9, 10] that
focuses on the structure, behavior, and dynamics of net-
works of independent organizations that collaborate to bet-
ter achieve common goals. CNOs are characterized by be-
ing formed by organizations which have a pre-disposition
to collaborate in order to attend a common interest using
IT, and by being associated with effective coordination and
shared decision making. These characteristics provide op-
portunities to generate commitment within markets which
∗Supported by the Netherlands Organization for Scientific Research
(NWO) under contract number 638.003.407 (Value-Based Business-IT
demand very quick, high-quality and cost-saving services
In such a context, maturity models (MMs) are a suitable
vehicle for CNOs to gain a deeper understanding of their
current B-ITa, and to plan what steps to take toward better
alignment. In this paper, we will define a conceptual frame-
work, in the form of a MM for assessing and improving
B-ITa in CNOs. Clearly, some other models and theories
related to B-ITa in CNOs. Nevertheless, none of these mod-
els and theories covers all the necessary domains that need
to be considered by CNOs when achieving B-ITa. This mo-
tivated us to adopt the position that these models and theo-
ries might be used as starting points in cross-organizational
B-ITa initiatives, but they need to be integrated.
The contribution of this paper is twofold.
present a systematic approach for the development of a MM
in the form of a MM process model. Second, we suggest a
state-of-art literature-based MM that can be used in a CNO
setting to assess processes related to those B-ITa attempts
which integrate multiple perspectives. The paper is orga-
nized as follows: Sect. 2 provides background on the con-
cepts we use. Sect. 3 presents related work emphasizing the
needs of MMs in CNOs. In Sect. 4 we describe the MM
we are developing. Furthermore, we discuss its adoption
in CNOs and its preliminary evaluation in Sect. 5. Finally,
Sect. 6 summarizes our conclusions and presents our imme-
diate future work.
2Conceptual Background and Definitions
For the purpose of our research, we define B-ITa as the
process to make IT services support the requirements of the
business, whether such services are individually or collabo-
ratively offered. We do not consider alignment as a steady
(application programs, e.g.,
ERPs, DBs, …)
(computers, user interface
(application programs, e.g.,
ERPs, DBs, …)
(computers, user interface
Figure 1. Business-IT alignment framework in
CNOs (adapted from ).
state but as a process that needs to be performed continu-
ously. By ‘IT services’ we mean services offered by com-
puterized information systems. By the ‘requirements of the
business’ we mean the systems requirements derived from
analyzing the goal(s) of the CNO. We will focus on oper-
ational B-ITa, which consists of aligning the operational
activities of IT systems and people to each other so that
optimal IT support for business requirements is achieved.
This contrasts with strategic B-ITa, where business and IT
tails [13, 30, 42].
We analyze the B-ITa concept in CNOs based on the
scheme shown in Fig.1. The horizontal layers classify enti-
ties in a service provisioning hierarchy in a business: phys-
ical entities provide services to a software infrastructure,
which provides services to information systems, which pro-
vide services to businesses. In the business layer, we take
four views on businesses: businesses provide services that
have a utility, they perform processes to provide these ser-
vices, they communicate with one another as part of per-
forming these processes, and while doing that, they ex-
change data that has semantics. Participating organizations
in a CNO need both to fit the different entities (horizontal
arrows) as well as to address B-ITa (vertical arrow). Our
interest is in the upper two layers of the framework (area
delimited by the dotted line), because there is where busi-
ness and IT alignment in CNOs takes place.
We define a CNO to be any “mix-and-match” network of
profit-and-loss-responsible organizational units, or of inde-
pendent organizations, connected by IT, that work together
to jointly accomplish tasks, reach common goals and serve
value constellations , extended enterprises and collabo-
rative highly integrated supply chains  are some forms
of CNOs. Our interest is in IT-enabled CNOs, i.e., collabo-
rations that are made possible by IT where the participants
interoperate with each other by means of information sys-
tems. We believe that IT makes global competition and col-
laboration possible, forcing organizations to focus on what
they can do well and facilitating collaboration between or-
ganizations with complementary competencies.
CNOs continue spreading since hypercompetitive envi-
ronments  exist. This kind of environments forces orga-
necting and aligning the business and IT operations among
them to meet goals. Participants in a CNO can be seen as
distinct loosely coupled stakeholders with commonly con-
flicting interests and goals . However, if they want to
collaborate, they need to formulate a clear-enough common
goal(s) toward which they strive together. This goal is not
necessarily the goal of all participants. The common goal
is an agreement between the customer-facing organization
and its direct partners. This goal might include also other
participating organizations in the CNO, but not necessarily.
CNOs are dynamic, because their environments are char-
acterized by rapid changes in IT, easy competitors’ mar-
ket entry and uncertain market demands.
defined collaborative work structures as basis , partic-
ipants need to react promptly to customer needs.
will collaborate while an interesting ‘business’ opportunity
exists. When this opportunity is over, the CNO dissolves
while, perhaps, the organizations are active in other CNOs
or look for new complementarities that allow them to par-
ticipate in new ‘business’ opportunities.
MMs describe the evolution of a specific entity over
time. Commonly, this entity is an organizational area or
function. MMs have been developed to assess specific areas
against a norm. Based on maturity assessments, organiza-
tions know the extent to which activities in such areas are
predictable. That is, organizations can be aware of whether
a specific area is sufficiently refined and documented so that
the activities in this area now have the potential to achieve
its desired outcomes. MMs apply a life-cycle approach
where an area develops over time until it reaches its highest
The first well-known maturity model was the soft-
ware capability maturity model1(SW CMM) proposed by
Carnegie Mellon University’s Software Engineering Insti-
tute (SEI). This model identifies, specifically for software
production, several levels of software process management
1More information on http://www.sei.cmu.edu/cmm/
Essentially, MMs make it easier for organizations to es-
tablish goals for process improvement and identify oppor-
tunities for optimization, since these models describe basic
attributes that are expected to characterize a particular area
for each maturity level. By comparing an organization’s
characteristics and attributes with a MM, an organization
will identify how mature it is in order to increase its process
capability: first, establishing goals for the improvement of
processes and then, taking action to achieve them.
3Needs of MMs in CNOs
In the context of a CNO, proper understanding of the do-
mains involved in B-ITa requires the integration of different
models. There have been some proposals for assessing B-
ITa. However, astheseproposalsareorientedtosingleorga-
nizations, they fail to take special characteristics of CNOs
into account, such as the need for coordination, the lack
of centralized decision making or the heterogeneity of IT
architectures. Besides such proposals, there are also mod-
els that can be used to assess the maturity of one different
aspect within CNOs. However, to the best of our knowl-
edge, B-ITa is still not addressed by a single model in a
CNO context that addresses all relevant aspects. In this sec-
tion, we present a summary of different B-ITa MMs and
MMs for CNOs that can be found in the literature. We did
a semi-systematic literature review using a systematic lit-
erature review process  to select the related work pre-
sented in this section. The performed literature review con-
sisted of a broad search of academic and practitioners’ in-
formation sources. We approached the literature search us-
ing several electronic indexing services (e.g., ACM Digi-
tal Library, Google Scholar, Citeseer library, and IEEEx-
plore). A set of key words was used: alignment, business IT
alignment, strategic alignment, IT alignment, architecture
alignment, maturity model, assessment tool, measurement
guide, networked organization, business network, collabo-
rative enterprises. We also used some alternative terms for
alignment: balance, harmony, fit, and linkage. We traced
the references in the identified papers to get access to other
relevant sources. We reviewed the abstracts and the conclu-
sions of the identified documents in order to determine their
relevance to our research.
3.1B-ITa Maturity Models
Luftman’s strategic alignment model is an approach to de-
termine a single organization’s B-ITa based on six do-
mains, namely skills, technology scope, partnership, gov-
ernance, competency measurements, as well as communi-
cations . Each of these domains is assigned five levels
of alignment. The level of alignment for each individual
domain is determined by means of answers to some ques-
tions. Luftman’s model has been developed based on his
practical experience and research, so this model is a prag-
matic model. However, it disregards interrelations among
the domains that explain B-ITa and it is focused to single
3.1.2 CIO Council’s assessment guide
The Chief Information Officer (CIO) Council, a consor-
tium of US Federal executive agency CIOs, developed an
architecture-specific alignment and assessment guide .
This guide provides an overview of the integration of en-
terprise architecture concerns into the information technol-
ogy investment planning process. It is useful to determine
to what degree a proposed investment aligns with business
strategies, and to know how well the technology of invest-
ments aligns with the infrastructure architecture. This as-
sessment model is primarily focused on investment studies
in federal agencies. It does not identify specific B-ITa do-
mains, and thus it does not provide support to identify op-
portunities of improvement in organizations on some par-
3.1.3 Duffy’s MM
The MM developed by Duffy  consist of six domains
required to understand B-ITa. The model is based on the
premise that a reliable partnership between IT and non-IT
executives is fundamental for achieving a successful B-ITa.
Duffy recognizes that IT and business objectives are inter-
dependent, and therefore, a division of practices into IT and
non-IT areas would generally be unfavorable. Although the
six domains reflect this position of the author, the model
does not have explicit maturity levels for each of the do-
mains. Instead, Duffy combines the six domains figuring
out four B-ITa scenarios where organizations can be catego-
rized. Such scenarios are the maturity levels in the model.
Duffy’s MM also is only focused on single organizations.
3.1.4 de Koning et al.’s model
Based on the analysis of business-IT excellence in several
successful organizations in The Netherlands, and with the
help of five hundred managers, de Koning and van der
Marck  came up with ten questions that can be used
to identify the level of alignment in single organizations.
Those questions can be answered in a scale from 1 to 10
where the highest score means ‘it entirely applies to my or-
ganization’ and the lowest score means ‘it entirely does not
apply to my organization’. Although they do not identify
topics. However, the levels they present are limited to three:
immature, puberty and mature; this restricts the results and
it neglects the assessment of the processes that do actually
help to achieve B-ITa.
3.1.5 van der Raadt et al.’s MAAM
The Multi-dimensional Assessment model for architecture
Alignment and Maturity (MAAM)  can be used to as-
sess architecture within organizations. The MAAM helps
to identify the current situation of an organization’s archi-
tecture, and to define improvement points and plans. The
authors claim that a correlation exists between architecture
alignment and architecture maturity. They claim that when
architecture maturity increases, architecture alignment gen-
erally increases too (and v.v.). The MAAM consists of six
interrelated domains that explain the alignment and matu-
rity of an architecture. However, the model only assess
such an architecture considering B-ITa as a stage that can
be reached by increasing architecture maturity.
COBIT, issued by the IT Governance Institute2, is a guide to
employ management best practices and to measure IT pro-
cesses. Version 4.0 of this guide provides a clear support
to assess the align of IT with the business processes. For
example, under the ‘Defining a strategic IT plan’ process,
COBIT outlines how to engage IT managers on alignment
with business goals and to develop a proactive process to
quantify business requirements. However, (i) the focus of
COBIT lies on IT Governance, (ii) it does not address a net-
B-ITa from a strategic perspective.
3.1.7Laagland et al.’s assessment tool
According to Laagland et al. , the degree of alignment
is mostly stipulated by the degree of maturity of changes
on architecture. Managers must then look at the maturity
of their organizations’ architecture as start point for iden-
tifying improvement measures for B-ITa. This assessment
its competencies are, and which measures must be imple-
mented to reach a higher level of maturity. The tool de-
scribestherolesofbusiness/ITmanagers, architects, project
managers, and the like, for each of the architecture levels.
With the model, it is possible to identify how organizations
handle managing architecture and B-ITa.
3.2Maturity Models for CNOs
Since we are developing a MM for CNOs, our literature
review also covers some MMs that can be applied in collab-
2More information on http://www.isaca.org/
orative settings (e.g., EIMM , IT outsourcing MM ,
extended CMM , E2AMM , SCM MM , and
CollabMM ). Each of these models covers a particular
domain related to B-ITa in CNOs (e.g. architecture or pro-
cesses), disregarding other necessary domains that need to
be taken in consideration by CNOs when achieving B-ITa.
So, none of those models explicitly helps to assess B-ITa.
It can be argued that those models could complement each
other to assess B-ITa in CNOs. However, CNOs should
spend considerable time and effort to understand and apply
each of the models, and to analyze how the results could
combine to plan B-ITa improvement actions. Therefore, to
have a selection of domains in a single integrated model is
useful for CNOs.
As no current B-ITa MM addresses alignment in CNOs
and no MM for CNOs addresses more than a single as-
pect of B-ITa, we are filling this gap in CNOs by devel-
oping a new MM: the so called ICoNOs MM (IT-enabled
Collaborative Networked Organizations Maturity Model)
to assess B-ITa in CNO settings. We present this MM in
the next section.
4 The ICoNOs MM
Developing MMs systematically is not a topic that is
widely covered in the literature. Instead, most of the MM
literature presents the resulting models only and does not
discuss the model developing process itself. The devel-
opment of the ICoNOs MM consists of several steps (see
Fig.2). Detailed explanation of most of these steps can be
found in our earlier work . Below we present a sum-
mary only. We make the note that because Fig.2 is a high
level view of our MM development process, we excluded
any discussion on feedback loops needed to keep the MM
updated in a dynamic environment. We, however, acknowl-
edge the importance of monitoring the MM and managing
the evolution of CNOs when the MM is modified.
The first step in developing a MM is to determine the
SCOPE of the model, which means to set the boundaries for
the model. This is to differentiate the model from existing
MMs. The second step is to DESIGN the model and covers:
• thespecificationofthemodel’stype. MMscanbeclas-
sified as assessment MMs and development MMs. The
first type consists of normative models which serve
as assessment tools that target certification, and help
improve the organization’s image as a reliable partner
(e.g., the SEI series of CMMI-compliant models). The
second type includes development tools that organi-
zations use as guides for implementing best practices
that, ultimately, lead to improvements and better re-
Figure 2. MM development process.
• the determination of the model’s architecture. The ar-
chitecture of a MM prescribes the manner in which
maturity levels can be reached.
staged MM, before reaching level 3, an organization
needs to achieve successfully what is mentioned in
level 2 for all the domains included in the MM. In a
continuous MM, each domain can be approached sep-
arately. This architecture allows selection of the order
of improvements that best meets the objectives of or-
For example, in a
• theorganizationofitsstructure. ThestructureofaMM
presents the organization of the model’s components.
It defines if the MM does include domains and key ar-
eas, and how they are decomposed and used to reach
• the definition of the maturity levels. This step implies
to define the number of discrete levels of maturity for
the model (typically five or six), and their qualifiers
• the identification of the domains. The last step related
to the design of the model is the identification of the
domains to which the levels apply. A domain is a rele-
vant aspect within the scope of the MM. For example,
CMMI for software development  recognizes 4 do-
mains: process management, project management, en-
gineering and support. This task is not simple because
after identifying the domains, they need to be validated
to assure that they correspond to the purpose of the
Once the design of the model is completed, process ar-
eas need to be identified for each domain so that we POP-
ULATE the model with observable domain assessment cri-
teria. A process area is a group of practices in a domain
which, when implemented collectively, satisfy goals con-
sidered important for making an improvement in that do-
main (e.g., a process area in the IS architecture domain is
‘IS portfolio management’). After populating the model,
it must be validated in order to EVALUATE its applicability
and generalizability. The objective is to validate the entire
MM to test it for relevance and rigor. Following popula-
tion and evaluation, the MM must be made available for
use to verify its generalizability (step DEPLOY). To provide
its acceptance and to improve its standardization, the MM
must be applied in organizations that differ from the orga-
nizations that were involved in its design and population.
The identification of organizations that may use the model
and the application of the model to multiple organizations
are the final steps towards its spreading and acceptance. Fi-
nally, it is important to track the evolution of (i) the orga-
nizational area or function that is assessed using the MM,
and (ii) the requirements of the organizations that apply the
model, in order to MAINTAIN the MM over time to keep it
up-to-date. For example, the first MM developed by the
SEI was the SW CMM. However, they observed that orga-
nizations would like to focus their improvement efforts not
only in software engineering but also across different orga-
nizational functions. Therefore, the SEI came up with an
integrated MM (CMMI) combining models from different
disciplines to support the enterprise-wide process improve-
ment that organizations were pursuing.
This paper focuses on the step POPULATE of the MM de-
velopment process. Therefore, in the remainder of this sec-
tion we report on the B-ITa process areas included in our
model. First, we present the STRUCTURE , LEVELS and DO-
MAINS for a better understanding of the ICoNOs MM.
4.1Structure of the model
The structure of the ICoNOs MM is based on CMMI
for development . It means that our MM builds on
prior work. For example, some CMMI design choices are
also present in ICoNOs. This situation avoids starting with
the development of the model from scratch, and, most im-
portant, it also prevents our future users from starting over
when adopting our MM for their B-ITa assessments.
The ICoNOs MM has four layers of aggregation. The
upper layer consists of the domains that must be addressed
in a CNO when achieving B-ITa, i.e., partnering structure,
IS architecture, process architecture and coordination (see
Sect. 4.3). The next three layers reflect the overall CMMI
structure (see [14, p.30]). For example, in each of the do-
mains we can also find process areas. Process areas are sets
of activities that are performed to make improvements in
a particular domain (see Sect. 4.4). Similarly to CMMI,
the ICoNOs MM process areas have specific and generic
goals, which the activities in the process area are supposed
to achieve. The specific goals describe characteristics that
must be present to satisfy a particular process area; they are
specific for this area. There are also goals, called generic
goals, that apply to all process areas, although their instan-
tiation for each process area can differ. For example, a
CMMI generic goal is ‘the process is institutionalized as
a defined process’. Our MM will incorporate the generic
goals of CMMI3. The goals will be decomposed in specific
and generic practices describing what a CNO may imple-
ment to achieve the specific and generic goals. These prac-
tices will be expected and are not mandatory. This means
that it will be permitted to implement alternative practices
in substitution for the specific and generic practices that the
ICoNOs MM will include. The only condition is that the
goals must be satisfied, to perform a process, to reach a spe-
cific maturity level.
4.2 The B-ITa levels
The ICoNOs MM has five levels of maturity (see
Fig.3). Levels are used to describe an improvement path
recommended for a CNO that wants to improve processes
to achieve B-ITa. To reach a particular level, a CNO must
satisfy all the set of process areas that are targeted for
improvement in a particular B-ITa domain. The levels are:
Level 1: Incomplete. At maturity level 1, processes related
to a particular B-ITa domain are usually not performed or
partially performed. It means such a particular domain is
not explicitly considered when a CNO strives for B-ITa.
Level 2: Isolated. At maturity level 2, processes are the
basic infrastructure in place to support a particular B-ITa
domain. They (i) are planned and executed in accordance
with a policy; (ii) employ skilled people who have adequate
resources to produce controlled outputs; (iii) are monitored,
controlled, and reviewed.However, such processes are
isolated initiatives that are not managed from the entire
Level 3: Standardized. At maturity level 3, processes
are directed to make improvements in the standardization
and management of a particular B-ITa domain. Processes
are performed from a CNO perspective (i.e., they are
cooperation initiatives). They are well characterized and
understood, and are described in standards, procedures,
tools, and methods.
Level 4: Quantitatively Managed. At maturity level 4,
processes use statistical and other quantitative techniques.
Quantitative objectives for quality and process performance
are established and used as criteria in managing the process.
3A detailed list of these generic goals can be found in 
Level 1: Incomplete
Level 2: Isolated
Level 3: Standardized
Level 4: Quantitatively Managed
Level 5: Optimized
Figure 3. The B-ITa levels.
Quality and process performance is understood in statistical
terms and is managed throughout the life of the process.
Level 5: Optimized. At maturity level 5, processes are im-
proved based on an understanding of the common causes
of variations inherent in the process. The focus of an op-
timized process is on continuously optimizing the range of
process performance through both incremental and innova-
4.3 The B-ITa domains
Once the levels are defined, domains where these lev-
els must apply need to be identified. A domain is a group
of processes that help to have improvements in a particular
CNO area. In previous work [37, 39, 40], we have reported
on how we have used a focus group and case studies to iden-
tify the domains that need to be addressed by CNOs in their
efforts for aligning business and IT. Fig.4 presents the fit
among the B-ITa domains. In the following, we give a short
summary of these domains.
• Partnering structure, defined as the CNO work divi-
sion, organizational structure, and roles and respon-
sibilities definition that indicate where the work gets
done and who is involved.
• IS architecture, defined as the fundamental organiza-
tion of the information management function of the
participating organizations embodied in the informa-
tion systems, i.e., software applications, that realize
this function, their relationships to each other and to
the environment, and the principles guiding their de-
sign and evolution.
IS ARCHITECTUREPARTNERING STRUCTURE
Figure 4. The B-ITa domains.
• Process architecture, defined as the choreography of
all (individual and collaborative) processes needed to
reach the shared goals of the participating organiza-
• Coordination, defined as the mechanisms to manage
the interaction and work among the participating or-
ganizations taking into account the dependencies and
the shared resources among the processes.
4.4The B-ITa process areas
Several theories and models, developed elsewhere, are
potentially useful to give insights for understanding the pro-
cesses related to B-ITa in CNOs (e.g., [4, 5, 12, 14, 17, 20,
21, 22, 25, 26, 27, 30, 33, 34, 43, 47, 48, 49]). Our position
is that it would be practical for CNOs to have a selection
of those processes in a single model. Fig.5 establishes a
map relating several theories and models to the four B-ITa
domains introduced in the previous subsection. It must be
noted that each theory and model covers much more than
the constructs (i.e., processes and process outcomes) we
present in the figure. That is, in our research, we take from
each theory/model those constructs only, which could have
a relation to the four B-ITa domains. Clearly, it can be ar-
a possible relation with the B-ITa domains. However, after
an exhaustive analysis of the theories and models, we de-
cided to include only general constructs. For example, the
‘Requirements development’ process of CMMI covers spe-
cific characteristics that are considered, in a general way, by
the ‘Requirement management’ process which we do take
into account in our mappings (see Fig.5). In this figure the
acronyms PS, IS, PA and CO stand for partnering structure,
IS architecture, process architecture, and coordination, re-
The leftmost and the rightmost columns in this figure
present the theories or models taken from the literature. By
‘model’ we mean a conceptual model, i.e., a set of con-
structs used to describe B-ITa or a domain of B-ITa; by
‘theory’ we mean a model plus claims about empirical rela-
tions between some concepts, i.e., correlational or causal
relationships. From each theory/model we have selected
constructs, assigned these to a B-ITa process area and as-
signed the B-ITa process area to a B-ITa domain. For exam-
ple, Gunderson’s theory of system safety analysis (depicted
in the upper left-hand corner of Fig.5) is mapped onto the
RAM B-ITa process area of the ICoNOs MM, where RAM
stands for Risk Analysis and Mitigation. The arrow con-
necting ‘system safety analysis’ to the oval labeled IS in-
dicates that this is associated to the IS architecture domain.
We make the note that the definitions of some constructs
made us decide to map them to more than one B-ITa process
area. Forexample, Hoque’stheoryofportfoliomanagement
can be applied to process architecture (PPM B-ITa process
area) and to IS architecture (IsPM B-ITa process area). The
assignment of process areas to domains is summarized in
Fig.6. It can be argued that the positioning of the processes
into a specific B-ITa level seems arbitrary. However, the
decisions for such a positioning were driven by the defini-
tion of each process and by what we have seen in the three
Recently, we began to conduct a new case study to identify
whether the process areas of the ICoNOs MM are present
in a real-life CNO, and to validate their positioning into the
model. It is too early to make a conclusion but from the
evidence obtained heretofore in the case study site, we can
anticipate that the SPD B-ITa process area could fit better
in level 3 of the IS architecture domain than in level 2.
4.4.1Partnering structure process areas
We present the B-ITa process areas (in alphabetical order),
grouped into the four B-ITa domains. For each process
area, we provide (in parentheses) the level in which the pro-
cess area is positioned, and the reference of the theory(ies)
and/or model(s) from we derived it.
Our model includes 7 process areas in the partnering
structure domain. These process areas are:
BMD Business model definition (L2). To define a blueprint
of how the CNO works, describing how different vari-
ables of the collaboration fit together as a system to
help creating value for each participant .
GSC Governance structure and compliance (L3). To struc-
ture the priorities and allocation of resources and de-
cision rights to create accountability; and to ensure
that activities are performed in conformity with poli-
cies and procedures. A successful compliance process
will be performed through definition of effective poli-
cies and procedures [22, 33, 47, 48, 49].
IoPD Inter-organizational policies definition (L3). To define
the plans of action, intended to influence and deter-
cies to increase mutual benefits perception and shared
MRE Metric-based exploration of roles (L4). To employ
approaches as relational exchange techniques, orga-
nizational communication’s mechanistic and system-
interaction methods to study organizational communi-
cation, structure and roles in the collaboration .
OSD Organizational structure definition (L2). Todefinethe
inter-organizational ties constructing a framework
for inter-organizational decision making and placing
power and authority in order to regulate the CNO
MODEL/THEORYCONSTRUCT (PROCESS/OUTCOME)CONSTRUCT (PROCESS/OUTCOME)MODEL/THEORY
RAMSystem safety analysis Quantitative exploration of rolesMREHolden & O'Toole
Service level agreements
Organizational structure definition
Shared risk and rewards - policies
Target architecture definition
Opportunities and gap analysis
Migration plan development
Implementation of the plans
HR organization and management
Roles and responsibilities specification
Decision rights allocation
Process standards specification
Target architecture definition
Opportunities and gap analysis
Migration plan development
Implementation of the plans
Business model definition
Collaborative decision making
Inter-organizational process optimization
IS architecture design
Architecture development processBAD
Bodenstaff, et al.
EFCModels formal consistency
Communication through/about architecture
Continous process improvement
Verification and validation
Quantitative project management
Organizational innovation and deployment
Organizational process focus
Organizational process definition
Organizational process performance
Causal analysis and resolution
IS capabilities definition
Policies and technical choices definition
Data architecture implementation
Application architecture implementation
Baseline technology arch. description
Architecture contract documentation
Plan and work processes standarization
Skills and norms standarization
Informal organizational structureQuantitative coordination analysisQRADecker & Lesser
B-ITa PROCESS AREAB-ITa PROCESS AREA
Figure 5. Map modeling theories applicable to the B-ITa domains.
RRS Roles and responsibilities specification (L3). To spec-
ify the roles and responsibilities, and their related
guide principles, of the participants in the CNO after
define its organizational structure .
SLA Service level agreements definition (L2). To describe
theagreementsonthedeliverables, quality, andfitness-
for-purpose of services that have an impact on the
work of each participating organization. A successful
implementation of these agreements will be delivered
through effective governance structure .
4.4.2IS architecture process areas
The ICoNOs MM covers 9 process areas into this domain.
These process areas are:
ATF IS architecture target formulation (L3). To evaluate,
select and design ISs needed to support the desired
to-be state of the IS architecture taking into account
business and IT drivers, and the processes to sup-
port [21, 22, 47].
AVV IS architecture verification & validation (L3). To per-
form periodically gap analysis to make sure chang-
ing IS requirements are managed in consistent fashion
with IS architecture targets. A successful verification
& validation will be performed through an effective IS
target formulation [14, 21].
BAD Baseline IS architecture description (L2). To create a
snapshot of the existing ISs and data, assessing what
the current status of the CNO is concerning ISs [21,
27, 47, 49].
IsCD IS capabilities definition (L3). To define the ability of
the collaboration to achieve new forms of competitive
advantage by ISs to achieve congruence with the busi-
ness environment where it works .
IsPM IS portfolio management (L3). To create the right mix
of information systems investments to properly use
limited resources while providing the maximum busi-
ness benefit. A successful IS portfolio management
will be delivered through the execution of the other IS
processes effectively [21, 27, 48].
IsRM IS requirements management (L2).
changing IS requirements during their engineering
process and the development of the required ISs .
To manage the
QPM Quantitative IS portfolio management (L4). To use
quantitative techniques to analyze, assess, and control
PARTNERING STRUCTURE IS ARCHITECTURE
Risk analysis and mitigation
Quantitative IS portfolio management
IS architecture target formulation
IS capabilities definition
IS architecture verification and validation
IS portfolio management
Baseline IS architecture description
Standards and principles definition
IS requirements management.
Metric-based roles exploration
Governance structure and compliance
Roles and responsibilities specification
Inter-organizational policies definition
Business model definition
Service level agreements definition
Organizational structure definition
PROCESS ARCHITECTURE COORDINATION
Inter-organizational process optimization
Causal analysis and resolution
Organizational process performance
Event logs formal consistency
Organizational process focus planning
Process architecture target formulation
Process architecture definition
Process portfolio management
Baseline process architecture description
Quantitative coordination relation analysis
Informal communication adjustment
Figure 6. The ICoNOs MM.
IS portfolio assets, managing such a portfolio from a
quantitative perspective .
RAM Risk analysis and mitigation (L5). To identify sources
of flaws and other problems (e.g., requirements incon-
sistencies, poor portfolio management, lack of IS prin-
ciples) in the IS architecture domain, and to take action
to prevent such situations in the future .
SPD Standards and principles definition (L2). To define
technology standards, policies and development prin-
ciples stating direction or practice on how the collabo-
ration should deal with the ISs [30, 43].
4.4.3Process architecture process areas
Our model includes 9 process areas which refer to this do-
main. These process areas are:
BPD Baseline process architecture description (L2). To cre-
ate a snapshot of the existing processes, identifying
and analyzing what the current status of the CNO is
concerning processes .
CAR Causal analysis and resolution (L5).
sources of flaws and other problems in the process ar-
chitecture domain, and to take action to prevent such
situations in the future .
EFC Event logs formal consistency (L4). To use event logs
for checking traceability of execution processes during
collaboration, and for controlling whether profitability
estimates are realized .
IoPO Inter-organizational process optimization (L5).
evaluate the process architecture in order to deploy in-
cremental and innovative improvements to gain inter-
organizational efficiency and competitive advantage.
A successful process optimization relies on effective
process focus planning and process architecture defi-
nition [14, 27, 48].
OPP Organizational process performance (L4). To estab-
lish and maintain a quantitative understanding of the
performance of the standard processes set in support of
PAD Process architecture definition (L3). To establish and
maintain a repository of CNO processes, assets and
work environment standards. A successful process ar-
chitecture definition depends on an effective baseline
process architecture description [14, 33].
PAF Process architecture target formulation (L3). To eval-
uate, select and design processes needed to support the
desired to-be state of the process architecture taking
into account business and strategy drivers [4, 22].
PFP Organizational process focus planning (L3). To plan,
implement, and deploy process improvements based
on a thorough understanding of strengths and weak-
nesses of the collaboration’s processes and process as-
sets. A successful process planning will be performed
through effective process architecture definition .
PPM Process portfolio management (L3). To direct limited
resources in terms of funds, people, etc., into the pro-
cesses to create a holistic process orientation [4, 27].
4.4.4Coordination process areas
The process areas covered by the ICoNOs MM into this do-
COC Communication-oriented coordination (L3). To agree
on communication channels, sharing knowledge and
learning in order to respond effectively to immediate
client’s needs and to determine what future markets
will require [12, 17, 27, 49].
DTS Direct supervision (L2). To supervise the work by spe-
cific persons who take the responsibility for the pro-
cesses, providing instructions to others and monitoring
their actions .
InCA Informal communication adjustment (L2). To adjust
and control the work among the participating organi-
zations by informal communication among the actors
outside the imposed hierarchical constrains for day-to-
day operations [12, 34, 49].
QRA Quantitative coordination analysis (L4). To use tech-
niques (e.g., causal model analysis) to link the inter-
relationships, called coordination relations, to the lo-
cal scheduling constraints of the participating organi-
STD Standardization (L3). To coordinate work and inter-
actions by standardizing the processes, outputs and/or
skills among the participating organizations [34, 47].
5.1Practical adoption of the ICoNOs MM
A key design decision that impacts adoption in practice
of the ICoNOs MM is the decision to assign separate matu-
rity level to each participant in a CNO. In other words, each
single participating organization within a CNO can have a
developed to assess the alignment of the entire CNO, the de-
cisions concerning achieving, or assessing, B-ITa in a CNO
can be made by one participating organization. Thus, not
all participants in a CNO have to adopt the ICoNOs MM,
or do so at the same time. While this design decision facili-
tates adoption, it is not the case that B-ITa maturity levels of
each participant in a CNO are completely independent. In-
stead, the maturity of one participating organization influ-
ences the maturity of the alignment between business and
IT of the entire CNO. For example, a participant with a spe-
cific level of B-ITa maturity as single organization can im-
pose other participants to collaboratively achieve the same
maturity level as a networked organization.
We consider chief officers of the partnering organiza-
tions in a CNO as the key users of the ICoNOs maturity
assessments. This assumption is motivated by published re-
sults of researchers (e.g. [8, 11, 23, 28]), which show that
the most powerful initial step to achieve B-ITa is to build
strong organizational support through strong commitment
of CIOs and/or CEOs. If chief officers want to improve
B-ITa, they need first to assess the processes related to B-
ITa, and commit as B-ITa catalysts and sponsors. Applying
these findings to our work, chief officers must be actively
involved in the CNO B-ITa project in at least three ways: (i)
influencing the CNO to use the ICoNOs MM, (ii) choosing
the best team to manage the B-ITa improvement effort, and
(iii) monitoring the assessment and improvement process in
each B-ITa domain. As the ICoNOs MM is a continuous
MM , it lets chief officers assess each B-ITa domain
separately (see Fig.7). This feature of the model will let
CNOs focus, for instance, on the domains with a low level
of maturity. Those domains that are associated with higher
maturity can, then, be candidates for inclusion in later im-
5.2 Preliminary Evaluation
At this stage of our work, we do not have empirical ev-
idence for the correlation between the ICoNOs MM’s do-
Figure 7. The pyramid view of the model.
cess in CNOs. Such a validation of the model is only possi-
ble after evaluating its design and population. However, we
is capable of dealing with any type of CNOs and for which
type of CNOs its results will bring most benefits (i.e., the
results would be most insightful). When conducting case
studies to validate the design of the MM, we made sure to
study different case study sites. We chose CNOs from dif-
ferent countries, one international and two of national na-
ture, one entrepreneur-led and two government agencies,
and one with a large amount of participants and two with
only 2 or 3 participating organizations. We must also note
that the B-ITa key drivers they have are different. The key
drivers of one of the studied CNOs are to control costs and
to manage risk, while the B-ITa key drivers of the other sites
are to improve quality and to increase effectiveness.
So far, we claim that the ICoNOs assessment results are
useful for CNOs that meet the CNO characteristics reflected
in our definition of CNO (see Sect. 2). That is, collabo-
rations where (i) participants pool costs, skills, and core
competences to provide world-class solutions that could not
be provided by any of them individually; (ii) information
systems are able in each of the participants to respond dy-
namically to meet the ever-changing customer needs and to
communicate and share information among them; (iii) par-
ticipants have a clear understanding of the common goal(s)
and the functions of each of the participating organizations
in order to know what is expected from each of them.
Some interesting open matters remain to be addressed to
produce a complete MM. First, we acknowledge that de-
spite the fact that we associated each process area to one
B-ITa domain only, these B-ITa process areas have an ef-
fect on each other regardless of the domain in which we
included them. For example, the process area of ‘Process
architecture target formulation’ is an input to the process
area of ‘IS architecture target formulation’ when addressing
a design of the information systems required to support the
CNO processes. We note that ‘IS architecture target formu-
lation’ is a process area in the IS architecture domain and
‘Process architecture target formulation’ is a process area
in the process architecture domain. To identify the possi-
ble relationships among the different process areas is part
of the work required to provide a complete MM. We also
want to provide a clear picture of the relations among the
B-ITa domains, as the MAAM  does.
Second, to have a complete MM, the ICoNOs MM must
incorporate specific goals and practices (see Sect. 4.1) de-
scribing characteristics that must be present to satisfy the B-
ITa process areas. These specific goals and practices could
be seen as the results to be achieved and the activities to
be performed in each of the process areas included in the
model. Third, validating a MM by means of a comparison
with another model is considered a difficult task, as there is
no reference model in practice.Therefore,for the EVALUATE
step of the MM development process presented in Fig.2,
we plan to use expert panels , focus groups [15, 45] and
testing pilots (where sponsorship from CNOs would be nec-
essary in order to use a prototype of the model to appraise
the maturity of theirB-ITa).
6 Conclusion and Future Work
The goal of this paper is to present (i) a process model
that can be used as a guide for developing maturity models,
and (ii) the first version of a maturity model to assess pro-
cesses related to business-IT alignment in collaborative net-
worked organizations (CNOs): the ICoNOs MM. Based on
an analysis of the potential applicability of several theories
and models in the area of business-IT alignment, we present
process areas grouped in four domains: partnering struc-
ture, IS architecture, process architecture and coordination
(see Sect. 4.3). These domains should be addressed by net-
worked organizations in their efforts to achieve business-IT
alignment. Unlike maturity models for assessing alignment
in single organizations, the ICoNOs MM is applicable at the
CNO level. This maturity model is a promising attempt to
properly understand the domains involved in collaborative
business-IT alignment in terms of process maturity.
We stress that the ICoNOs MM is a work in progress to
be further developed, revised, and eventually modified. De-
tails remain to be worked out in the future as more knowl-
edge becomes available from a case study we are conduct-
ing in a CNO to empirically identify whether the process
areas included in ICoNOs are present in the investigated
case study site. Our work for the immediate future includes
identifying the specific goals and practices for each of the
process areas (see Sect. 4.1). Future work also includes val-
idating the maturity model as a whole. We plan to use test-
ing pilots, expert panels and focus groups to address this
 O. Adelakun. IT outsourcing maturity model. In Proceed-
ings of the 13th European Conference on Information Sys-
tems, The European IS Profession in the Global Networking
Environment, ECIS’04, 2004.
 F. M. Barbini and A. D’Atri. How innovative are virtual
enterprises? In ECIS, 2005.
 S. Beecham, T. Hall, C. Britton, M. Cottee, and A. Rainer.
Using an expert panel to validate a requirements process
improvement model. Journal of Systems and Software,
 Blue-Crow. Business process modelling and analysis, 2007.
 L. Bodenstaff, A. Wombacher, and M. U. Reichert.
formal consistency between value and coordination models.
Technical Report TR-CTIT-07-91, Enschede, October 2007.
 W. C. Bogner and P. S. Barr. Making sense in hypercompet-
itive environments: A cognitive explanation for the persis-
tence of high velocity competition. Organization Science,
 P. Brereton, B. A. Kitchenham, D. Budgen, M. Turner, and
M. Khalil. Lessons from applying the systematic literature
review process within the software engineering domain. J.
Syst. Softw., 80(4):571–583, 2007.
 M. Broadbent and E. Kitzis. Interweaving business-driven
IT strategy and execution: Four foundation factors. Ivey
Business Journal, 69(3):1–6, 2005.
 L.M.Camarinha-MatosandH.Afsarmanesh. Collaborative
Networked Organizations: A Research Agenda for Emerg-
ing Business Models. Kluwer Academic Publishers, 2004.
 L. M. Camarinha-Matos and H. Afsarmanesh. The emerging
discipline of collaborative networks. In Virtual Enterprises
and Collaborative Networks, pages 3–16. Kluwer Academic
 B. Campbell.Alignment: Resolving ambiguity within
bounded choices. In Proceedings of the PACIS 2005, pages
1–14, Bangkok, Thailand, 2005.
 Y. E. Chan. Why haven’t we mastered alignment? the im-
portance of the informal organization structure. MIS Quar-
terly Executive, 1(21):76–112, 2002.
 Y. E. Chan, S. L. Huff, D. W. Barclay, and D. G. Copeland.
Business strategic orientation, information systems strategic
orientation, & strategic alignment. Information Systems Re-
search, 8:125–150, 1997.
 CMMI Product Team. CMMI for Development, Version 1.2:
Improving processes for better products., 2006.
 D. R. Cooper and P. S. Schindler. Business Research Meth-
ods. Boston, [Mass., etc.]: McGraw-Hill, 8th edition, 2003.
 D. Damian.Stakeholders in global requirements engi-
neering: Lessons learned from practice. IEEE Software,
 M. Daneva and R. Wieringa.
ity model to support requirements engineering for cross-
organizational ERP. In RE’06: Proc. of the 14th IEEE Int.
Requirements Engineering Conference, Minneapolis, MN,
A coordination complex-
 E. W. Davis and R. E. Spekman. The Extended Enterprise:
Gaining Competitive Advantage through Collaborative Sup-
ply Chains. Financial Times Prentice Hall, 2003.
 D. de Koning and P. van der Marck. IT Zonder Hoofdpijn:
Een Leidraad voor het Verbeteren van de Bedrijfsprestaties.
Prentice Hall, 2002. In Dutch.
 K. Decker and V. Lesser.
ordination relationship. Group Decision and Negotiation,
 DOC Enterprise IT Architecture Advisory Group. Informa-
tion technology architecture: What is it, why should you
care, and how do you do one?, 2004.
 J. Duffy. Maturity models: Blueprints for e-volution. Strate-
gic and Leadership, 29(6):19–26, 2001.
 B. A. Edwards. Chief executive officer behaviour: The cat-
alyst for strategic alignment. Journal of Value-Based Man-
agement, 13(1):47–54, 2000.
 Federal Architecture Working Group. Architecture Align-
ment and Assessment Guide. The Federal Chief Information
Officer Council, 2000.
 S. Gunderson. A review of organizational factors and ma-
turity measures for system safety analysis.
 M. T. Holden and T. O’Toole. A quantitative exploration
of communication’s role in determining the governance of
Management, 33(6):539–548, 2004.
 F. Hoque. The Alignment Effect. FT Press, 2002.
 G. S. Kearns and A. L. Lederer. A resource-based view
of strategic IT alignment: How knowledge sharing cre-
ates competitive advantage. Decision Sciences, 34(1):1–29,
 T. Knothe, K. Schneider, D. B¨ ol, T. Kahl, S. Schuster,
F. Lillehagen, J. Krogstie, and H. G. Solheim. Framework
for the establishment and management methodology, 2005.
Deliverable A.1.4.1, ATHENA, Integrated Project Contract
 J. Luftman. Assessing IT-business alignment. Information
Systems Management, 20:9–15, 2003.
 A. Magalhaes, R. Ara´ ujo, and M. R. S. Borges. Designing
collaborative processes. In Proceedings of the 8th Workshop
on Business Process Modeling, Development and Support
(BPMDS’07) in the 19th International Conference on Ad-
vance Information Systems Engineering (CAISE’07), 2007.
 K. McCormack and A. Lockamy. The developmentof a sup-
ply chain management process maturity model using the
concepts of business process orientation.
Management, 9(4):272–278, 2004.
 META Group. Architecture maturity audit: Part 1. META
Practice, 4(4), 2000.
 H. Mintzberg. Structure in Fives: Designing Effective Or-
ganizations. Prentice Hall, Englewood Cliffs, NJ., second
 R. Santana Tapia. What is a networked business? Technical
Report TR-CTIT-06-23a, University of Twente, Enschede,
The Netherlands, 2006.
 R. Santana Tapia and N. Zarvi´ c. Value-based partnering
structure design for networked businesses: A multi-method
approach. In Proceedings of 21st Bled Conference “eCol-
laboration”, pages 263–276, Bled, Slovenia, 2008.
Analyzing a quantitative co-
 R. Santana Tapia, M. Daneva and P. van Eck. Business-
IT alignment domains and principles for networked orga-
nizations: A qualitative multiple case study. 3rd Interna-
tional Workshop on Enterprise Integration, Interoperability
and Networking. EI2N’08. Submitted and under review.
 R. Santana Tapia, M. Daneva and P. van Eck. Developing an
inter-enterprise alignment maturity model: Research chal-
lenges and solutions. In C. Rolland, O. Pastor, and J.-L.
Cavarero, editors, Proc. of the 1st Int. Conf. on Research
Challenges on Information Science (RCIS’07), pages 51–59,
Ouarzazate, Morocco, 2007.
 R. Santana Tapia, M. Daneva and P. van Eck. Validating
adequacy and suitability of business-IT alignment criteria
in an inter-enterprise maturity model.
the Eleventh IEEE International EDOC Enterprise Comput-
ing Conference, Annapolis, MD, USA, pages 202–213, Los
Alamitos, October 2007. IEEE Computer Society Press.
 R. Santana Tapia, P. van Eck and M. Daneva.
organizational business-IT alignment maturity: Validating
the domains of an alignment assessment instrument. Inter-
national Conference on Information Systems, ICIS’08. Sub-
mitted and under review.
 N. Ramasubbu, M. Krishnan, and P. Kompalli. A process
maturity framework for managing distributed development.
IEEE Software, 22(3):80–86, 2005.
 B.H.ReichandI.Benbasat. Developmentofmeasurestoin-
nology objectives. MIS Quarterly, 20:55–81, 1996.
 J. Ross. Creating a strategic IT architecture competency:
Learning in stages. MISQ Executive, 2(1):31–43, 2003.
 J. Schekkerman. Extended Enterprise Architecture Maturity
Model Support Guide v2.0. Institute for Enterprise Archi-
tecture Developments, 2006.
 Y. Simmons. Using focus groups as an applied research tool.
Howe’s Now, 6(2), Apr 2000.
 D. Tapscott, D. Ticoll, and A. Lowy. Digital Capital - Har-
nessing the Power of Business Webs. Nicholas Brealy Pub-
 The Open Group. The Open Group Architecture Framework
TOGAF –2007 edition (Incorporing 8.1.1). Van Haren Pub-
 M. van den Berg and M. van Steenbergen. DYA: Stap voor
stap naar professionele enterprise-architectuur. Ten Hagen
& Stam uitgevers, 2004. In Dutch.
 B. van der Raadt, J. F. Hoorn, and H. van Vliet. Align-
ment and maturity are siblings in architecture assessment.
In CAISE ’05: Proceedings of the 17th International Con-
ference on Advanced Information Systems Engineering, vol-
ume 3520/2005 of LNCS, pages 357–371, Porto, Portugal,
 H. van der Zee, P. Laagland, and B. Hafkenscheid. Architec-
tuur als Managementinstrument: Beheersing en Besturing
van Complexiteit in het Netwerktijdperk. Ten Hagen Stam
Uitgevers, 2001. In Dutch.
 P. van Eck, H. M. Blanken, and R. Wieringa.
GRAAL: Towards operational architecture alignment. In-
ternational Journal of Cooperative Information Systems,
13:235–255, Sep 2004.
In Proceedings of