Telecommunications Service Providers (SPs) face Information Technology (IT) problems similar to those experienced by other industry segments; in particular, how to drive down the total costs of IT systems while improving their effectiveness. One approach a company might use in reducing costs is to undertake internal standardisation of IT systems. This reduces training, development, administration and operations expenses. Further, it promises applications that can be moved among different instances of the standard platform and can communicate using standard protocols.
In determining which components of IT systems to standardise, a Service Provider may find a natural split between the general-purpose computing platform and the applications that run on top of the platform. The applications are often the strategic differentiators that a Service Provider needs in an increasingly competitive marketplace; the expertise needed to write such applications is employed by the Service Provider itself.
Today, virtually all Service Providers standardise internally all or parts of their general-purpose computing platform which is used company-wide for IT.
From a vendor's point of view, however, Service Providers' platform requirements do not appear to be standard. What one Service Provider views as standard may be very different from another Service Provider's view, rendering the market fragmented for vendors, even within a particular market segment. The costs of producing multiple platform varieties to meet customers' demands must be passed on to those customers. The finite resources available to vendors - both platform vendors and Independent Software Vendors (ISVs) - means that some of the platform needs of a fragmented market will not be met.
Clearly, a fragmented market is inefficient, and the question is whether this fragmentation exists because of some real business need or because it represents arbitrary differences. Early discussions among Service Providers quickly revealed that technical efficiencies would result from a coherent view of a general-purpose computing platform. The Service Provider market segment could develop such a view, which could be used by each Service Provider within its discretion in making its own purchasing decisions. This gave birth to the SPIRIT effort.
A team of international telecommunications Service Providers, vendors and ISVs was formed in March 1993, under the auspices of the Network Management Forum. The aim of this team, called SPIRIT (Service Providers' Integrated Requirements for Information Technology), was to produce specifications for a general-purpose computing (IT) platform by March 1995.
The SPIRIT members comprise representatives of most Service Providers in Europe, Japan and North America, and representatives of most major vendors. In addition, SPIRIT has established liaisons with major related organisations, such as X/Open, POSC (Petrotechnical Open Systems Corporation), Eurescom and TINA-C (Telecommunication Information Network Architecture Consortium).
Vendors find in SPIRIT the potential for increasing their efficiency in serving a large market with relatively uniform needs. SPIRIT's description of common needs can assist vendors in reducing risk in undertaking new offerings. Fewer customer-specific platform variations free vendor resources for creating value-added differentiators. Innovation comes more quickly, and more effort can be spent on improving the qualities (robustness, performance, and so on) of the standard platform.
Service Providers share a common incentive to use the SPIRIT specifications: a larger market is followed by increased competition and lower prices. Just as important, a common IT platform offers the advantages of interoperability and portability. Interoperability, which occurs because of the use of the same protocols between systems, means more seamless distribution. Portability, which occurs because of the use of the same languages and APIs, means applications can be moved across similar SPIRIT-conformant platforms. Commercial applications are more likely to appear (indeed, both vendors and SPs could develop commercial applications).
In addition, the work of SPIRIT provides a basis for technical analysis that previously Service Providers repeatedly did themselves.
SPIRIT has brought together users and vendors to reach significant agreements on the technical requirements that Service Providers may use in specifying a general-purpose computing platform for IT. In a very short time, SPIRIT has created a viable basis which Service Providers can use with discretion for procurement. While there are no rules requiring vendors to build SPIRIT-compliant platforms, nor any requiring Service Providers to procure them (procurement decisions are at the discretion of each Service Provider), the benefits that SPIRIT brings to both Service Providers and vendors makes likely its widespread use.
SPIRIT is governed by strict working procedures, which prohibit any vendor bias in the specifications, and are intended to avoid any actions or discussions that might violate any applicable anti-trust laws.
Major standards used in the SPIRIT Platform are:
SPIRIT was developed from contributions by:
The first phase of SPIRIT, which ran from March 1993 to September 1993, achieved the following results:
While SPIRIT Issue 1.0 can be thought of as a skeleton promising what SPIRIT would produce, SPIRIT Issue 2.0 has produced a viable basis for identifying the needs of a typical Service Provider's general-purpose computing platform.
SPIRIT Issue 2.0 has three normative elements: its references to industry standards, its profiles (selections among the options contained in some standards and/or groupings of standards), and conformance requirements. The actual functional and non-functional requirements are not part of the SPIRIT specification, but can be found separately on the NMF WWW Server (http://www.nmf.org).
SPIRIT Issue 2.0 was created during September 1993 to August 1994, from the contributions of several specialised technical teams; for example, the distributed TP team and the SQL team, with each such team consisting of members from Service Provider and vendor companies.
The additional emphases of SPIRIT Issue 2.0 are:
During the publication of SPIRIT Issue 2.0, it became obvious that far-reaching synchronisation between the work in the area of SQL within SPIRIT and X/Open together with the SQL Access Group was achievable. The result of this synchronisation is evident by the publication of the X/Open SQL, Version 2 Specification that contains nearly the complete SPIRIT SQL specification. Only the Interlanguage Calls Profiles between C, COBOL and SQL have been kept as part of SPIRIT.
SPIRIT Issue 2.0 improves and enhances the Structured Transaction Definition Language (STDL) specification. STDL addresses the user requirements of portability and interoperability in a multi-vendor transaction processing (TP) environment. Following the publication of SPIRIT Issue 2.0, SPIRIT submitted the STDL specification to the X/Open fast-track review process, resulting in the formal adoption of STDL as an X/Open Preliminary Specification. STDL is now the high-level transaction control language (HTL) within the X/Open Distributed TP Model.
The SPIRIT Issue 2.0 specification was very well received. Several major Service Providers (SPs) are currently using SPIRIT for their procurement specifications.
The current SPIRIT Issue 3.0 general-purpose IT platform specification is a logical extension of the SPIRIT Issue 2.0 specification and is fully upwards-compatible with its predecessor.
SPIRIT Issue 3.0 was created during September 1994 to October 1995, and is meant for procurement within 6 to 12 months after publication.
Specifications used by the SPs for their IT platform and telecommunication network management are related. This relationship is most prevalent in the area of systems and network management.
OMNIPoint is the NMF specification for telecommunication managed networks. SPIRIT and OMNIPoint have done as much as possible to synchronise between the two specifications: SPIRIT Issue 3.0 and OMNIPoint 2. For example, in the area of OSI management care has been taken that the same specifications are used. For SPs and their suppliers, this synchronisation guarantees interoperability in a wider market. For others using SPIRIT as a general-purpose computing platform, it enables them to benefit from the knowledge and expertise of the telecommunications SPs in the area of management.
Experience with SPIRIT Issue 2.0 has resulted in the introduction of a number of sensible combinations of specifications for use in procurement. Users will find it helpful to frame an Invitation to Tender around one or more of these system and component sets, focusing their attention on the particular deltas and qualities required.
The SPIRIT C and COBOL specifications have been augmented with detailed application program portability guides, that will help programmers to improve portability.
The SPIRIT internationalisation specifications have been extended with the Latin-2 code set to enable better use in Central and Eastern Europe.
The SPIRIT security specification has been added, drawn from the X/Open specifications in this area.
The computing facilities at the desktop are more and more an integrated part of the total IT environment. Consequently, SPIRIT addressed this area, and in particular focused on the management and interoperability between the desktop and their servers. For this purpose specifications have been adopted from the Desktop Management Task Force (DMTF).
The next phase will run until mid-1996.
The focus will be on maintenance, conformance, consolidation of
the experiences of the current users, and on adopting new mature standards.
It is expected that, in particular, specifications in the area of
management and object-oriented technology will mature in this timeframe.
| Contents | Next section | Index |