Assigning Roles and Responsibilities Rigorously

Grid Architecture provides a powerful framework for a difficult task. Some standard processes and math tools can help.

Let me start off by saying this is a rather technical and complex posting. The issue is how to perform new roles and responsibilities assignment, an issue that has become prominent as Distributed Energy Resource (DER) integration into electric power grids proceeds. Now in the U.S., FERC Order 2222 has pre-empted much of what I am about to show, which is unfortunate because the Order was not done using anything like the rigor provided here.

OK, that being said, how might we structure the process of adding new roles and responsibilities to segments of the electric utility industry so as to avoid hidden couplings that will eventually cause inter-organizational confusion and conflicts? We begin with some definitions, as usual.

• Structure is the arrangement or pattern of interlinkage of components; the manner in which parts are related or connected or interact; the organization of a system; the form or “shape” of a system.

• Components are uniquely identifiable, non-trivial, nearly independent devices, individuals, organizations, organisms, elements, building blocks, parts, or sub-assemblies that may be collected together to cooperate or to serve a common purpose.

• A capability is the ability to perform certain actions or achieve specific outcomes.

• A function is any of a set of related actions contributing to a larger action; a task, operation, or service. Functions combine to implement capabilities.

• A role is set of connected behaviors, actions, or processes carried out by an entity (a person or an organization) to animate, direct, or manage one or more functions.

• A responsibility is a duty or obligation for which an entity is held accountable. One or more responsibilities attach to a given role.

The purpose is to start with a set of desired capabilities and from that define functions to implement the capabilities that can be grouped into function sets that are assigned to entities in such a way that conflicts, duplications, and ambiguities are avoided automatically. Figure 1 shows this concept.

Figure 1. Overview of Structured Roles/Responsibilities Assignment

The rules that prevent hidden coupling are simple:

1. Functions must be distinct and non-overlapping (a condition we term orthogonal).

2. Each function can be mapped to only one function group (cluster).

3. Each cluster (functionality group) defines one and only one role.

4. Each role can be assigned to one and only one entity, but any entity can have more than one role.

The assignment problem can be approached in seven steps, with structural rules embedded in several of the steps to assure that hidden coupling (a cause of downstream conflicts) is avoided. Figure 2 shows the seven step process.

Figure 2. Seven Step Process for Roles/Responsibilities Assignment

Step 1: Specification - define the new capability (or capabilities) needed to meet new power system requirements, such as large-scale DER/CER integration.

Step 2: Decomposition - decompose the new capabilities into sets (clusters) of functions.

Step 3: Consolidation - in conjunction with existing functionalities, consolidate the functions list so that it consists only of unique, non-overlapping functions (mathematically, create an orthogonal set). Information on existing capabilities, functionalities, and components/systems are necessary inputs.

Step 4: Clustering - partition the functions into sets or groups. The clustering criteria for Step 4 for are largely technical in nature (access to required data, access to control devices, data and control coupling to other functions, modular cohesiveness, etc.). Every function must cluster to one and only one function group.

Step 5: Define roles - the crucial structural consideration here is that each functional group maps to one and only one role. Detailed definition of roles is done via standard methods of Business Process Design, based on how the functions must be implemented. This step will surface details such as access to infrastructure needed for Step 6.

Step 6: Map roles to entities and assign responsibilities - detailed industry structure documentation is necessary for this step. The crucial structural consideration here is that each role can map to only one entity but any entity can have more than one role. Business Process Re-engineering, which is well-known to most utilities since they do this for themselves, is applied across multiple entities. Some of other criteria to be considered are:

• Technical factors

  • component accessibility

• Structural factors

• Business factors

  • entity capacity

  • entity dependability

• Regulatory factors

• Financial factors

• Human factors

  • skill sets

  • staff availability

The bulk of the issues that can be divisive are encapsulated in the criteria for Step 6. Note that in addition to the usual issues, for the DER problem it is necessary to consider the capacity and dependability of the DER suppliers and aggregators, meaning the likelihood that the entities can carry out the roles successfully and will do so over the long haul. Business Process Re-engineering methodology provides a standard framework within which to resolve these issues. Since multiple entities are involved, it may be useful to engage an independent third party with relevant experience to lead this process.

Step 7 Inter-Entity Integration - once the roles assignments are settled, there is a necessary post-assignment step to ensure that functionalities which reside in separate entities, but which must coordinate or cooperate to fulfill capabilities, will have the necessary means to do so.

More About Clustering

The formal methods for grouping functions into clusters are perhaps less familiar than the other steps listed above. There are many approaches to clustering and Figure 3 shows some of the most common.

Figure 3. Common Clustering Methods

I recommend the use of graph partitioning methods for problems of more than trivial size. The basic idea is to represent the set of functions as a graph, with edges between graphs having weights that represent how strongly the connected functions are related. Figure 4 shows an overview of one way to construct such graphs.

Figure 4. Edge Weight Calculation

Functional strength (cohesiveness) is the degree to which elements of a function jointly contribute to a well-defined goal. Figure 5 shows how to assign values to this.

Figure 5. Function Cohesion (Strength)

Each function can have only one cohesiveness value(strength). Do not consider internal function design when assigning cohesiveness value, only externally visible behavior. Note that a function in which a set of tasks or operations have no externally visible meaningful relationships to each other (called coincidental strength) should be scored the same way as Logical strength, but in practice that function should be redesigned.

Figure 6 shows how function information coupling is quantified.

Figure 6. Function Information Coupling

Four types of information coupling (plus the no-coupling option) depend on what kind of information is shared between a pair of functions and how much data it takes to do so. Consequently this is evaluated for every pair of potentially connected functions. Note that the coupling value includes size parameters for each of the two functions. A single function has a size of one. If a legacy function group is being considered in the partitioning and the group itself is not to be broken, then the group is treated as a single graph node with a size equal to the number of functions in the group.

Use the cohesion and strength values to compute the edge weights for the function graph, as Figure 4 above illustrates. Once the graph is constructed, there are many choices for methods to partition the graph. Figure 7 shows a taxonomy of methods with particular choices highlighted.

Figure 7. Graph Node Clustering Algorithm Taxonomy

Some of these methods are implemented in tools like igraph and NetworkX. If you have not worked with graphs and graph partitioning before, I recommend that you find a specialist to assist you.

The result of the partitioning yields the function groups needed in Step 5.

Final Comments

Complex problem solutions always benefit from clear definitions, well-formed problem statements, and methodical processes. The process described here can and should be done in an open, transparent manner, and using the framework and methods helps achieve consensus. The area where the most contention is likely to arise is in Step 6. This is why I advise using a standard methodology (Business Process Re-engineering) led by a disinterested and unbiased external party for this step.

Acknowledgement

I greatly appreciate the assistance of Paul De Martini and Sinan Aksoy, PhD in helping me think through this process.