The SPIRIT specifications are primarily intended for use, by Service Providers, in procurement of IT systems. However, SPIRIT can be used in several phases of the work of any IT organisation. For instance:
The examples outlined here are based on experiences from within the Service Provider community.
However, as SPIRIT is a set of general-purpose IT specifications, the experiences are equally applicable to other IT communities such as banking, government, military, healthcare, commercial multi-nationals and other large organisations.
SPIRIT Issue 3.0 defines the concept of System and Component Sets. These collect together commonly used computer platform capabilities, which generally have strong inter-relationships or dependencies. This helps procurers in making decisions about the detailed set of IT components they need to specify. It also helps in enabling a higher-level view on overall systems architecture.
SPIRIT does not, however, set out to provide a complete architecture. Rather, it is restricted to the underlying platform. SPIRIT has abstained deliberately from those company and business specifics that are represented in applications or information architectures. SPIRIT does, however, provide a robust, scaleable foundation upon which such business-specific capabilities can be built. Its source was the business requirements identified by many Service Providers, who expect to run a number of different systems configurations in their IT departments based on subsets (System Sets) of SPIRIT.
SPIRIT provides, for example, the structure and specifications for detailing the IT infrastructure for such a specific area as management of the end-user environment. SPIRIT also applies to the area of the distributed transaction environment to establish data consistency among several existing applications with overlap in the coverage of the business and the data that represent that business.
Architectures can vary considerably in scope and detail. The architecture for a large service provider, with a rich legacy of existing systems and applications, upon which many current services are based, will be a substantial document. In contrast, the architectural needs of a start-up mobile or network operator, providing its services to a small group of value-add Service Providers, will be much less and will probably focus on more short-term needs.
An essential part of the establishment of a good IT environment is regular and intensive communication between customer and suppliers. Each user organisation has a list of preferred suppliers, based on their installed hardware and software, and on positive experiences with those suppliers in the past. Cooperation with those suppliers is of mutual benefit. For the customer, such contact provides early information about new developments and shifts in the market. It gives the customer early opportunity to assess current vendor strategies and enables quick response to internal requests from other business units that are supported by the users' IT environment. On the other hand, suppliers require early feedback about likely market acceptance of newly developed products.
The SPIRIT specifications are the result of ongoing and continuing discussion between the vendor and consumer communities. In fact, within the SPIRIT programme itself, such discussions were the litmus test of whether to include certain specifications, and which specific parts. The SPIRIT specifications eliminate problems that may have prevented the implementation of standards in the past, such as the presence of too many options or too much functionality.
Thus, individual users should consider using the SPIRIT specifications as the basis of ongoing discussion with their vendors. By discussing such issues with suppliers, a better understanding can be acquired of how a particular vendor can help to achieve added value with customers.
The prime purpose of SPIRIT is to provide the basis for a Request for Tender (RfT). SPIRIT has already been applied several times successfully for this purpose. It is understood that many functional and non-functional requirements will be added to the actual RfT by individual users, depending on their specific needs. However, the value of SPIRIT is that a tedious and costly part of the preparation of the RfT can be based on readily available material. These system sets, defined in Part 2, System Sets, are the consolidation of the use of such specifications in actual procurements.
SPIRIT is a precise and stable specification that has been checked with available solutions several times. Using these specifications helps to avoid the problem of buying a specific solution that only fits the current requirements. Also, large IT systems tend to be extended during their lifetime, at least once. Solutions based on one particular vendor's product or architecture tend to lock users into that supplier for subsequent upgrades. SPIRIT, because it is an open, industry agreement, provides the best possible guarantee to lessen such problems.
The need for Service Providers to cooperate between themselves for their ongoing business, as well as the need for better interoperability between existing applications within a Service Provider, requires the ongoing assessment of their current IT portfolio.
Which protocol is used for email, for file transfer, or for managing the elements of the IT infrastructure? There are many standards to choose from, and, as a result, the current portfolio may be a plethora of standards (and options within standards) that hinder the efficient operation and integration of IT.
The structure provided by SPIRIT, as well as the actual specifications, provides the tools to assess current portfolios. It may even provide the basis to settle internal disputes about which specifications to use for a specific purpose.
Most vendors will have to respond to customers' RfTs which reference the SPIRIT specifications. Obviously, each vendor will assess their strategy and product line against the SPIRIT specifications, but because the Telecommunications Service Providers represent such a large homogeneous market, most vendors are already preparing their product development plans, based on the SPIRIT specifications. In fact, by their supportive participation in the SPIRIT programme, they have had early insight into the Service Providers' requirements and many have products available now.
The last few years can be characterised by the alliances formed in the IT industry. For vendor alliances, SPIRIT could be a basis to establish product synergy. In particular, SPIRIT can be used as the basis of conformance and interoperability testing between product ranges. By doing this, suppliers can integrate their products more easily and provide the market with a more coherent and richer portfolio of products.
For independent software vendors, SPIRIT provides the platform specification that, by its nature and origin, is a safe basis for further application development.
For the Service Provider, as a supplier of managed telecommunications services, SPIRIT also provides the platform upon which to deliver many of their products, as well as the basis for all of their new internal operations systems.
The latter, in particular, is exemplified by the NMF OMNIPoint
specifications that Service Providers use as the basis of their
management and operations systems.
OMNIPoint is a set of implementation agreements which are
intended to be used in a Telecommunications Management Network
(TMN) environment.
OMNIPoint-based management systems can use SPIRIT as the underlying
computer platform and thus be able to provide a robust, scaleable and
highly performant solution to mission-critical needs.
As you would expect from two sets of specifications coming from
one organisation, SPIRIT and OMNIPoint are well aligned.
| Contents | Next section | Index |