On the Goal Domain in the RM-ODP Enterprise Language: An Initial Appraisal Based on a Foundational Ontology
ABSTRACT The “goal domain” addresses objectives in a broad scope ranging from high-level statements expressing the vision and mission of an organization (or community) to declarations of the results that must be achieved by business process execution. This paper reviews the support for the goal domain in ISO RM-ODP. We analyze the conceptualization for goals (objectives) in the reference model's Enterprise Viewpoint using a fragment of the Unified Foundational Ontology (UFO) that deals with some aspects of social reality and intentionality. The interpretation of the RM-ODP concepts in terms of this foundation may help to provide a sound underpinning for these concepts and support the identification of possible extensions of the reference model.
- [Show abstract] [Hide abstract]
ABSTRACT: Enterprise Architecture (EA) promotes the establishment of a holistic view of the structure and way of working of an organization. One of the aspects covered in EA is associated with the organization's "active structure", which concerns "who" undertakes organizational activities. Several approaches have been proposed in order to provide a means for representing enterprise architectures, among which the ArchiMate, an EA modeling language. In this paper, we present a semantic analysis of the fragment of the ArchiMate metamodel related with the representation of active structure. In addition, we present a proposal to extend the metamodel based on a well-founded ontology for the organizational domain. Our objective is to enrich the language with important capabilities to represent organizational structures using a principled ontology-based approach.FOIS/FOMI, Rio de Janeiro; 07/2014
Conference Paper: An Ontological Analysis of the ISO/IEC 24744 Metamodel[Show abstract] [Hide abstract]
ABSTRACT: This paper presents an ontological analysis of the Software Engineering Metamodel for Development Methodologies (SEMDM), provided by the ISO/IEC 24744 Standard. An ISO initiative intends to use SEMDM as source of an ontology for standards harmonization purposes, and the ontological analysis can help to ensure the required semantics. This analysis is done in the light of the Unified Foundational Ontology (UFO). As result, we present some of the problems identified in SEMDM, as well as alternative model fragments solving them.FOIS 2014 - 8th International Conference on Formal Ontology in Information Systems; 09/2014
- [Show abstract] [Hide abstract]
ABSTRACT: Enterprise Architecture (EA) promotes the establishment of a holistic view of the structure and way of working of an organization. One of the aspects covered in EA is associated with the organization's "active structure", which concerns "who" undertakes organizational activities. Several approaches have been proposed in order to provide a means for representing enterprise architectures, among which the ArchiMate, an EA modeling language. In this paper, we present a semantic analysis of the fragment of the ArchiMate metamodel related with the representation of active structure. In addition, we present a proposal to extend the metamodel based on a well-founded ontology for the organizational domain. Our objective is to enrich the language with important capabilities to represent organizational structures using a principled ontology-based approach.FOMI; 07/2014
Wo or rk ks sh ho op p o on n O OD DP P f fo or r E En nt te er rp pr ri is se e C Co om mp pu ut ti in ng g
WO OD DP PE EC C 2 20 01 10 0) )
Peter F. Linington, José Raúl Romero, Antonio Vallecillo (Eds.)
Vitória, ES, Brazil. October 25, 2010
In conjunction with:
The 14th International IEEE Enterprise
Distributed Object Computing Conference
25-29 October 2007, Vitória, ES, Brazil
Peter F. Linington
School of Computing
University of Kent
Kent, CT2 7NF (UK)
José Raúl Romero
University of Córdoba
Escuela Politécnica Superior
Dpto. Informática y Análisis Numérico
Campus de Rabanales
14071 Córdoba (Spain)
University of Málaga
29071 Málaga (Spain)
© The authors
Impreso en España – Printed in Spain
Table of Contents
Preface ………………………………………………………………………………………… v
Reflective Federation of Enterprises in Open Service Ecosystem
Lea Kutvonen………………………………………….……………………………… 1
Systems Planning Using ODP
Arve Meisingset…..…………………………………………………………………... 7
The Stereochemistry of Enterprise Objects
Peter F. Linington…………………………………………........................................... 11
On the Goal Domain in the RM-ODP Enterprise Language: An Initial Appraisal Based on a
Joao P. Almeida, Evellin Cardoso, Giancarlo Guizzardi………………………............ 19
Contract Management in Multi-Viewpoint Specifications- Experiment in the Electrical Network and
the SOA Domains
Bruno Traverson………………………………………………………………………. 29
On the Use of ODP Graphical and Textual Specifications
Daniel Ruíz-González, Antonio Vallecillo and José Raúl Romero..…………………. 43
List of Authors
Almeida, João Paulo A.
Linington, Peter F.
Romero, José Raúl
João Paulo A. Almeida
Peter F. Linington
José Raúl Romero
Marten van Sinderen
Federal Univ. of Espírito Santo (Brazil)
Stevens Institute of Technology (US)
University of Helsinki (Finland)
University of Kent (UK)
University of Córdoba (Spain)
University of Twente (The Netherlands)
Novay (The Netherlands)
EDF R&D (France)
University of Málaga (Spain)
Agile Enterprise Ltd (UK)
The present volume contains the papers selected for presentation at the EDOC 2010 Workshop on
ODP for Enterprise Computing (WODPEC 2010).
As stated in the Call for Papers (http://www.rm-odp.net/events/wodpec2010), the RM-ODP
standard (ISO/IEC 10746 | ITU-T Rec. X.901-X.904, Reference Model of Open Distributed
Processing) provides a comprehensive and coherent framework of concepts for the specification of
complex large scale IT systems, and has taken on a new significance in the light of the Model-
Driven Architecture (MDA) initiative from the OMG and the wide-scale adoption of Service-
Oriented Architectures (SOA) as well as the emerging concepts of Enterprise Architecture (EA).
Thus, we are witnessing major companies and organizations starting to use RM-ODP as an effective
approach for structuring their large-scale distributed IT system specifications. With this increase in
the significance of the RM-ODP comes the need to address a range of issues arising both from the
practical application of its concepts and from its relationship with other enterprise architectural
frameworks. Examples of concept application are the achievement of effective and integrated
business and service modelling, the complexity of specifying policy, security and system
management requirements, the specification of coherent and consistent multi-viewed systems, and
the use of UML as the language for ODP system modelling. Other frameworks and methodologies
include the relationship between the RM-ODP and SOA, CBA, or EDA, the integration of ODP-
based projects into development processes such as RUP, the relationship of the RM-ODP to EA
frameworks such as TOGAF, DoDAF, or Archimate.
Following the success of previous WODPEC events (since 2004) as a traditional IEEE EDOC
Workshop, WODPEC 2010 aims to continue to provide a discussion forum where researchers,
practitioners, system modellers, tool developers and representatives of standardization bodies can
meet and exchange experiences, problems and ideas related to the ODP framework for system
specification, its practical application and long term evolution, and its use in conjunction with other
architectural practices and approaches (e.g., MDA, SOA, CBA, EDA) in the realm of Enterprise
This volume contains the proceedings of the sixth workshop, WODPEC 2010, held on October
25th, 2010, in Vitória, Brazil, in conjunction with the 14th IEEE International EDOC Conference –
The Enterprise Computing Conference (EDOC 2010). Six papers were selected for oral presentation
and publication, based on a thorough peer-review process, in which each paper was reviewed by
several experts in the field.
Contributions this year fall broadly into two groups. The first is concerned with the scope and field
of application of the ODP framework, and the second explores aspects of the modelling techniques
used to express the framework.
There are two papers in the first group, both concerned with extending the scope of the work to
capture more information about the planning for and dynamics of new developments. Kutvonen
discusses the extension of the organizational description to allow a more dynamic business ecology,
in which metainformation repositories are used to allow the application of reflective techniques in
the rapid creation of virtual enterprises. This approach is illustrated by reference to their Pilarcos
architecture. Meisingset concentrates on the large scale planning and provisioning activities that
occur when a large organization, such as a telecoms company, enters a new business area. He puts
the case for adding additional concepts to support the planning and deployment aspects of system
provision, allowing more emphasis to be placed on the specific system instances needed to realize
the design produced. The argument is supported by detailed discussion of the interaction and data
definition aspects from both the class and instance points of view.
The second group covers a number of specific aspects of the framework. Almeida, Cardoso and
Guizzardi consider a high level view of system specification, discussing the representation of
objectives in the enterprise viewpoint, applying the Unified Foundational Ontology (UFO) so as to
deal more accurately with issues of social reality and intentionality. They show how a broad range
of objectives, from high-level statements expressing the vision and mission of an organization to
declarations of the results that must be achieved by business process execution, can all be integrated
within a single conceptual framework. Linington also concentrates on the enterprise viewpoint, but
examines detailed issues concerning in the representation of communities and community
composition, particularly the way role-filling constraints are expressed when communities are
abstracted to yield community objects. He proposes techniques for improving modularity by
associating constraints with the abstraction and role-filling relationships involved.
Traverson tackles issues of traceability in viewpoint based frameworks, concentrating on contract
management and service composition as a source of examples. He proposes a solution using a
systematic process based on reliable construction techniques, and supports the proposal by
describing its use to solve practical problems that arise when applying a service oriented
architecture in the electricity supply industry. Finally, Ruiz-González, Vallecillo and Romero look
at the balance between using visual and textual notations for expressing large system specifications
and how the advantages of both can be achieved by providing suitable synchronization mechanisms.
They present synchronization algorithms and demonstrate that the process can be automated by
describing a prototype tool.
We would like to thank the EDOC 2010 organization for giving us the opportunity to organize the
workshop, especially to the General Chair, João Paolo Almeida, the PC Chairs, Giancarlo
Guizzardi and Lea Kutvonen, and to the Workshop Chair, Maria-Eugenia Iacob, for their
assistance and continuous support. Particular thanks are due to all those that submitted papers, and
particularly to the contributing authors. Our gratitude also goes to the paper reviewers and the
members of the WODPEC 2010 Program Committee, who helped in choosing and improving the
Vitória, ES, Brazil, October 2010
Peter F. Linington, José Raúl Romero and Antonio Vallecillo
WODPEC 2010 Organizers
Reflective federation of enterprises in open service ecosystem
Department of Computer Science
University of Helsinki, Finland
Abstract—The present trend of enterprise computing is
towards networked business, and thus there is a high demand
on a new layer of global infrastructure that facilitates collabo-
ration management and provides utilities for interoperability.
This paper discusses the open ecosystem architecture of Pilar-
cos, and especially the role of metainformation repositories in it
to support reflective control that keeps the ecosystem structures
consistent but dynamic.
Keywords-open business service ecosystem; enhancement and
application of ODP concepts; reflective infrastructure
The present trend of enterprise computing is towards net-
worked business, and thus there is a high demand on a new
layer of global infrastructure that facilitates collaboration
management and provides utilities for interoperability.
Collaboration support infrastructures or models, or breed-
ing environments for virtual enterprises, have been intro-
duced for solving this need. Examples include Pilarcos ,
ECOLEAD , Athena , and CrossWork . In addition,
these projects also address the system and service software
engineering aspects in such environment, based on model-
driven techniques. (Throughout this paper we use the terms
virtual enterprise and business network in an almost ex-
This paper discusses the open ecosystem architecture
of Pilarcos, and especially the role of metainformation
repositories in it to support reflective control that keeps the
ecosystem structures consistent but dynamic. The Pilarcos
architecture has been developed in alignment of the concepts
defined in ODP reference model , , as described in
earlier papers , .
Section 2 provides an overall view of the service ecosys-
tem, while Section 3 introduces it from the reflective system
model perspective. Section 4 concludes by discussing how
the ecosystem architecture differs from a single enterprise
II. OPEN BUSINESS SERVICE ECOSYSTEM
In biology, an ecosystem means an environment where
flora and fauna lives and dies, utilises resources and interact
with each other, and eventually, new spieces can develop.
This behaviour is restricted by laws of nature, or by for
example human interventions.
Similarly, inter-enterprise collaborations that are governed
by multi-party contracts, can be bread, run their natural
lifecycle, be terminated, and leave experience knowledge
behind. We call such an environement open business service
ecosystem since we choose to focus on service-oriented
computing and keep business services aligned with their
software counterparts, and vice versa.
Figure 1 illustrates the ecosystem structure. On the left
side, metainformation is brought to the system by designers
and analyzers concerning
• available services from service providers (enterprises
including public and private sector providers),
• publicly known business scenario descriptions that we
call business network models (compositions of sets of
business process descriptions, with required associa-
tions between roles to be simultaneously occupied);
• reputation information that allows terminating collabo-
rations to report failures and successes in the ecosystem
to advise further collaboration decisions.
The bottom part represents the global, federated infras-
tructure services that provide services for business service
and partner detection and selection, econtract establishment,
monitoring and breach detection, and reputation manage-
ment facilities to support trust management with. The top
part represents the lifecycle of each collaboration (virtual
enterprise) from negotiation to termination phase.
The different ecosystem building projects we have studied
differ in automation and control aspects of negotiation,
operational time monitoring, and feedback generation for
private and public collaboration and interoperability knowl-
For example, in Pilarcos, the negotiation phase is ”demo-
cratic” as all potential partners can participate in the business
network model definition process, and the service discov-
ery process. Only when the final decision-making phase
including final commitment to the formulated contract is
performed, the decisions are made at each partner according
to private rules. In contast, ECOLEAD and CrossWork
allow a coordinator to do the selection, and the selected
partners start negotiating about the roles and interaction
patters suitable for the business case at hand and the compe-
tencies of the partners. This phase also illustrates the more
automation-oriented style in Pilarcos, while in the two other
architectures, the role of infrastructure is support human
Furthermore, an important feedback aspect in the ecosys-
tem is that of reputation information generation. The
reputation-based trust management concept facilitates the
scalability of the ecosystem. Interestingly, we can here rely
on social ecosystem studies : the number of potential
partners in the ecosystem is limited to very small numbers
if there is no behavior norms established, and only slightly
higher numbers if there is sanctions for misbehaving. How-
ever, if also leaving misbehaviour unreported is considered
as misbehaviour, an increasingly large ecosystem can be
kept alive. The reputation production mechanism together
with the negotiation step where partners can reflect the
collaboration suitability for their strategies, their resources,
and the potential risk predicted with reputation information
creates a cycle that has this necessary control function.
Simply, it emulates the social or legal system pressure of
business domain. This functionality is much missing from
The main five challenges in such an ecosystem have been
• support functions to match the mangement needs; in-
cluding service discovery and selection, eContracting,
and breach management ;
• support of ecosystem evolution by a coherent knowl-
edge base; this includes the control of collaboration
types and available services and interoperability man-
agement information (discussed further in the next
• support of regulation of collaborations in such a way
that only acceptable collaboration types are allowed,
and by controlling the behaviour of services through
contracts and enterprise policies ;
• support of private decision-making on collaborations;
this includes expert system of enterprise to make de-
cisions and commitments and trust decisions involve-
• global software application system production; this
involves production methods for service software and
coordination models, and definition of open service
ecosystem quality requirements for software.
III. REFLECTIVE MODEL
A reflective system is a system that can reason about its
own structure, behaviour and state, and furthermore, can
act upon itself. For reasoning and action triggering, the
system includes a causally connected metalevel model of
its own characteristics, making it able to detect changes
in itself or its environment, make decision based on that
information, and change its own status or create interaction
with its environment. To quote the original definition :
”We define computational reflection to be the behavior
exhibited by a reflective system, where a reflective system
is a computational system which is about itself in a causally
The concept has successfully been applied on context
sensitive and adaptive applications, or rather, on the mid-
dleware level that supports such applications: reflective
A. Contract-base governance of business networks
In the construction of the infrastructure model for the
open business service ecosystem, the reflection model has
been used together with a multiagent system model. Figure 2
illustrates the situation as follows.
Here, the topmost model ”system model” refers to the
business network system model embedded to an eContract
after it has been established and committed to by all parties.
This model, i.e. contract, can be changed by a) human ad-
ministrators at the involved enterprises requesting so through
their expert systems, or b) asyncronous event rised by the un-
derlying system, i.e. any of the services themselves detecting
a situation requiring attention. An attention requiring event is
such that does not conform to the criteria set in the contract
(either by a service itself detecting a failure or someone
else in the business network detecting a breach). This event
can be handled by the contract (agent) automatically or the
decision can be forwarded for human intervention (necessary
to control the amount of automation in precence of business
and legal consequences of actions).
Viewing the managed system itself, the situation becomes
more complicated, as the business services involved are not
under the control of a single autority, but belong to separate,
independent administrative domains. Thus, the willingness
to perform actions, capability and implementation of the
actions, and representation of the information related to the
expected actions may differ significantly. We do not suggest
harmonisation of the system and platform level, since one
of the main goals of the architecture is to allow evolution -
also on this technical level.
We can require the causal connection to be held be-
tween the eContract and the business network structures
and criteria, but cannot assume that the causal connection
would be completely unified. Therefore, the solution has two
parts. First, for each role in the contract there is a causal
connection with the supporting business service at the pro-
viding enterprise. Second, the contract agent forms a shared-
vocabulary messaging environment for the agents represent-
ing participating enterprises. These enterprise agents are
responsible of keeping their local services in syncrony with
the committed contract status; here we use the reflective
model again to allow a variety of techniques to be utilised
locally. Beween themselves the enterprise agents need to use
protocols familiar from multi-agent systems or speech act
theories: definitions and declarations, requests, suggestions,
commitments, and opinions.
Figure 1. Overview of the open business service ecosystem
It is inevitable that at some point of time the enterprise
agents either fail to manage their local services as promised,
do not agree on the contract status or changes to it, or cannot
find a way to resolve a breach detected in the underlying
system. This is normal in business, so it should not be
considered as faulty behaviour of the supporting software
The remaining block of desing is that of monitoring
collaboration behaviour. Each enterprise has their local
policies and in addition, the contract brings in a set of
polies and processes specific for the collaboration instance
it governs. This metainformation can be transformed to
simple monitoring rules that are executed by the underlying
computing platform supporting a specific service. We might
say that the reflective model is here utilised in the opposite
direction: the running system is made to reflect the changing
expectations towards it, and to trigger corrections to the
model where the real system is not in syncrony with those
In comparison to the related work mentioned before, the
Pilarcos approach has more focus on the runtime control
of the virtual enterprises /business networks. The other ar-
chitectures mentioned focus on the establishment phase, and
utilise business process descritions with distributed workflow
engines to guarantee correct execution. However, our goal
has been to minimize the platform requirements in favour of
asyncronous evolution steps at each enterprise. Instead, we
use monitoring of agent-like, active business services instead
of assuming passive, reactive business services invoked by
Figure 2. Overview of the reflective management by contracts
the workflow engines.
In respect of associations to ODP reference model, the
system presents a federated system. The federation is formed
by enterprise agents jointly governing the business network
by sharing the eContract.
B. Keeping interoperability knowledge coherent
As described above, the ecosystem lifecycle requires
coherent models and metainformation to be fed into the
infrastructure knowledge repositories, desribing business
network models, available services, reputation, and further-
more, service type information to form a shared ontology or
vocabluary for the other categories of items.
The operational time reflective model can only succeed,
if the models available conform to the Pilarcos require-
ments. Therefore, for each repository (service offer repos-
itory, type repository, business network model repository),
several metamodel layers have been carefully designed.
These layers give rules and ontology for the ecosystem
concepts (such as collaboration, service, contract), service
software development methodology phases and artefacts,
infrastructure functions and artefacts manipulated by them,
and interoperability knowledge items, their relationships and
ways of storing them.
An interesting aspect of these models is that they also
bind together, and thus, the design and production time
artefacts become also artefacts at the operational time.
The set of metamodels together form a construction that
gives sufficient rules to keep the interoperability knowledge
and collaboration contracts coherent, thus ensuring that the
reflection mechanism at operational time works correctly.
In addition, the layers of models ensure that the knowl-
edge bases are extendable as new concepts, such as new
nonfunctional service properties or new service types are
In practice, when designers and analyzers try to enter
information items and models to the repositories, the cor-
responding metamodel layers will be used to study, whether
the suggestion is correct. If not, the designers can be given
advise on how to improve the proposal. The designers
may also study existing artefacts in the repositories, assess
their relationships and create relationship links between the
artefacts. For these relationships, similar modeling layers
exists, and thus, at this phase too, advise on analysts may
The implementations of the repositories cannot be cen-
tralised for two reasons: technical scalability and need for
separate alliances at the business level. However, the coher-
ence of uppermost concept models across the repositories
sufficies for federating the repositories. The same mecha-
nisms that are present for evolution support also support
interoperability between these repositories.
A common way of describing the interplay of business
and computing solutions is though enterprise architecture
work. In this paper, we have however considered an open
ecosystem in which business networks, i.e. inter-enterprise
collaborations are desinged, established, terminated, and
evaluated. In describing the ecosystem, the enterprise archi-
tecture frameworks (such as Zackman  or TOGAF )
fail mainly for two reasons.
First, the frameworks are static by supporting an inventory
for ”current situation” and a goal state definition. Their
usage is more suited for decision-making on what kind of
new investements for resources, knowledge and processes
to choose. In contrast, the ecosystem architecture needs to
support processes by which a constant, dynamic change is
supported in the system. We have adopted a reflective and
federative way of supporting the evolution of the system,
thus keeping the change process scalable.
Second, the frameworks are designed to consider artefacts
and activities that the enterprise owns. In contrast, the
ecosystem architecture must utilise processes where own-
ership and decision-making authority is not guaranteed. We
have adopted a multi-agent system pattern to be combined
with the reflective model to overcome this difficulty.
 L. Kutvonen, J. Metso, and S. Ruohomaa, “From trading
to eCommunity management: Responding to social and
contractual challenges,” Information Systems Frontiers (ISF)
- Special Issue on Enterprise Services Computing: Evolution
and Challenges, vol. 9, no. 2–3, pp. 181–194, Jul.
2007. [Online]. Available: http://dx.doi.org/10.1007/s10796-
 L. M. Camarinha-Matos and H. Afsarmanesh, “Virtual enter-
prise modeling and support infrastructures: Applying multi-
agent system approaches,” in Multi-Agent Systems and Appli-
cations. LNCS2086. Springer, 2001.
 A. J. Berre, B. Elvester, N. Figay, C. Guglielmina, S. G.
Johnsen, D. Karlsen, T. Knothe, and S. Lippe, “The athena
interoperability framework,” in Enterprise Interoperability II.
 N. Mehandjiev and P. Grefen, Dynamic Business Process
Formation for Instant Virtual Enterprises. Springer, 2010.
 Information Technology – Open Systems Interconnection,
Data Management and Open Distributed Processing. Refer-
ence Model of Open Distributed Processing. Part 2: Founda-
tions, ISO/IEC JTC1, 1996, iS10746-2.
 Information Technology – Open Systems Interconnection,
Data Management and Open Distributed Processing. Refer-
ence Model of Open Distributed Processing. Part 3: Archi-
tecture, ISO/IEC JTC1, 1996, iS10746-3.
 L. Kutvonen and J. Metso, “Services, contracts, policies
and ecommunities – relationship to ODP framework,” in
 L. Kutvonen, “What applying of the ODP viewpoints
teaches us about tool-chains,” in 10th IEEE International
Hong Kong: IEEE Computer
 E. Fehr and U. Fischbacher, “The nature of human altruism,”
Nature, October 2003.
 L. Kutvonen, T. Ruokolainen, S. Ruohomaa, and J. Metso,
“Service-oriented middleware for managing inter-enterprise
collaborations,” in Global Implications of Modern Enterprise
Information Systems: Technologies and Applications, ser.
Advances in Enterprise Information Systems (AEIS).
Global, Dec. 2008, pp. 209–241. [Online]. Available:
 T. Ruokolainen and L. Kutvonen, “Managing interoperability
knowledge in open service ecosystems,” in Proceedings
of the 13th Enterprise Distributed Object Computing
Conference Workshops, EDOCW.
Auckland, New Zealand:
 S. Ruohomaa and L. Kutvonen, “Making multi-dimensional
trust decisions on inter-enterprise collaborations,” in Proceed-
ings of the Third International Conference on Availability,
Security and Reliability (ARES 2008).
IEEE Computer Society, Mar. 2008, pp. 873–880. [Online].
 P. Maes, “Computational reflection,” Ph.D. dissertation, 1987.
 G. Coulson,“Whatis
 J. A. Zachman, “A framework for information system archi-
tecture,” IBM Systems Journal, vol. 26, no. 3, pp. 276–292,
 The Open Group, “Togaf 8.1.1 online,” Tech. Rep.,
Systems Planning using ODP
Corporate Development. Telenor ASA.
Snarøyveien 30C 1360 Fornebu. Norway
Abstract — The objective of ODP is according to ITU-T
Recommendation X.901 stated as follows: “The objective of
ODP standardization is the development of standards that
allow the benefits of distributing information processing
services to be realized in an environment of heterogeneous IT
resources and multiple organizational domains. These
standards address constraints on system specification and the
provision of a system infrastructure that accommodate
difficulties inherent in the design and programming of
distributed systems.” This objective seems to cover planning
and interworking of IT systems within an organization, such as
a telecom operator. Therefore, we in this paper discuss the
needs of an Overall IT Plan, and discuss the use of ODP for
specifying the solution. We indicate that the current ODP may
be too abstract for the purpose, and indicate how to adapt
ODP to fit the purpose.
WHAT IS SYSTEMS PLANNING?
When a Telecom Operator wants to start a new operation
in a new country, he typically has to purchase and install
several ten-folds of new IT systems and integrate these
through hundreds of interfaces. Systems Planning addresses
what IT systems are wanted, will be or are installed.
Interworking Planning addresses what interfaces are
wanted, will be or are installed between the IT systems.
There needs not be only one database of each IT system, as
the data may be partitioned, eg into regional partitions. This
partitioning we call Application Planning. The Interworking
Planning needs to cover interfaces between the partitions, as
well as between the system classes. And if there are overlaps
between Applications or System (classe)s, a data mastering
regime needs to be defined.
Systems Planning is made for a certain Organization or
structure of organizations. Organization Planning is outside
the scope of this paper, but the IT Plans will have to be based
on the given Organization, and will need to map to this
Organization. An IT Planning methodology may need to
combine IT Planning and Organization Planning.
Systems Planning is not only needed for Greenfield
Operators, but may also be needed for incumbants. Systems
Planning may be carried out before starting in-house new
development, when starting acquisition of externally
developed software packages, when wanting to modify
existing IT systems, when wanting to modify the integration,
when wanting to migrate to a new platform or infrastructure,
when wanting to change the sourcing regime, or when
wanting to reorganize the company.
Systems Planning is about designing the large
components of the IT solution. Systems Planning does not
address the detailed design of functions, interfaces or work
We ask in this paper how ODP is prepared for the
Overall IT Planning as outlined above, and if ODP has
shortcomings, how could we best extend ODP to cover what
This section identifies business requirements for a
framework capable of documenting an Overall IT Plan as
outlined in the previous section. The framework should be
capable of defining:
Templates of organization unit classes for a particular
Organization unit instances, eg per region, of that
Possibly mappings to other entities of the Enterprise
System classes within the business
System instances/Applications per System class
Identification of Interworking between System classes
Identification of Interworking between System instances
Mappings between System instances and Organization
Possibly mappings to other entities of the Information
Processing system classes within or for the business
Processing system instances per Processing system class
Identification of Interfaces between Processing system
Maybe identification of Interfaces between Processing
Mappings between Processing system instances and
Mappings between Processing system instances and
Possibly mappings to other entities of the Computational
In the Discussion section, we will address use of the
ITU-T Recommendation Z.601 Appendix I  gives
some background on Systems Planning:
“A system instance is a set of data instances that are
enforced as one consistent whole.” A system instance is
called an Application.
“A system class is a set of data classes that prescribe
constraints and derivations on data instances.” A system
instance belongs to one system class only, ie. strong
ITU-T Recommendation X.906 section 6.2.2 Viewpoint
specifications  contains the following definitions:
the enterprise viewpoint, which is concerned with the
purpose, scope and policies governing the activities of
the specified system within the organization of which it
is a part;
the information viewpoint, which is concerned with the
kinds of information handled by the system and
constraints on the use and interpretation of that
the computational viewpoint, which is concerned with
the functional decomposition of the system into a set of
objects that interact at interfaces – enabling system
the engineering viewpoint, which is concerned with the
infrastructure required to support system distribution;
the technology viewpoint, which is concerned with the
choice of technology to support system distribution.
The following discussion is indicative only, and other
conclusions are possible.
Systems Planning, Interworking
Application Planning may all fall into the Computational
Viewpoint. However, the Computational Viewpoint seems to
have a wider scope, and seems not to give any definition or
guidelines to support the mentioned planning activities.
Note that even if one ODP system, Enterprise object or
Package (within the Enterprise Viewpoint) might be defined
per System class or System instance, we do not think that
this is the intended use. We observe that in the example
Library System in X.901 Annex A , both an Enterprise
Role and an Enterprise Object are named Library system, but
we think that this notion of system is different from the
Z.601 notion of System.
X.906 section 7.4.2 states :
“for each enterprise object in the enterprise
specification, a list of those information objects (if any)
that model information or information processing
concerning the entity modelled by that enterprise
We do not think this is a means to structure data into
System classes. Also, the Information Viewpoint is
abstracting across all System classes and instances, and does
not define how data are designed and contained in each. Ref.
X.906 section 6.2.6 : “The individual components of a
distributed system should share a common understanding of
the information they communicate when they interact, or the
system will not behave as expected”. This indicates that the
definitions are independent of and goes across System
The schema and package notions in the Information
Viewpoint might be a means to structure data into System
information/concepts, and not data.
Section 9.1.1 states:
“A computational object is an object as seen in the
decomposition and interacts with other computational
objects. Since it is an object, it has state and behaviour,
and interactions are achieved through interfaces.”
A System class may be a special case of a computational
object. This allows the System class to have states, interfaces
and interactions. However, we see no mentioning of data
bases, data structures, data transformations, user interfaces
etc. We find nothing that supports design of large database
applications. However, in the Annex A in Figure A.36 we
find an example specification of data types.
Section 9.4.4 states:
“Where transparencies that replicate objects are
involved, each computational interface of the objects
being replicated corresponds to a set of engineering
interfaces, one for each of the basic engineering objects
resulting from the replication. These engineering
interfaces each correspond only to the original
The expression “replication” may indicate that
Application planning is deferred to the Engineering
Viewpoint. We note the following on Engineering
Viewpoint specifications in section 10.4.3:
“Each engineering object corresponds to a set of one or
more technology objects. The correspondence and
implementable standards for each technology object are
dependent on the choice of technology. The engineering
correspondences to implementation. Engineering
objects and their interfaces correspond to technology
objects and their interfaces, and thus will become basic
information source for testing in the technology
We provide no further discussion on Engineering and
Technology Viewpoint specifications here.
ITU-T Recommendations M.3020  recommends a
three phase method for developing information systems:
Requirements phase – Requirements.
Analysis phase – Implementation independent
Design phase – Technology specific specification.
The methodology uses UML class diagrams for the
second stage, corresponding to ODP Information Viewpoint.
The Requirement phase may correspond to the Enterprise
Viewpoint. If so, the Design phase would comprise
Computational, Engineering and Technology Viewpoints.
Systems, Interworking and Application Planning may all
correspond to the Design phase. We may call the
combination of the three planning domains for Overall IT
however, the viewpoint addresses
It models functional
does not have any
Planning, as IT Planning may cover all detailed
specifications, that are not addressed in the Overall IT
From the previous discussion, we have no definite
conclusion on where the various planning domains fit into
the RM-ODP viewpoints. Therefore, the proposals in the
next section are indicative, as well, and are not final. As an
example, it is not clear that System classes and instances
should be included in an extension of the Information
Viewpoint, as this viewpoint is intended to be conceptual
and not to cover concrete data syntaxes.
IV. EXTENSIONS OF ODP
We propose to consider organizing the ODP Reference
Model into a table, where each viewpoint constitutes a row.
The current contents of the ODP Recommendations may be
put into a first column. Proposed extensions are put into the
following additional columns:
IT Planning classes
IT Planning instances
as indicated in the Requirement section. This is
illustrated in Table 1.
Table 1 – Proposed Extended ODP-RM
If the Overall IT Planning instances are homomorphic
(many-to-one mappings) to the Overall IT Planning classes,
the Overall IT Planning might have one column for IT
Planning classes only, and no column for IT Planning
instances. However, the planners will have to design the
contents of both classes and instances.
Note that Predicate calculus does not distinguish classes
and instances. However, the statements may be interpreted
against a universe of sets, where sets like John and Bill
correspond to instances, and sets like Persons and Customers
correspond to classes. Note also that the notions of variables
and constants are different from classes and instances.
When using UML for ODP specifications, the specifiers
typically define classes only, as creation of instances is left
to the users of the specified information systems. However,
the IT planners will have to create both classes and instances.
Therefore, we propose use of the two separate columns.
In the subsequent text, we define and discuss the contents
of each cell in Table 1.
Organization classes define templates for Organization
instances within a business. Organization classes may
presentation of organizations into matrixes, pizzas or
other are supported.
Organization instances make up a hierarchy within a
business. Organization instances are homomorphic to
their Organization classes.
System classes define a vertical partitioning of data
within a business. System class labels are globally
unique within the business.
A System class may be used by one or more
Organization classes. This reference forms the basis for
defining ownership, access control and detailed design
of the System class.
A System class is defined by its contained data structure.
A set of references to the contents of the Information
Viewpoint may form a basis for design of the data
structure. Also, the System class may be defined through
an informal listing of the data therein.
The data in a System class may be seen as a set of n-
tuple classes, ie. tables. The columns of the tables may
share common domains, ie value sets. These value sets
represent the object classes that the System classes may
communicate about. Hence, object classes may appear
as n-ary relations between System classes. These object
classes indicate what the system classes need to
Alternatively, we could represent the communication
between System classes as
One-way directed communication
We recommend the use of the last alternative. However,
when doing Systems and Interworking Planning, we cannot
go into details of the interactions, eg. through question and
answer dialogues. So the One-way directed communication
should show the main information flow only. This
communication we call an interface. The contents of the
Interface may be specified through references to the contents
of the Information viewpoint of the Detailed ODP
Framework. However, this would not be sufficient to define
the grammar of the message types to be used. Also, the
communicated data may during Interworking Planning be
specified informally in natural language.
If there are overlaps between data n-tuples (N>=2) of
several System classes, a Mastering regime needs to be
defined. For each n-tuple/table we need to define Source
System classes, one Master System class and Client System
classes. Note that the Source may be spread on more than
one System class. The n-tuples of the Mastering regime may
be different from the n-tuples of data within each System
class. And the Mastering involves more than one System
class, per definition. Therefore, we recommend that the
Mastering regime of a business be documented separately in
a table having three columns: Source System classes, Master
System class, and Client System classes.