Systems Planning using ODP

Arve Meisingset Corporate Development. Telenor ASA.

Snarøyveien 30C 1360 Fornebu. Norway arve.meisingset@telenor.com

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.

I. 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 processes.

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 is needed?

II. REQUIREMENTS 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

business • Organization unit instances, eg per region, of that

particular business • Possibly mappings to other entities of the Enterprise

Viewpoint • 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

units • Possibly mappings to other entities of the Information

Viewpoint • Processing system classes within or for the business • Processing system instances per Processing system class • Identification of Interfaces between Processing system

classes • Maybe identification of Interfaces between Processing

system instances • Mappings between Processing system instances and

Organization units • Mappings between Processing system instances and

System instances • Possibly mappings to other entities of the Computational

Viewpoint In the Discussion section, we will address use of the

remaining viewpoints.

III. DISCUSSION ITU-T Recommendation Z.601 Appendix I [4] 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.

2010 14th IEEE International Enterprise Distributed Object Computing Conference Workshops

978-0-7695-4164-8/10 $26.00 © 2010 IEEE

DOI 10.1109/EDOCW.2010.38

357

2010 14th IEEE International Enterprise Distributed Object Computing Conference Workshops

978-0-7695-4164-8/10 $26.00 © 2010 IEEE

DOI 10.1109/EDOCW.2010.38

357

• “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 typing.

ITU-T Recommendation X.906 section 6.2.2 Viewpoint

specifications [3] 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 information;

• the computational viewpoint, which is concerned with the functional decomposition of the system into a set of objects that interact at interfaces – enabling system distribution;

• 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 Planning and

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 [2], 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 [3]: • “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 object;”

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 [3]: “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 classes.

The schema and package notions in the Information Viewpoint might be a means to structure data into System

classes; however, the viewpoint addresses information/concepts, and not data.

Section 9.1.1 states: • “A computational object is an object as seen in the

computational viewpoint. It models functional 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 computational interface.”

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 viewpoint specification does not have any 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 viewpoint. “

We provide no further discussion on Engineering and

Technology Viewpoint specifications here. ITU-T Recommendations M.3020 [1] recommends a

three phase method for developing information systems: • Requirements phase – Requirements. • Analysis phase – Implementation independent

specification. • 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

358358

Planning, as IT Planning may cover all detailed specifications, that are not addressed in the Overall IT Planning.

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

Detailed ODP Framework

Overall IT Planning

Enterprise Viewpoint

Organization classes

Organization instances

Information Viewpoint

System classes System instances

Computational Viewpoint

Process System classes

Process System instances

Engineering Viewpoint

Technology Viewpoint

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

contain Organization classes recursively. This containment defines name bindings. No other 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 communicate about.

Alternatively, we could represent the communication

between System classes as • n-ary busses • two-way communication • 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.

359359

A System class may be instantiated into one or more System instances. The business may use one centralized System instance, or it may use decentralized System instances per region. The decentralized System instances may run on a centralized data centre or not. For each System instance there needs to be an informal specification of what data instances will be covered. As all System instances of a System class share the same data definitions, there should be no need to refer from each System instance to the contents of the Information Viewpoint.

For each System instance there needs to be a reference to the Organization instances being served by this System instance.

Also, all Interfaces between System instances needs to be defined. However, here the specifier may rely on the Interface specifications between System classes, and may not need to repeat or delete at Interface instance level. The Mastering regime between System classes needs to be extended to the System instance level. In principle, a larger Mastering table needs to be developed. Here the actual replication of data instances between System instances is not completed at System class level, and hence, needs to be accurately specified between System instances.

System classes and System instances address vertical and horizontal partitioning of data. Hence, we may use the expressions Data System classes and Data System instances. However, the software solution comprises more than storage and enforcement of data. Some software nodes may only communicate and translate data. These nodes we call Processing System classes or Processing system instances.

Processing System classes are software packages that communicate and translate data. There may be a Processing System class per (data) System class. But there may be additional Processing System classes for middlewares, Enterprise Service Busses, web services etc. The additional Processing System classes may not enforce consistency of data.

Processing System classes may be defined by references to the contents of the Computational Viewpoint of the Detailed ODP Framework. They may have references to corresponding (data) System classes. They may have references to Organization classes. And they may have informal texts on these usages.

Processing System instances are actually deployed instances of Processing System classes. They may have additional references to actual Organization units.

We have not carried out a detailed discussion on use of the Engineering and Technical Viewpoints. However, some of the deployment specifications may already be covered by the instantiations made according to Table 1. Maybe only the platforms/infrastructures remain to be specified. This topic needs to be further investigated.

V. CONCLUSIONS This paper offers a discussion on how to incorporate or

extend ODP to cover Overall IT Planning. We have indicated uncertainties on where the various planning domains fit in, and we have indicated how ODP may be extended. However, we offer no final conclusions on this.

Rather we offer the paper as a contribution for further discussions. The discussions may lead to revisions of existing definitions and addition of new definitions.

We believe that this kind of challenge, where we discuss use of ODP relative to a certain application domain, ie. Overall IT Planning, is what is needed to validate the usefulness of ODP, and to adapt ODP to practical usage.

We believe that an offer of a practical solution to this challenge is needed. We indicate that an additional Recommendation text be developed jointly between ISO and ITU on Overall IT Planning using ODP. This paper offers a first contribution on what contents may go into such a text.

REFERENCES 1. ITU-T Rec. M.3020. Management interface specification

methodology. (05/2009) 2. ITU-T Rec. X.901. Information technology – Open distributed

processing: Reference model - Overview. (08/97) 3. ITU-T Rec. X.906. Information technology – Open distributed

processing: Use of UML for ODP system specifications. (11/2007)

4. ITU-T Rec. Z.601. Data Architecture of one IT system. (02/2007).

360360