the future of distributed services

on this  page veryard projects typical services veryard projects white papers we recommend relevant books other  material ODP concepts & notions frequently asked questions presentations other  links veryard projects home page contact us cbd = component-based development odp = open distributed processing cbse = component-based software engineering cbb = component-based business

four predictions for 2001 Convergence of computing and telecoms. This has of course been predicted many times before.  Indeed, the label Information Technology was once intended to include telecoms, but now seems to be synonymous with computing. Component-Based Development Extending differentiated services and policy management. Most discussion to date has been focused on a narrow technical issues such as network traffic and the associated technical standards (IETF). In future, this will be extended to cover a broad range of customer-facing and business issues. Extending 'plug-and-play' into the business arena.  Constructing solutions from ready-made building blocks (plug-and-play) seems very attractive, not just for telecoms networks, but for whole business operations.  Component-Based Business Convergence of engineering and economics.  Proper system of metrics - linking engineering characteristics with ecological success and commercial value.  Option pricing and the hedonic pricing model may be applied to network services.

Opportunities of distributed systems

What is distribution

Management distribution. Power, authority and responsibility is not located in a single person or company, but is spread across a network of many managers in many organizations.

Information distribution. Information is communicated between points in space-time. Delays in transmission and availability are caused by various obstructions, including: people, procedures, technology and security controls.

System distribution. Technical systems are composed of devices spread across multiple locations.

ODP Vision

Open Distributed Processing (ODP) is predicted to become an important field of Information Technology during the next few years. ODP is widely expected to be a growth area for IT products and services, particularly when the current standardization efforts come to fruition. This raises important planning and policy issues for IT management.

ODP represents a combination of two concepts - openness and distributed processing - seen by many as a significant aid to gaining the organizational flexibility that is sorely needed by today's business.

The vision of ODP is for an information technology which can support cooperation between geographically and organizationally distributed work groups, and which can adjust robustly to both internal pressures (business reengineering) and external pressures (environmental volatility, technological change).

For users, ODP can provide valuable assistance in bridging the gap between today's and tomorrow's increasingly complex and intractable business requirements and the capabilities of conventional IT support for business.

For vendors, ODP offers an opportunity to provide the solutions to business problems that many of them have been striving to respond to for years but have not been successful in delivering

However, for ODP to have true business utility, and thus create business advantage, the development and implementation of ODP systems must be supported by an effective, flexible, simple and comprehensible process, automatable to the greatest extent possible, and with requirements being captured through modelling tools that provide readily usable notations for their clear representation. The formulation of business cases for ODP investments also needs to be supported, and in similar manner.

Business Opportunities

There have always been swings in management fashion between centralization and decentralization. But the latest writings by management gurus on radical corporate decentralization have a new flavour. We can identify six themes in particular:

ODP supports a business drive for greater flexibility.

Current advances in distributed systems and telecommunications technology mean that it is increasingly possible to support cooperation and collaboration between organizations by creating systems that span enterprise boundaries. Open distributed processing (ODP) should provide a mechanism that will facilitate the management of consortia and complex value-chains.

ODP is also supposed to provide a mechanism for delivering a broad range of information services to the user, from inside and outside the enterprise to which the user belongs.

Technical Opportunities

ODP brings additional technological opportunities 

Object orientation Trading / broking  Various forms of transparency	Distributed databases Geographical  Multiple ownership	Client/server 2-tier  3-tier 4-tier
Heterogeneous systems	Interoperability Within organization  Between organizations	Federated systems

On the technical side, miniaturization of computing devices connected by telecommunications services has made departmental computing with small-grain increments of computing power possible. This has made the physical dispersal of central monolithic computing feasible together with consequent changes in the place of computing and information systems within the business environment. Familiarity with stand-alone computers on a personal basis has fuelled the acceptance of dispersal though in the first instance with a loss of cohesion when connectivity was weak. The basic effect of the physical distribution of components of a system is that a number of technical assumptions normally made about single computer systems and program support environments no longer hold and have to be reversed.

In effect, from the point of view of distributed systems, single monolithic centralized computing systems are a special case. Given sufficient knowledge, local optima may be engineered and assumptions can be relaxed but not as part of the program descriptions. Foremost is the assumption that the environment can no longer be considered to be homogeneous. The assumption that processes are remote entails an increase in the number of failure modes. It is no longer possible to consider a unified name space, and federated name spaces need to be constructed which mirror the administrative boundaries of remote systems. These considerations affect the way distributed systems are built, especially as they encourage notions of cooperation and the feasibility of constructing systems out of the requisite pieces of functionality rather than the development of massive systems with myriad options to cater for universal requirements.

---

Opportunities from open systems

We are dealing not only with issues of distribution but also of openness. Some people find the notion of openness more difficult to deal with.

Notions of openness can be divided into those that focus on technological openness, those that focus on organizational/management openness, and those that focus on market openness.

Technological openness

The idea of technologically open systems is to allow the use of components from various suppliers in the design and development of computer systems, using common standards to help achieve significant economic benefits.

Technological openness can be characterized in the following ways:

Portability The capability of implementing programs without change on different computer systems.	Interconnection The ability to move information between computing systems using communications.
Interoperability The ability of joint working between interconnected computing systems.	Distributability Extends the interoperability idea to allow processes and information to be provided and migrated automatically to the most convenient point of an interconnected set of computing systems.

Organizational / management openness

Organizational/management openness can be characterized in the following ways:

Evolution The ability of an information system to be maintained to respond to changing requirements.  Software engineers such as Manny Lehman have encouraged us to consider the information system, across its operational life-cycle, as an evolving object.

Unboundedness The absence of barriers to the provision of information and services for the end-user.  The ability of unexpected information, from unexpected sources, perhaps even in unexpected formats, to somehow enter the system. This relates to the notion of the open-ended incremental and continually evolving system discussed by Hewitt and de Jong.

Business information systems have always been open, to some extent. Thus instead of a simplistic binary alternative - fully closed / fully open - it is more useful to consider a spectrum of degrees of openness, with full conformance to open system standards being positioned at (or at least towards) the fully open end of the spectrum.

Market openness

Market openness is often referred to as the 'level playing field'. It can be characterized in the following ways:

Low entry barriers The ability of new competitors to 'freely' enter a market.

Low exit barriers The ability of competitors to 'freely' leave a market.

Barriers to entry and exit are partly technological and partly socio-political. Of course, there are few if any markets where it would be appropriate or possible to altogether eliminate barriers to entry or exit. This is partly to do with the fact that operating in a market involves the acquisition of obligations.

In some markets (for example, banking), one of the functions of the regulator is to prevent players leaving the market without fulfilling existing obligations. This in turn may cause the regulator to restrict entry, only allowing those players whose untimely exit is improbable (or at least properly controllable).

In other markets (for example, IT), this regulatory function is performed by the companies themselves, in order to retain market respect. This is why, for example, IBM was for many years unable to withdraw commitment to the 360 architecture, or to the IMS database architecture. Such considerations in turn lead to entry inhibitions: a potentially high cost of exit may discourage entry into a high-risk market.

---

Outdated assumptions

Beyond traditional systems and development

Until recently, most information technology systems developers have worked within a certain 'paradigm' - a certain set of agreed common assumptions about the nature of the systems they have been developing, and about the nature of the development work itself.
• Central problem ownership, central design authority, central funding authority. This assumption leads to a reduced involvement in the development of solutions by those using the system.
• That complete understanding of a given problem/situation was possible and desirable
• That a permanent/final solution to a given problem was possible
• Stable or slow-moving market environments, technical architectures and policy frameworks
Perhaps these assumptions were never really true. But in most situations they could at least be regarded as reasonable approximations to the truth.

The assumptions about permanence and stability were certainly questioned especially in relation to problems of maintenance. The problems were, however, tackled more in terms of providing efficient tool chains based on the same paradigms rather than basing aids on a fundamental reappraisal of the purpose and policy of systems and the methods of development. Much the same comment can be made about the modifications suggested to the classic life-cycle development model.

Open distributed processing changes the software process

• Patterns of (re)usage of a software artefact are not predictable.
• Technical characteristics of software artefacts are hidden from the user, in the name of 'transparency'.
• Individual developers may have no monopoly over supply.
• Individual brokers and traders may have no exclusive control over the distribution of any given artefact.
• Individual users may have no exclusive control over usage.
These changes affect at least three important aspects of software quality assurance: design reviews, testing and configuration control.

The developer of a software artefact typically has incomplete knowledge of how it will be used, when, where, by whom, in what contexts, for what (business) purposes. Nobody has the complete picture: not the software tester, nor any individual end-user, nor any intermediary (planner, publisher, broker/trader, librarian, …).

Beyond two-valued logic

  

In a closed non-distributed system, all enquiries have a definite answer.	For example, either the customer record is found, or it is not found.
The behaviour of a component of such a system can therefore be specified using simple two-valued logic.	If condition is TRUE then action or outcome is X; if condition is FALSE then action or outcome is Y.
In a distributed system, an enquiry may not have a definite answer.	One simple reason for this may be that a remote server containing customer data is currently unavailable.
To specify the behaviour of a component of a distributed system, we may need to use three-valued logic.	If condition is TRUE then action or outcome is X; if condition is FALSE then action or outcome is Y; and if condition is UNKNOWN then action or outcome is Z. (A logically equivalent alternative to using three-valued logic explicitly is to define lots of exception conditions. But this tends to make the specifications more complicated.)
In an open distributed system, there are many other reasons why the results of an enquiry may be indeterminate.	For example, an Internet search using the same search engine with the same parameters may not yield the same results twice.

Beyond traditional testing

Besides making the specification of components more complex, the indeterminacy referred to above makes it much harder to test and debug systems and components, as it often proves impossible to replicate anomalous results.

Furthermore, ODP challenges the traditional double negative of testing: if a component fails to fail a test, then it must satisfy requirements.

Although often there is no fixed specification of what the software artefact is required to do, some limited testing is possible, for example:

• whether the software artefact conforms to its own description
• whether the software artefact conforms to standard constraints (such as absence of side-effects)
Where testing is more difficult, and its results less conclusive, is in the compatibility of multiple objects and artefacts. This is complicated by the fact that we don't always know what compatibility is required. This is related to the problem of feature interaction.

---

Architecture and Standards

A new paradigm is emerging as the focus of current standardization efforts for open distributed processing between heterogeneous systems (known as ODP) and of technological R&D. The motivation for developing of a standard for Open Distributed Processing was the opportunity provided by a range of computing and telecommunication options which allowed diverse systems to work in a co-operative fashion. A further factor was the availability of incremental portions of computing power at economic prices coupled with the liberalization of telecommunications services. This has been accompanied by the emergence of a paradigm shift in the approach to systems building by the utilization of the object-oriented approach.

The Open Distributed Processing standard is a reference model standard. That is it provides a framework in which component standards are placed. The framework provides concepts and languages for describing the functional components of an open distributed processing infrastructure. The same concepts and the terms of the languages are the basis of this report. Successful development of distributed applications requires more than an enabling infrastructure of computing and telecommunications. The opportunities and organizational changes consequent on the adoption of an open distributed processing approach need adjustment and rethinking of methods, design processes and tools. We use the concepts and languages from the Open Distributed Processing standard to develop a methodology of enterprise modelling and a business case methodology. to validate and quantify the options generated by the model. In a domain of distributed applications, models derived from other disciplines, but described using the concepts of open distributed processing, provide a suitable starting point for analysis.

The Open Distributed Processing standard was based on early work carried out by the Alvey project on Advanced Network Systems Architecture (ANSA) which used a notion of projections, to denote various areas of concern when describing a distributed system. In this case we are describing a system not the model of a system. The term 'projections' derives from the idea that a system is projected on to these various concerns, each having particular characteristics.

In the table, the five projections chosen are labelled with names that derive from early ANSA work and are annotated with a single word indicating the nature of the areas of concern covered by each projection.

In the Open Distributed Processing standard the projections are called 'viewpoints' and there is a strong presumption that these labels signify stages in a development cycle. It is clear that both ways of considering the viewpoints/projections are valid. Some care needs to be taken of the context or purpose in using the basic concepts.

Other application domains will make similar structured use of basic open distributed processing concepts though the actual set of concepts, models and mechanisms used are related to the domain. The domain concepts are constructed from the basic concepts. The basic notion of a distributed system is that it is a set of autonomous agents. A particular property of such agents is that they will seek information about the services carried out by other agents. A further property is that agents will seek to form co-operative alliances of various sorts with other agents. This co-operation implies that questions of legitimacy, liability, payment need to be considered together with the ability to negotiate and make binding contracts. Information about all of these issues needs to be available as part of the agent's capabilities. Information needs to be provided about the functioning of each service so that modifications can be negotiated.

Defined process

The SCIPIO method is designed to provide a simple yet powerful process for making planning, design, and implementation judgements around open distributed component-based business systems.

We provide consultancy and training based on the SCIPIO method. Please contact us to discuss.

Typical starting point

• Problems with existing technology.
• New technology on offer.
• Changes in policy requiring organizational change.
• Changes in organizational relationships.
• Changes in external environment

Typical endpoint

• The formulation of a solution or adaptation(s).
• The agreement by the client of a solution or adaptation(s).
• The formulation/agreement of a plan for developing and implementing the solution or adaptation(s).
• The implementation of the solution or adaptation(s).
• The demonstrated achievement of the hoped-for benefits.

Kevin Kelly. New Rules for the New Economy. 10 ways the network economy is changing everything.  US: Viking Penguin. UK: Fourth Estate. 1998

A systematic analysis of the strategies for successful business in the new world. This is the open, distributed, connected, chaotic world he described in his previous book. Out of Control: The New Biology of Machines, Social Systems, and the Economic World.

Acknowledgements

top home page contact us
in asssociation with	This page last updated on December 4th, 2000 Copyright © 1997-2000 Veryard Projects Ltd http://www.veryard.com/CBDmain/odp.htm