Open Platform 3.0™ Snapshot – Platform Capabilities

 

This chapter lists the business and technical capabilities that a conforming platform must or can have, and describes some realizations of the technical capabilities.

A capability is mandatory if a platform “SHALL” provide it. A capability is optional if a platform “CAN” rather than “SHALL” provide it. The documentation of a platform SHALL state clearly which optional capabilities it does provide.

A platform SHALL have a description of the realization of each mandatory capability and of each optional capability that it provides. This description, and any standards or specifications that it references, SHALL be open: it SHALL meet The Open Group Standards Adoption Criteria. [ADOPTION]

Any capability can be realized in a number of ways. How capabilities are realized in different platforms affects interoperability. It is important that realizations use the same standards, and are compatible with each other. This Snapshot does not constrain realizations, but it does require that they be documented so that, even if interoperability cannot be achieved “out of the box”, it can at least be programmed.

Note:  It is intended that the Open Platform 3.0 standard will include standard realizations. This Snapshot includes a small sample, to illustrate that intention.

Business Capabilities

These are capabilities that are deemed necessary (though not necessarily sufficient) to the achievement of business objectives.

Support for Services

Service Design

A platform CAN provide facilities for service design.

Service Deployment

A platform MUST support the deployment of services.

Service Operation

A platform MUST support the operation of services.

Discovery by Users

A platform MUST provide a means by which appropriately-authorized users can discover what services it supports.

Discovery by Services

A platform CAN provide a means by which appropriately-authorized other platform or service instances can discover what services it supports.

Service Catalog

A platform CAN provide a service catalog, which describes services that its instances support and/or services that other platform instances support. If a service catalog is not provided, human local knowledge or system intelligence for how to select, size, model, and pay for a service is required.

Many vendors may imagine the service catalog as the entry into Open Platform 3.0 from a business capability perspective.

Service Composition

This is the composition of business services (from existing and supported emerging technologies) that may involve both human and machine interaction, multiple locations, and multiple providers, to create a new business service.

Service Composition

A platform CAN enable appropriately-authorized users to compose services, including by service orchestration and service choreography.

Business Data Analysis

These are capabilities to analyze data so that a user or service can discover and communicate insights for knowledge and decision-making purposes.

Analytics is key to developing a purposeful and trustworthy information-driven means to empower decision-making. It can span structured, semi-structured, and unstructured data.

Guided Data Acquisition

A platform CAN enable a user or a service to discover, link, and synthesize relevant data from diverse sources (existing or new, within or outside of the enterprise, and increasingly on-the-fly) with minimal user guidance moving from data in situ to its curation for downstream use.

Acquisition needs could involve diverse types and formats of data. Guided acquisition tends to involve humans and tools to engineer, extract, and establish relevance of features in data.

Note:  This capability is derived from the draft Business Data Lake specification, and is subject to revision as that specification is further developed.

Data Exploration

A platform CAN enable a user or a service to reduce the amount of data to examine so as to focus on evaluating key metrics and measures (as in KPIs) for business reporting or for visualization.

Exploration may involve the use of:

  • Descriptive statistics to characterize data distribution and dispersion
  • Techniques to identify possible relationships among two or more items
  • Visualization for reporting

Note:  This capability is derived from the draft Business Data Lake specification, and is subject to revision as that specification is further developed.

Data Persistence

A platform CAN enable a user or a service to store, retrieve, and manage large volumes of diverse types of data.

This could involve smart storage and retrieval technologies and related aspects, such as capacity planning, transport network, integration, protection, backup, and archival.

Note:  This capability is derived from the draft Business Data Lake specification, and is subject to revision as that specification is further developed.

Velocity Adaptation

A platform CAN handle variability in speeds and feeds (variation in data velocity).

There is a need to manage variances in data velocities at required scale in a timely manner. The historical solution approach to handling velocity was mostly based on separating writes and reads – this may not be adequate in the case of big data.

Note:  This capability is derived from the draft Business Data Lake specification, and is subject to revision as that specification is further developed.

Stream Processing

A platform CAN process large-scale streaming data and provide near real-time response.

This capability enables analysis of data in motion. It is required for processing real-time streaming data or event data where the ratio of event throughput to number of queries is usually high.

Note:  This capability is derived from the draft Business Data Lake specification, and is subject to revision as that specification is further developed.

Business Data Reporting

This is a capability to support business management reporting, accountability, traceability, and governance, and to make business information available for system-of-record support, including information for billing, inventory, and regulatory reporting.

Analytics Reporting

A platform CAN provide reports showing data analytics results.

Data Conveyance

These are capabilities to convey information between devices and services.

Seamless exchange of information across organizational or system boundaries is crucial to The Open Group vision of Boundaryless Information Flow™. It implies the ability to transport information for any end-to-end business scenario.

Information distribution may be viewed as a special case of information exchange.

Different platforms or parts of platforms may be optimized for particular forms of communication. Information needs to be transported transparently, using multiple standard network technologies and protocols. This results in the individual technologies being irrelevant/invisible to the business.

Information to be transported may provide notification of events that have occurred, or actions to be taken. Such notifications need to be given consistently at all interfaces where they are presented.

The following requirements apply to the realization of the capabilities in this section.

  • Data Representation: The documentation of an interface by which a platform receives or delivers data SHALL describe how data elements are represented within the data.
  • Network-Neutral Data Interface: A platform SHALL be able to receive data from and deliver data to devices and services in a form that is independent of the networks and protocols used to transport the data.
  • Device-Neutral Data Interface: A platform SHALL be able to deliver data received from devices to services and receive data from services for delivery to devices in a form that is independent of the devices concerned.

Data Conveyance within a Platform

A platform SHALL be able to convey data between any services that it supports and any devices connected to it.

Data Conveyance with Other Conforming Platforms

A platform SHALL be able to convey data between any service that it supports or device connected to it and any other conforming platform that supports a service or is connected to a device producing or consuming the data.

Data Conveyance with Non-Conforming Platforms

A platform SHOULD be able to convey data between any service that it supports or device connected to it and non-conforming platforms (for example, legacy platforms), as well as with conforming platforms.

Note:  This clearly depends on support for the appropriate interfaces by the non-conforming platforms concerned.

Intellectual Property

A platform SHALL have a means of preserving intellectual property.

Governance

Note:  Governance capabilities are expected to form an important part of this section ultimately. At this point, no specific governance capabilities are defined.

The following requirements and considerations apply.

  • A platform must enable appropriately authorized identities to institute the desired behaviors needed for effectively managing information/knowledge assets, and related business processes across the ecosystem(s) in focus by establishing decision rights, accountabilities, and mechanisms for change.
  • Effective governance ensures proper alignment and coordination across parties, compliance, and mitigation of risks. It involves lifecycle processes around a firm’s information/data assets.
  • Existing governance frameworks like the ISACA COBIT and emerging reference models like The Open Group IT4IT™ standard should be considered as applicable, and conforming platforms should be sensitive to the need to trace and report value to the business and comply with existing and future regulatory demands for managing risk.

Technical Capabilities

These are capabilities that are defined in technology terms and that are needed for the instantiation (in whole or in part) of business capabilities.

Note:  A technical capability must always be driven by one or more business capabilities.

They include capabilities related to system operation, and capabilities that support the maintenance of good operational characteristics in a system of which a platform forms a part, such as safety, security, resilience, quality of service, and quality of data.

Event Handling

Business solutions can require the correlation of events from multiple sources. Also, system event correlation can be critical to assure SLA/OLA compliance, and so to quality of operation.

A possible event model is described in Appendix B.

Event Correlation

A platform CAN have the ability to correlate events seamlessly, real-time, from multiple sources (including cloud computing, mobile devices, social media, big data, and IoT).

Semantic Consistency

This is the ability to enable consistent business and technology semantics. Seamless information exchange relies on integration and interoperability methods that effectively address nomenclature, syntax, format and structure, and semantic mismatches.

In a business or social ecosystem, different participants create and process data in the light of different information models. Meaningful information exchange requires consistent interpretation of the data across different models. This implies a multi-enterprise data governance approach that is much more difficult than the approach available within a single enterprise.

Semantic Analysis

The documentation of a service or device that delivers or receives data may describe the data element concepts that its data elements represent. A platform CAN provide a means by which users or services can determine whether described data element concepts are equivalent or similar.

Data element concepts are often described in terms of semantic models, which can take many different forms and formats. Within an ecosystem, they will likely span a wide spectrum from Entity-Relationship-Attribute (ERA) forms used for traditional data models to the subject-predicate-object Semantic Web triples in Resource Description Framework (RDF) and Web Ontology Language (OWL) forms. Even when different participants use the same modeling technique within an ecosystem, they can produce radically different models.

Resource Management

A platform that has resource management capabilities SHOULD enable them to be applied in accordance with policies set by appropriately-authorized users.

Parallel Processing

A platform CAN have the ability to utilize parallelism.

Parallelism can give significant gains in processing speed, and help speed up the overall process, from ingestion to insight, especially with large data volumes.

Note:  This capability is derived from the draft Business Data Lake specification, and is subject to revision as that specification is further developed.

Load Apportionment

A platform CAN provide a means of apportioning load between computing resources.

Resource reservations and load balancing CAN include migrating load between platform instances.

Note:  This capability is derived from the draft Business Data Lake specification, and is subject to revision as that specification is further developed.

Cluster Deployment

A platform CAN enable a user or system to set up a service infrastructure of hardware clusters to process workloads (including big data workloads).

Note:  Many big data projects involve as the first step both set-up and maintenance of an infrastructure cluster. Some platform providers utilize Infrastructure as a Service (IaaS) models to cut down time and effort involved.

Note:  This capability is derived from the draft Business Data Lake specification, and is subject to revision as that specification is further developed.

Identity, Entitlement, and Access Management

Identity, entitlement, and access management is the security discipline that enables the right individuals to access the right resources at the right times for the right reasons. This is also applicable for devices, applications, or any other entity that requires access to information or a system.

Principal Identity Determination

A platform CAN enable a service instance to determine reliably the identity of any principal.

This typically relies on authentication of principals.

Principal Role Determination

A platform SHALL enable a service instance to determine reliably the roles (for example, “staff” or “public”) that a principal has.

This typically relies on authentication of principals.

Directory

A platform CAN maintain a directory of users, devices, applications, or any other entity that requires access to information or system, and provide services with information about them.

Note:  When a set of conforming platforms is used by an enterprise or in an ecosystem, one of them should have a directory, which can be accessed by the others.

Access Control

A platform SHALL enable immediate, easy, and secure access to services or data to authorized principals, and SHALL deny access to principals that are not authorized.

Authorization

A platform SHALL ensure that authorization is granted in accordance with policies set by appropriately authorized users. Roles and personas CAN be attributes used by the platform in this context.

Security

Note:  Security capabilities are expected to form a major part of this section ultimately. At this point, no specific security capabilities are defined.

The following security requirements and considerations apply.

  • Security capabilities must support provision of appropriate security and privacy as information passes from (and is possibly transformed by) services, in order to enable appropriate and adequate trust in the resulting information that is utilized in the new business services (and potential business models).
  • Further, security is assured through enterprise and service monitoring and event alerting through any one of the cloud computing, mobile devices, social media, big data, or IoT capabilities by asserting that Open Platform 3.0 has an enterprise event correlation capability.
  • Security levels and compliance requirements must be able to be defined and implemented consistently and interoperably throughout an ecosystem. This means, in particular, that the representations of roles or other access management-related attributes with common semantics can be mapped across different parts of the ecosystem.

Audit

Audit capabilities contribute to security and governance.

Audit Trail

A platform SHALL have means to capture any activity from a user, device, application, or any other entity to support policy performance reporting, policy compliance, and policy deviation. This will include privileged user account monitoring and privilege creep.

Quality of Service(QoS)

Platform QoS Attributes

A platform SHALL expose standard non-functional and supportability QoS attributes for its own operation.

Service QoS Attributes

A platform SHALL maintain records of the non-functional and supportability QoS attributes that it exposes for its own operation and of those exposed by the services that is supports.

Quality of Service Reports

A platform SHALL provide reports of the QoS attributes that it records.

QoS Exception Events

A platform SHALL be able to create an exception event when there is a variance beyond set limits of any supported attribute. The limits and whether an event is created for any particular breach SHALL be determined by policies set by appropriately-authorized users.

The variance SHOULD be addressed, where possible, without disruption at the service layer, so that the attribute returns to expected policy levels as soon as practicable.

Quality of Data

Quality of Data Attributes

A platform SHALL maintain records of the data quality attributes of the data that it makes available to users and services.

Quality of Data Reports

A platform SHALL provide reports of the quality of data attributes that it records.

Management/Monitoring

Management by Users

A platform SHALL enable appropriately-authorized users to monitor and control the services that it supports.

Management by Services

A platform SHOULD enable appropriately-authorized service instances to monitor and control the services that it supports.

Platform Self-Management

A platform SHOULD monitor and reliably report its state of health, and take action when a report warrants this.

Upgradability

Non-Disruptive Assimilation

A platform SHOULD support non-disruptive assimilation of upgrades and new components by itself and by the services that it supports. If it cannot support non-disruptive assimilation, it SHALL support scheduled assimilation of upgrades and new components.

Note:  This enables continual service improvement.

Policy-Driven Platform

Platforms and other system components typically act as policy enforcement points for access control and other policies. This section describes capabilities that support policy-driven operation. The underlying concepts are described in [XACML].

For example, a user, system, or machine selecting a service from a service catalog may select options for time, service level, and model size, and the chosen options are enforced by policy whether the service is executed in-house, outsourced, or multi-sourced. The user has and should expect that the chosen SLA is protected by policy that enforces OLA compliance on outsourced or multi-sourced service delivery, no matter what “depth” the OLA outsource or multi-source has derived.

Note:  [XACML] defines a framework for policy-driven access control, but its definitions of PAP, PDP, and PIP are framed in general terms, and are to be understood here as potentially applying to other kinds of policy. (Policy Retrieval Point (PRP) appears to be a recent introduction. It is not in the XACML 2.0 standard, and is not used here.)

Policy Administration

A platform CAN act as a Policy Administration Point (PAP).

Policy Decision

A platform CAN act as a Policy Decision Point (PDP).

Policy Information

A platform CAN act as a Policy Information Point (PIP).

Capability Realizations

This section describes specific realizations of the capabilities described earlier in this chapter.

A platform NEED NOT implement the realizations described here for the capabilities that it has, except where the realization is explicitly stated to be mandatory. The documentation of a platform SHALL state which realizations it does implement, and SHALL describe all of its realizations (including those not described here) so that interoperable systems can be developed independently.

Note:  Only four realizations, and only two capabilities, are described in this Snapshot. This illustrates the concept of capability realization. It is intended that the Open Platform 3.0 standard will describe more realizations.

Device Data Exchange

This section describes realizations of the Device Data Exchange capability for Data Conveyance.

Realization 1

The platform functions as the Internet Object User Platform of the Internet Object Model and communicates with the Internet Object using the Open Messaging Interface [O-MI] over HTTP, with payload formatted in accordance with the Open Data Format [O-DF].

Realization 2

The platform functions as the Managed Object User Platform of the Managed Object Model and communicates with the Object Manager Platform using the Open Messaging Interface [O-MI] over HTTP, with payload formatted in accordance with the Open Data Format [O-DF].

Realization 3

The platform functions as the Object Manager Platform of the Managed Object Model and communicates with the Managed Object using the Open Messaging Interface [O-MI] over HTTP, with payload formatted in accordance with the Open Data Format [O-DF].

Access Control

This section describes a realization of the Access Control capability of Identity, Entitlement, and Access Management. This implementation is mandatory.

The platform acts as a Policy Enforcement Point (PEP) as defined in [XACML].