Figure 1P-1. Frameworx Viewpoints

MODA / Information Framework / Business Entity / Patterns Domain / Policy ABE / Figure 1P-1. Frameworx Viewpoints

Project:

Figure 1P-1. Frameworx Viewpoints : Object diagram

Created:	5/11/2022 9:20:58 AM
Modified:	6/7/2022 9:10:41 PM
Project:
Author:	Natha Paquette
Version:	1.0.0
Advanced:
ID:	{262DC70A-E431-48cc-9465-A58A08678A43}

Introduction Policy management has been portrayed as an effective mechanism to orchestrate the behavior of distributed systems. Different versions of policy management have concentrated on different aspects of this problem, ranging from defining business goals to specifying low-level configuration changes in a device. Unfortunately, such efforts have been scattered and uncoordinated. The Frameworx (formerly known as NGOSS) specifications prescribe an architectural framework, supplemented with principles and procedures, which can be used to guide the development of distributed computing solutions through the creation and re-use of Frameworx artifacts. The set of Frameworx artifacts, available through the Frameworx Knowledge Base, form a comprehensive set of information that enables business needs to drive the implementation of Frameworx using commercial off the shelf software. The concept of the knowledge base is central to the methodology because it provides a way to “link” work efforts and activities as the progressive views of the system solution are developed. The reader is encouraged to read [053Main], which describes the Frameworx architecture as a whole and the Frameworx viewpoints in particular. This approach is shown in Figure 1P-1. Policy, of course, plays a critical role across all four Frameworx viewpoints. Since policy can be used to represent, define and manage entities of all types, its integration into the SID framework takes the form of defining a new Common Business Entities ABE to contain the policy information model. To find the Information framework figure, refer to “GB991 Core Frameworks Concepts and Principles” guide book. The purpose of this phase of the SID is to define a set of business entities that can be used to describe Frameworx business artifacts. One of the goals of the SID model is to enable a seamless transition from business concepts and definitions to other domains, such as networking. This becomes critical in order for business people to be able to properly leverage highly technical concepts, as well as concepts that are critical to the operation of the business. Policy is one of those concepts that has the potential to be used in multiple domains, and for multiple purposes. Thus, what is needed is the ability to define: <ul>
<li>A common representation that can be used for all four Frameworx viewpoints</li><li>How management applications can use policy</li><li>How policy entities of one viewpoint can specify and interact with policy entities of another viewpoint</li></ul>
This addendum covers the business definition of the Policy model. This model is used to define formal definitions for entities that are part of a policy management methodology, be it an application, the issuing of a command, or something in-between. Policy management means many things to many people. The most common categorizations of Policy are for business use, networking use, and architectural use. To point out the important link between policy and Frameworx (specifically, the work in [053C] and [053D]), these three categorizations will be rephrased as follows: <ul>
<li>Policy is a set of business rules and is meant for use by business people</li><li>Policy is a means to control Quality of Service (QoS), and is meant for use by networking people</li><li>Policy is a means to scale the system, and is meant for use by systems architects</li></ul>
These three definitions all have a common theme: policy is used only by a specific set of users. In contrast, the Frameworx Behavior and Control Specification ([053C]) posits that a Frameworx system must simultaneously address the needs of different constituencies of users. This Addendum abstracts the representation and application of policy into a set of concepts that are appropriate for use by business people. This set of abstractions can then be used for the following tasks: <ul>
<li>Define a canonical model for policy</li><li>Standardize the representation of policy independent of the content of the policy</li><li>Provide an infrastructure that supports extending policy to support application-specific domain information</li></ul>
This paragraph will also start to explore the rich set of interactions and relationships with other business entities defined in the SID. This is meant to be a very comprehensive work, and as such will proceed over several SID phases. This is necessary because of two reasons. First, the business entities in other SID Addenda are evolving. As more detail is added to them, richer relationships are uncovered. Second, the model described in this Addendum is a high-level framework for policy. As more experience is gained using this model, more relationships and entities will be defined. The reader conversant with other SID Addenda will note that other SID Addenda have a strong correspondence with the eTOM [eTOM]. This is harder to do for policy, as policy is only defined in a very high-level, abstract sense of the eTOM. This can be seen in Figure below. Policy doesn’t appear as a top-level process, and it shouldn’t. This is because policy is an infrastructural component that affects ALL of the SIP and Operations processes of the eTOM. The reader is encouraged to refer to [eTOM] for an explanation of the various business processes that are defined to support the concepts in the above domains.