Using the ODP reference model for Enterprise Architecture
Using the ODP reference model for Enterprise Architecture
Department of Computer Science, University of Helsinki, Finland
Abstract become fundamental requirements for the collaborative
architectures, covering processes, information, and
The Open Distributed Processing Reference Model modularization of the application domain.
(ODP-RM) provides viewpoints and abstract The Open Distributed Processing Reference Model,
infrastructure guidelines that can be used for a basis ODP-RM [8,9], was initially developed for structuring
for enterprise architecture, especially for an inter- the application level concerns of communicating
enterprise architecture. The ODP-RM does not systems in general. As part of the present trend,
prescribe methodology for modeling itself, but provides business networks form an important focus area for
common vocabulary and focus for description. This which the reference model can be applied. This paper
paper performs a brief analysis of the ODP-RM (and discusses the above mentioned enterprise architecture
Pilarcos extensions to it) in terms of defining challenges and required elements in the enterprise
enterprise architecture. Special attention is given to architecture and points out what kind of solutions and
potential to provide support for consistency enforcing architecture patterns are already present in the ODP-
between viewpoints, analysis of model properties, and RM. As refinements of the ODP-RM generic
interaction between business and technology needs. specifications, results from the Pilarcos project work are
used. The Pilarcos project has developed B2B
1. Introduction middleware  and is enhancing the research
activities towards service oriented software engineering
“An enterprise architecture describes how the and enterprise architecture needs in a way consistent
elements of an organization fit together – the business with the ODP reference model.
processes, organizations responsible for them, Section 2 discusses formation of enterprise
Information Technology (IT) capabilities and architecture in general, while Section 3 states some
infrastructure – today and in the future“ . For this guidelines for a specific enterprise architecture for
purpose, a large number enterprise architecture networked business arena. This inter-enterprise
methods, architecture frameworks and modelling tools architecture is made visible through papers on the
already exists (e.g., Zachman , TOGAF , ARIS Pilarcos work , which is shortly commented on in
, Archimate , business architecture ) as well as Section 4 while the main contents of Section 4 is on
standard frameworks . By their origin, the main goal noting the solutions suitable for inter-enterprise
has been to enforce a shared vision of the enterprise architecture directly provided by the ODP-RM. Section
architecture to all involved parties (users, designers, 4 further elaborates on the potential for cross-viewpoint
implementors, service providers) in the enterprise, and consistency maintenance both at architecting time and
to support coherent management even during changes operational time through monitoring and operational
in the architecture. knowledge collection and feedback processes.
Modern challenges for enterprise architecture arise
from the interoperability and federation needs: inter- 2. Defining enterprise architecture
enterprise computing and merging of businesses cause
needs for loose integration of business services across An enterprise architecture defines how business
enterprise boundaries. Furthermore, there is increasing strategy is realized using the processes and resources
demand for aligning the computing infrastructure to the available by the enterprise. The process by which the
requirements of the business management activities. architecture is defined and that evaluates its change
Interoperability and federated management facilities needs and describes its development steps rely on a)
common terminology, b) the methodology for
developing the system and its components, c) form a specific category of virtual enterprises (or
explanation on how the developed components fit extended enterprises, business networks, etc.). This
together, and d) the set of tools that support the section summarizes a few enterprise architecture
methodology. guidelines for enterprises wishing to emphasis potential
The enterprise architecture itself is commonly for agility in business networks.
divided to topic domains and layers of different levels of In this future vision of inter-enterprise architecture,
detail. The domains should become connected together the essential concepts are business service
by methodological means that supports consistency and interoperability and contract-governed collaboration
refinement steps. The variety and maturity of tools for between business services.
model creation and verification preserves attention too. We understand interoperability, or the capability to
The subarchitectures commonly in use include collaborate, as the effective capability to mutually
[e.g.,3] Business Architecture, Data Architecture, communicate information in order to exchange
Applications Architecture, and Technology proposals, requests, results, and commitments (i.e., to
Architecture. exchange speech acts common in business). The term
The business architecture is needed to start the covers technical, semantic and pragmatic
definition process, to define the business strategy, the interoperability. Technical interoperability is concerned
business processes of interest, and to define the with connectivity between the computational services,
stakeholders and their viewpoints of interest to be allowing messages to be transported from one
followed through in the other architecture models. The application to another. Semantic interoperability means
resulting documentation should point out the reference that the message content becomes understood in the
framework to be used, and identify the architecture same way by the senders and the receivers. This
principles to be used in the architecture process. concerns both information representation and
Suitable reference architectures for business messaging sequences. (More and more the ability to
architecture could include RosettaNet specifications etc. transform information in messages between the source
The data architecture and application architecture and the targets is viewed as a service supporting
have the goals of defining the major types and sources interoperability (e.g., enterprise application integration
of information in a consistent, complete and stable (EAI) and enterprise service bus (ESB) ).
manner so it can be accessed and understood by all Pragmatic interoperability captures the willingness of
stakeholders. On application side, the objective is to partners to perform the actions needed for the
determine the selection of information processing collaboration. This willingness to participate refers both
applications relevant for the enterprise. to the capability of performing a requested action, and
The technology architecture grounds the work on an to policies dictating whether it is preferable for the
existing application platform, shared terminology and enterprise. (In most integration products, workflows are
production and deployment processes. Thus the selected used to manage business processes. Here, the joint
technology architecture restricts the correspondences understanding of external business processes and their
between the business and application architectures and enactment is essential, not the actual enactment
the technology support available or required. technology.)
The impact of the existence, maturity and timeliness We expect the technology architecture to provide
of the enterprise architecture is significant: it allows common facilities for interoperability and collaboration
informed decision-making while negotiating lifecycle management. The method of managing
commitments on inter-enterprise collaboration, on collaborations and contracts is based on generic, B2B
provision of products or services to clients, and middleware protocols and agents private to each
controlling changes in the enterprise architecture. involved enterprise. In addition to the common
When interoperability and collaboration management protocols, each enterprise needs expert systems to
are specifically addressed, the enterprise architecture support private decision-making on participation in
also has a considerable impact on the enterprise’s collaborations, management of private policies, etc.
agility. The methodology for building the business networks
is semi-automated: based on a selected business
3. Architecting networked businesses network model and service offers published by service
providing enterprises the B2B middleware is able to
Loosely-coupled, dynamic collaborations of business suggest contracts that are ensured to represent
services that are provided by autonomous enterprises interoperable collaborations. The expected way of
business services to fit into the collaboration and to enterprise is prepared to make available for its clients.
each other is defined in terms of interoperability and The business services can fulfill roles in multiple
collaboration contract requirements and breaches. business networks simultaneously, based on their ability
These aspects are to be continuously monitored during to fulfill the behavioural and nonfunctional
the collaboration lifecycle, at times triggering requirements of the role and the contract.
management actions. In terms of defining an enterprise architecture for
We call all kinds of the inter-enterprise networked business, we can state the following
collaborations business networks. This is because the guidelines. First, business scenarios should be formed
business management activities appearing in different in a rather generic way and be refinable by policy
types of business scenarios (e.g., supply chains, virtual statements that can be negotiated for each collaboration
enterprises, and subcontractor networks) repeat largely separately. The business scenarios should be modelled
the same pattern. Looking at the common business in terms of business processes, compositions of business
scenarios from the supporting technology point of view, processes, and provide control and monitoring potential
we can separate external business processes that express through addition of non-functional properties. The
what interactions the players in the business network resulting models should be verified and published on
must take, and the service processing software at the trusted repositories available for all stakeholders.
location of each player. The nature of supply chain or Second, the open market of business services is
virtual enterprise becomes expressed and defined by the formed by federated service offer repositories, that are
business processes, while the supporting technical trusted in terms of providing non-repudiation of offers
environment can be identical for all types. From the and traceabilty of the offer providers, and in terms of
technical point, we can consider that the primary goal checking conformance to known service types and
of each independent organization in these scenarios is associated required properties within offers.
to provide added-value services by composing existing Third, business services are mapped to technical
services provided by different enterprises. However, service compositions under a single business
because of the different responsibility models important administration that has authority on deciding the
for the business management perspective we need to associated policies and contracts that constraint the
preserve the following separation: behaviour of the technical service. This authority must
orchestration, where the coordinator of the be authorised and responsible for the enterprise
composed service takes on the obligations of decision-making and traceable.
providing the service; and Fourth, the application platforms involved should be
collaboration, where a mutual contract is formed able to support a service-oriented architecture. This
and the members of the collaboration are equal means that there should be either native or added-on
and have their contracted obligations; the facilities to provide metainformation on the services
coordination of the collaboration is maintained and reflect the metalevel commitments to the system
by the supporting infrastructure. state (or to refuse changes), and strict encapsulation of
Therefore, each business network is viewed as the implementation of the services provided through the
collaboration between autonomously administered published interfaces.
business services. A business network is established Fifth, the technology environment should support
dynamically to serve a certain business scenario or not only concepts for publishing, binding and
opportunity that is made commonly known by performing services, but to manage the lifecycle of
publishing a business network model (BNM). The collaborations and to detect and maintain potential for
business network model captures all those external interoperability as needed.
business processes that are relevant for the business Sixth, the technology architecture is a changing
scenario. The business network model also gives element. Therefore, an especially important principle to
structure for the contract that is technically used for cover in the architecture process is to define solutions
governing the collaboration at runtime; the contract that cut potential domino-effects from technology
captures most of the social behaviour requirements in changes to directly supported business or application
the collaboration. A business service is realized by a chains forcing re-implementations; legacy support, or
business application implementation running under the rather strong encapsulation of services (not only objects
administration of a single authority. The potential of or components) is a necessity.
activities of the business application is restricted and Finally, the technology architecture should support
controlled by enterprise policies to the degree that the global description of relevant information between
services, but also relevant metainformation about the aspects to failure concepts; f) include security service;
services and collaborations. and g) offer selectable distribution transparency services
The difference to other approaches can be found in for communication.
the strong encapsulation of business services, deliberate These goals are acquired by the ODP reference
omission of distributed execution facilities for shared model through three already standardised aspects of the
business processes, and emphasis on the ability of the basic reference model (which that was completed in
architecture itself to carry out the changes in the 1996 [8,9]): First, a division of an ODP system
business architecture, information system architecture, specification into viewpoints, in order to simplify the
and technology architecture. For all these aspects, the description of complex systems . Second, definition
B2B middleware is expected to provide semantically of a set of general concepts for expressing the viewpoint
consistent repositories and associated protocols for specifications . Third, a model for an infrastructure
publishing, retrieving, comparing and negotiating. In supporting, through the provision of distribution
addition, the view of the architecture is global, instead transparencies, the general concepts that it offers for
of a single enterprise. specification purposes . Finally, specification of some
essential middleware services as component standards.
4. The ODP-RM solutions These services include the already completed trading
service , naming framework , type repository
In the early phases of the Pilarcos project series, function , and interface binding framework together
involvement on the ODP standardization was part of with the supporting protocols.
the work. Therefore, a lot of alignment of the basic
concepts can be easily found. In this section, a brief 4.2. Common concepts
introduction to the ODP-RM is given, pointing out
aspects on which we can base the future, inter- Part 2 of the reference model provides a common
enterprise architecture view. vocabulary to be used in any ODP system specifications.
Presently, the ODP reference model is often
4.1. Family of ODP standards undervalued solely due to its object-orientation.
However, the objects used are only a form of
The ODP reference model (RM-ODP) [8,9,13,14, abstraction, of strong encapsulation of behaviour and
15] is a joint standardisation effort of ISO and ITU. It information and more like the present service concepts.
was started with a basic reference model standardisation In the correction cycle of the ISO and ITU standards, it
officially already in 1989, and developed in interaction is suggested to point out the relationship of the present
with other distributed system models. Thus, ODP object-oriented vocabulary and more modern service
reference model has had impact on industry trends concepts; the relationship is fairly straightforward .
already during its development. One of the necessary steps for managing
The ODP standardisation aims for development of collaborations across administrative domains is to
standards that allow distributed information processing differentiate between ways by which objects (i.e.,
systems to be exploited in a heterogeneous environment services) appear in the system. The ODP model allows
and under multiple organisational domains . This goal objects to appear in the system in two ways, by
is an enhancement to the openness requirement above. instantiation or by introduction. Instantiation is the
In addition to the use of public and standardised often used model, where a template exists with
middleware services, the systems must be able to sufficient information for the creation of an object
support interoperation in spite the independent instance. Introduction allows manipulation of objects
evolution and independent technology decisions made without knowledge of their instantiation methods – only
by the sovereign member systems. the object type is interesting. The ODP model defines
The ODP standards support systems to be built so type as a predicate that classifies objects based on their
that they a) provide software portability and properties. A template is defined as a type detailed
interoperability; b) support integration of various enough for instantiation. The instantiation process is
systems with different architectures and resources naturally dependent on the platform facilities, and
without costly ad-hoc solutions; c) accommodate therefore, whether a type is also a template depends on
system evolution and run-time changes; d) federate the platform.
across autonomously administered or technically The object behaviour is specified as a set of
differing domains; e) incorporate quality of service interfaces. An interface represents objects role as a
provider or exploiter of a service. As an object can where a group of B2B middleware agents work together
support multiple interfaces, it can also participate in the to manage the collaboration lifecycle and
provision of multiple services. A typical object supports interoperability.
at least a mission specific interface and a management
interface. 4.3. Viewpoints supporting architecture
An interface (at which two or more objects meet for domains
communication) is not specified as an indivisible,
global abstraction. Instead, both a client requesting a The ODP reference model defines five viewpoints –
service and a server providing such a service, can have enterprise, information, computational, engineering and
slightly different technical views of the interface. The technology viewpoints . The viewpoint specifications
ODP communication model concepts declare how these of a system can be regarded as separate projections of a
views can be mapped together in the binding process full system description. A system must be specified
that creates a communication channel between the from each of the viewpoints. Each viewpoint
client and server interfaces. Object interfaces are bound specification is a consistent and complete specification
based on their type, the object template is not on its own, but it only considers those aspects of the
considered. Because of the separation of client and system that are valid on its point of view. So the
server interfaces, also the sub-typing and substitutability viewpoint specifications do not overlap totally, but they
concepts for ODP objects differ from other object may show different level of detail in the areas where
models. The type system of objects focus on the shared they need to discuss same or related features. The
features required from interfaces that need to be bound engineering viewpoint specifications are tightly related
together, instead of focusing on implementation with the ODP infrastructure model that is specified as
inheritance hierarchies. The essence of sub-typing rules part of the engineering viewpoint specification rules.
for ODP objects is contravariance: the offered The enterprise viewpoint description of a system
information must include at least the information specifies the activities and the responsibilities of the
expected by the receiver. In most object models, system. Activity means any information exchange
sub-typing is based on covariance: the replacing object sequence and it is a high-level abstraction of the
can both expect to receive and offer more information operations within the system. The system itself can have
that the replaced object expects and offers. any granularity that is interesting. The system can be as
The separation of interfaces allows not only late wide as a global information network including
binding across enterprise boundaries, but also for applications or as small as a memory cache. The
relaxed type-matching and automation of enterprise specification identifies the system, its
transformation configurations into the communication environment, and the required communication of the
channels . system and its environment. The specification answers
The ODP reference model introduces the structuring to the questions “What is the purpose of the system?”
concepts of community, domain, and federation. These and “What services the system is responsible to
concepts can be used for organising objects for provide?” and “Who needs the services?”.
producing and exploiting services. The structuring In respect of the enterprise architecture, each
concepts can be considered to be either static, design enterprise viewpoint specification provides provide a
time concepts, or dynamic, operation time concepts. business architecture model, although without any
A community is a configuration of objects with a connections to component services to realise the
common objective. For example, a business network is a architecture or to technology architecture to support it.
community where the common objective is explicitly However, the business network models that follow
stated in the governing contract, capturing joint rather closely the enterprise language structures and
business processes and policies as means to reach the requirements  provides definitions for expected
objective. business values, and other non-functional aspects. The
A <X> federation is community of <X> domains. A enterprise specification thus sets guidelines that will be
<X> domain is a set of objects, each of which is related reflected to the runtime environment, to the monitors
by a characterising relationship <X> to a controlling governing the collaboration and the business services;
object. For example, a technology domain is the set of the linkage between business architecture and
objects conforming to a technical standard, and a technology architecture is direct.
trading domain is the set of objects known to a trader The information viewpoint description of a system
object. An example of a federation is a business network identifies logical information entities, their logical
contents, their repositories and the objects that are engineering viewpoint specifications should show how
responsible of the information flow in the systems. the specified system utilise these services. The
Questions for information viewpoint specification are engineering specification therefore answers the question
“What information is needed to support the system's “By which services are the computational objects
services?”, “Where does the information come from and supported?” The ODP infrastructure model identifies a
go to?”, and “Is it necessary to store the information set of global, distributed basic services that should be
somewhere?”. The information viewpoint specifications available at each node in the global system. These
should not describe data structures, but only the include invocation of operations, transfer of continuous
semantics of the information. Also, the technique of data as streams, trading, type repository functions, etc.
storing information is irrelevant in this viewpoint (as These services facilitate selective transparency of
the logical infrastructure supports storage services). communication.
In respect of the enterprise architecture, each In respect to the enterprise architecture, the
information viewpoint specification provides a set of engineering viewpoint specifications should capture the
relevant information elements that can be published in functionality of the support environment as enhanced
common type repositories, making the information with the B2B middleware repositories, especially their
accessible to all involved stakeholders. However, contents, and the associated protocols between the
associating the information definitions to business agents representing the enterprises. These elements
network models, a more effective and non-overlapping contribute to the technology architecture, and in
information base can be formed . addition importantly to the business architecture,
The computational viewpoint specification captures information architecture and application (service)
the behaviour of the system. Behaviour is an abstraction architecture.
of how things are done, in contrast to the notion of what The technology viewpoint specification shows in a
things are characteristic in enterprise viewpoint concrete hardware and software configuration how the
activities. An activity identified in enterprise viewpoint system services and other required components are
may involve several objects to perform a sequence of realized. The specification answers the question “How
operations in computational viewpoint. The are the infrastructure services realized?”. This is a
computational viewpoint shows the system as a direct mapping to the technology architecture.
composition of logical objects. For each object its The ODP viewpoint languages or specifications
interfaces are described. If the interface involves address the required elements for enterprise architecture
operations, each operation gets logical parameter definition, as can be seen for example by reviewing the
descriptions (information structures, not data structures) TOGAF architecture development method. In the
– if the interface involves streams, each data flow comparison, it should be noted that the TOGAF
component of a stream gets logical protocol descriptions architectures is a partitioning of the set of models
instead. This is the viewpoint that usually explicitly required to do enterprise architecture, not a set of
shows potential for distribution. Neither the enterprise overlapping views. TOGAF also recognises the need for
viewpoint nor the information viewpoint specifications views, that is an assembly of basic architecture elements
need to express any distribution concerns. The for a purpose.
computational viewpoint answers to questions like Also, it should be noted that each viewpoint
“Which operations are available?”, and “Who (which specification adds to the set of further requirements on
logical entity) performs the operation?”. the structure of service realisations, service descriptions
In respect of the enterprise architecture, the and service management information. The method that
computational viewpoint specifications can be written can be built using the ODP-RM is thus incremental;
so that they provide structure for business services and when the viewpoint specifications are made available
thus elements to publish on the trading service to form through public repositories this means a globally
a global open service market. It is essential that there is evolvable collaboration knowledge base and automated
service types publicly defined in the type repository to breeding environment. In addition, different enterprises
provide for mapping between business network roles may have a different set of coexisting specifications in
and business services. use, making the environment flexible for different types
The engineering viewpoint specification identifies of enterprises or different maturity levels of
the infrastructure services needed for the system to collaboration. The management structure is described in
operate. The ODP-RM engineering viewpoint defines the following section.
the set of available infrastructure services, and all other
4.4 ODP-RM enhancements by B2B middleware B2B middleware services that are available through
private agents at each enterprise, the right kind of
The ODP reference model defines an abstract software investment cycles can be supported.
computing platform that comprises of a set of
coordination, management, and repository functions. 4.5. Consistency of viewpoint models
Each open system should independently support these
functions, and in some restricted cases, also allow other The system specification includes five complete
systems to make controlled queries on the supported specifications, that all can be analysed as separate. Each
interfaces. The functions are described using a set of viewpoint reveals a different aspect of the system, and
supporting concepts (nodes, capsules and clusters), that therefore the full functionality can only be seen by
give an internal engineering view of the middleware looking at all specifications together. As the viewpoint
software. However, these concepts are used only for specifications are all complete specifications on their
descriptive purposes, to ease discussion, not as own, the abstraction levels of objects in the
technology guidelines. specifications can differ. Still, the specifier must show
At the time of the ODP-RM creation, the abstraction how the specifications are mapped together.
level for distribution platforms required that kind of The ODP-RM aims for specifications that allow
structuring, and still does, as the platforms have not yet software portability and interoperability and defines
developed to level of maturity where there were a four classes of reference points – points where the
consistent set of concepts available for selecting conformance to the standard specification need and is
properties like security, privacy, or dependability for the allowed to be tested. Other behaviour than that visible
transparent configuration of the communication layer. at these reference points is not considered. The four
However, on top of this communication layer, more classes of reference points are programmatic,
conceptual functionality must be provided. The perceptual, interworking and interchange conformance
essential functions introduced in the ODP-RM include points. For service-oriented architecture these two are of
trading function and type repository: The trader interest: at a perceptual reference point there is some
provides a service offer repository , while the type interaction between the system and the physical world
repository  provides structuring rules and while at an interworking reference point sets
constraints for metainformation and service elements conformance requirements for communication between
managed by the platform. two or more systems in terms of the exchange of
In the Pilarcos environment we have extended this information.
abstract platform by management services, i.e. The conformance rules can be modeled across any
pervasive functions as follows. First, tools and viewpoint specifications. For example, conformance
repositories support developing and publishing of new rules can expect enterprise viewpoint policies to be
models for business networks,and defining new service adhered to at the technology level, or the information
types for business services in such a way that the service exchange patters published to be followed at all
types match the needs of the business network roles business processes and business services playing roles
. Second, service offer repositories enable in them.
enterprises to publish business services to the open In respect of enterprise architectures, the
service markets together with metainformation for conformance rules would be captured in methodology
automated matching to roles and for interoperability guidelines.
testing against peers in the business network . In terms of consistency of the models, we need to use
Third, means are required for declaring policies that the facilities provided by the viewpoint languages
govern the use and the availability of business services. themselves. Because the enterprise architecture clearly
Fourth, new protocols are needed for negotiating utilizes a reflective system design, the semantic
eContracts to govern a new business network ; the constraints of metainformation is a key issue. Here, the
establishment phase is partially performed by a third- ODP information viewpoint language gives a good basis
party population process, partially by a collective, by stating static schema, dynamic schema and invariant
refining or dropping-out negotiation protocol between schema, thus denoting the initial state of the system,
becoming peers. Finally, facilities are needed for allowed state changes and their effect on information
monitoring the behaviour within eCommunities and content, and semantic restrictions that always hold over
manage breaches within them as specified in the the information state.
eContract . We believe that by this kind of generic
By using the information viewpoint over the B2B . Information Technology – Open Systems Interconnection,
middleware repositories, we can define semantic Data Management and Open Distributed Processing. Reference
constraints between newly defined and published Model of Open Distributed Processing. Part 2: Foundations,
service types, business network models, and service
 Information Technology – Open Systems Interconnection,
offers. When the repositories each have a set of required Data Management and Open Distributed Processing. Reference
information contents defined according to the B2B Model of Open Distributed Processing. Part 3: Architecture,
management protocol needs, the essential type safety of 1996. IS10746-3.
the overall system can be maintained . This  L. Kutvonen, J. Metso, and S. Ruohomaa, “From trading
promises for more effective and global tools than is to eCommunity management: Responding to social and
traditionally expected by enterprise architecture contractual challenges” ISF 9(2-3):181-194.
methods for single enterprises.  D. A. Chappell, Enterprise Service Bus. O’Reilly. 2004.
 Linington, P. RM-ODP: The architecture. In The 3rd
International Conference on Open Distributed Processing –
5. Conclusion Experiences with distributed environments, 1995.
 Raymond, K. Reference model of open distributed
We presented an enterprise architecture for processing (RM-ODP): Introduction. In The 3rd International
networked business. Each involved enterprise need to Conference on Open Distributed Processing – Experiences with
have their private architectures, but in addition be able distributed environments , 1995.
to participate this larger architecture as a member in the  Blair, G., and Stefani, J.-B. Open Distributed Processing
collaboration management activities. and Multimedia. Addison-Wesley Publishing Company, 1997.
The ODP-RM provides sufficient concepts to build  Information Technology – Open Systems Interconnection,
Data Management and Open Distributed Processing – ODP
an evolvable enterprise architecture of this type.
Naming framework. IS14771.
Although some of its vocabulary needs bringing up to  Information Technology – Open Systems Interconnection,
date by adoption of service-oriented concepts and Data Management and Open Distributed Processing. Reference
enhancing discussion on non-functional properties, the Model of Open Distributed Processing. ODP Type repository
framework is still valid and in line with current widely function. IS14746.
used description languages.  Lea Kutvonen and Janne Metso. Services, contracts,
In comparison to traditional enterprise architecture policies and eCommunities - Relationship to ODP framework.
methods, the evolution steps of the architecture have WODPEC 2005, pages 62-69, 2005.
been taken as a part of the computing system  Lea Kutvonen. Relaxed Service-type matching and
Transformation management. In Workshop on Enterprise
responsibilities and loosely-coupled interoperation that
Modelling and Ontologies for Interoperability, EMOI-
can be modified and reconfigured at operational time as INTEROP 2005, June 2005.
a main method of collaboration.  Information Technology – Open Systems Interconnection,
Data Management and Open Distributed Processing – RM-
References ODP enterprise language. 15414
 T. Ruokolainen and L. Kutvonen. Service typing in
 Mitre, “Guide to the Enterprise Architecture Body of Collaborative Systems. In Interoperability for Enterprise
Knowledge”. http://www.mitre.org/tech/eabok/, 2004. Software and Applications Conference (I-ESA2006).
 J. A. Zachman, “A framework for information system  L. Kutvonen, T. Ruokolainen, and J. Metso.
architecture,” IBM Systems Journal, 26:3, pp. 276–292, 1987. Interoperability middleware for federated business services in
 The Open Group, “Togaf 8.1.1 online,” Tech. Rep., web-Pilarcos. IJEIS 3:1, 1-21.
http://www.opengroup.org/architecture/togaf8-doc/arch/.  L. Kutvonen, J. Metso, and T. Ruokolainen. Inter-
 A.-W. Scheer and M. Nüttgens, “Aris architecture and enterprise collaboration management in dynamic business
reference models for business process management,” Tech. networks. In On the Move to Meaningful Internet Systems
Rep., 1996. 2005: CoopIS, DOA, and ODBASE: OTM Confederated
 M. Lankhorst and H. van Drunen, “Enterprise architecture International Conferences, CoopIS, DOA, and ODBASE, Agia
development and modelling -- Combining TOGAF and  J. Metso and L. Kutvonen. Managing Virtual
ArchiMate” Via Nova Architectura. March 2007. Organizations with Contracts. In Workshop on Contract
 G. Versteeg and H. Bouwman. Business architecture: a new Architectures and Languages (CoALa2005), Enschede, The
paradigm to relate e-business strategy to ICT. ECIS 2004. Netherlands, Sept. 2005.
 K. Kosanke, “Standardization in enterprise inter- and  Lea Kutvonen. What applying of the ODP viewpoints
intraorganizational integration,” International Journal on IT teaches us about tool-chains. In 10th IEEE International
Standards and Standardization Res., 3 (2), pp. 42–50, 2005. Enterprise Distributed Object Computing Conference
Workshops (EDOCW'06), 2006. IEEE Computer Society.