The SOV-1 specifies a hierarchy of services. The elements in the hierarchy are M3 Services (i.e. service specifications rather than service implementations), and the relationships between the elements are specialisations – i.e. one service is a special type of another. Service attributes, interfaces and constraints are inherited down a service taxonomy – e.g. if Service A is a specialisation of Service B then it also inherits all the features of Service B.
The purpose of an SOV-1 is to provide a governance structure for a Service-Oriented Architecture. Along with SOV-2, Service Interface Specification, it defines a standard library of service specifications for an enterprise, which service implementers are expected to conform to.
Usage
The intended usage of the SOV-1 includes:
- SOA governance.
- Identification of services.
- Service planning.
- Service audit.
- Service gap analysis.
- Providing reference services for architectures.
- Tailoring generic services for specific applications.
Product Description
In MODAF terms, a service is an implementation-independent specification of a packaged element of functionality and/or capability.
There is, however, potential for confusion between services and capabilities. To help clarify this:
The key indicator of a service is that it provides a standard interface to consumers. This means that services may be used as “wrappers” for one or more capability in order to provide a standard method of access to the capability. A well-designed service taxonomy provides a set of specifications for capability providers to adhere to.
An SOV-1 depicts services, specialisation relationships between services, service attributes and service policy (i.e. constraints). A service taxonomy persists over time (an architect may wish to specify historical, current or future services) and may be referenced by multiple architectures.
In SOV-1, services are only defined in the abstract, i.e. SOV-1 does not specify how a service is to be implemented. An SOV-1 is structured as a specialisation hierarchy of services, with the most general at the root and most specific at the leaves.
In contrast to AV-2, Integrated Dictionary, an SOV-1 is structured using only one type of specialisation relationship between elements: super- subtype. A super-subtype relationship is a relationship between two classes with the second being a pure specialisation of the first. Any service that specialises from another must implement all the functionality of its parent, and provide all the same input and output interfaces of its parent; in other words, any specialised service shall be entirely compatible with its parent (however, it may add functionality and interfaces). For example, if a service, “Printing”, requires input of paper size and ink colours, a service, “Hi-Resolution Printing”, that specialises from it must also accept these parameters and produce equivalent behaviour when initiated.
Creating a Service Taxonomy diagram
To create a Service Taxonomy diagram:
- Click on Service Taxonomy in the Action Artifact area, and then select Create New Diagram.
- Type the diagram name and press Enter.
- A blank diagram is created and you can start constructing the view. You can create ServiceSpecifications and connect them with Generalization under the diagram toolbar.
MODAF in Visual Paradigm
The MODAF is brought to you by Visual Paradigm, a full-featured development platform. Visual Paradigm provides an easy-to-use, model-driven MODAF tool that supports the development of MODAF views and models. You can create integrated MODAF products and generate architectural documents that facilitate organizations to efficiently coordinate enterprise architecture initiatives.