Entitlement Standards/Solution/Management/Tracking/Specifications

Quality Specifications

RQ related specifications are logically layered. Their development is also logically sequenced in time. The following table presents logical layers A to E, from system to user, or from the most fundamental to the most sophisticated, where, typically, more fundamental layers are required to support the more sophisticated ones.

Numbers in parenthesis indicate sequence number and the proposed development sequence follows layers ABCED, mostly as A could be agreed upon rapidly, as adequate standards already exist, and D requires the most industry agreement, as well as an open time-line to specify new RQs that progressively achieve industry consensus.

Layered Specifications Work Summary
Combining specification layers (e.g. A to E), natural patterns, as well as existing resources and specifications, RQ specifications can be organized as:

  • A- (1) Execution:formula and content reference query and formula language:
    • use XPath (e.g. XSLT, Xquery) for rules, policies, formulas
    • simple, powerful, context aware, strong standards-based
    • enable governance execution (e.g. monitor, control)
    • help resolve major IT issues (e.g. security, analysis, management)
  • B- (2)Negotiation:RQ negotiation and qualitymatching(e.g. QoS, NFPs, KPIs):
    • use QoS specification and SOA to specify RQ/TRQ negotiation
    • RQ providers and requesters can negotiate acceptable quality levels for any shared quality
    • TRQs may also include tracking parameter negotiation
    • a generalized standard negotiation process specification is required
  • C- (3) Infrastructure:support RQ definition, sharing, management, tracking:
    • use REMMS and proposed RQ tracking solutions
    • merge to integrated standards specification set
    • integrate with resource and process management & modeling
    • support Relations, RQs, TRQs, Schedules, Processes
    • include and support execution
  • D- (5)Semantics:resource quality value interpretation and metrics:
    • build on QoS specifications
    • support custom RQs (e.g. default, Infrastructure level)
    • define semantics “plug-in” interface
    • define semantics “plug-in” infrastructure
    • add semantics “plug-ins” for specified RQs
    • support semantics “plug-in” certification (e.g. extension)
  • E- (4) Modeling:RQ modeling, based on both infrastructure and semantic layers:
    • use Resource Modeling (e.g. REMMS) with built-in modeling and tracking for qualities
    • ensure Resource Modeling preset profiles for modeling domains (e.g. BA, EA, BPM)
    • develop UML profile or update to support required resource modeling
    • provide adaptable modeling to support semantics extension without redefining modeling