I have been using tools I learned through the System Design and Management Program to help integrate unmanned aircraft systems (UAS) into the National Airspace System—a complex challenge made more difficult because critical stakeholders appear to have value definitions that are at odds with each other.
As an overarching methodology, I’m using the value-creation framework developed by E. Murman et al. in Lean Enterprise Value, including aligning value among stakeholders with an enterprise purpose statement and an X matrix analysis (see previous Pulse articles for detailed discussion).
The next task for the enterprise architect is to synthesize potential methods for delivering the desired enterprise attributes using Object Process Methodology (OPM). The goal at this stage is to implement a process that is robust enough to handle the often subjective inputs that result from the value-alignment activities, while at the same time preserving the rigor of the analysis. Without this kind of approach, it is very difficult to defend the “solution” as the best possible alternative.
In the last article we defined the enterprise scope and purpose as “restore principle of maneuver,” a higher level objective of the military that calls for placing the enemy in a position of disadvantage through the flexible application of combat power. This purpose also serves the FAA’s safety needs by enabling a more maneuverable platform while meeting the Department of Defense’s needs for war fighting capability.
With this in mind, one potential set of enterprise solutions for restoring maneuver to UAS platforms can be illustrated implementing the enterprise architecting framework developed by Deborah Nightingale, director of the Lean Advancement Initiative (LAI) and Donna Rhodes, director of the Systems Engineering Advancement Research Initiative (SEAri). Note that the knowledge integration between LAI and SEARi was already occurring.
This framework [see Figure 1] connects the enterprise purpose to the value attributes identified via the X matrix and puts each attribute “into action” to describe the type of activity needed to produce the desired end-state. By inserting the “enterprise views” column between the purpose and these attributes, the enterprise architect naturally begins to see potential solution paths simply by considering how the purpose can be met in a specific context (enterprise view) by acting on a specific outcome (value attribute) using one or more potential mechanisms (points of leverage).
These “points of leverage” were developed by systematically going through the previous three columns and asking how they could be combined to achieve the desired purpose of restoring maneuver to UAS platforms.
For example, consider the first mechanism listed under “points of leverage”—educated participants. This mechanism was postulated by considering what could be done within the “policy” domain to deliver the value attribute of “ensure safety.” One such “policy” decision would be to mandate or encourage better education of national air-space users concerning the operation and characteristics of UAS platforms and procedures. Others might be to require more capable equipage or establish direction for procedures and standards.
The art of architecture
While Object Process Methodology is enormously useful, there is no substitute for experience in system architecture. Even for my SDM master’s thesis, I didn’t actually re-create the full matrices for these systems on paper because I largely knew what concept pieces would work with others and which wouldn’t just by inspection.
Architecting is an art as well as a science. An in-depth knowledge of both the subject matter and architecting is necessary to avoid a massive number of potential combinations. Over time, experience gives you an intuitive sense for what will work and what won’t.
Of course, the participation of several team members is necessary to tackling any complex system challenge—if only to provide the requisite knowledge to fully address all aspects of the project. For that reason, I think the more team members trained in SDM’s hallmark systems thinking methods the better. I’m convinced that attempting to do an enterprise architecting job with someone who is not an expert (or at a minimum, very knowledgeable) in these tools—as well as the specific material and context—will result in a
lot of rework, if not outright failure.
Figure 1. UAS Airspace Integration Enterprise Solution OPM
while at the same time identifying those mechanisms that have the highest degree of connectivity to multiple value attributes. These mechanisms then become “points of leverage” in the potential design space that the architect can further refine for maximum perceived benefit to the stakeholder community.
The overarching enterprise architecture represents a distillation of a host of “enterprise views – value attributes – points of leverage” combinations that were tied together, pulled apart, and recombined until the architect reached the desired level of value delivery. SDM’s class in system architecture provides a number of useful constructs for generating, assessing, and selecting such combinations to keep the problem tractable and to prevent a geometrical explosion in the total number of potential architectures that have to be evaluated.
At this point, the architect has arrived at an enterprise architecture with a high degree of confidence that it will
not only create the desired value, but will likely produce more value than a relatively large percentage of any alternative architectures that could be explored. This is a direct benefit of employing a rigorous methodology.
The last remaining task is perhaps the most straightforward from a theory perspective, but also the most difficult to implement effectively. The problem is going from the current state of the enterprise to the desired one articulated by the new enterprise architecture.
Fortunately, LAI has done a tremendous amount of research on the topic of enterprise transformation. To
briefly summarize its findings, the enterprise architect must now enter into intensive discussion and dialogue with the enterprise stakeholders to assess the appropriate path forward. The first order of business is to return to the key stakeholders and ensure that the value delivery needs are still valid and the proposed architecture will meet those needs. Senior leadership in each key stakeholder organization needs not only to
understand the nature of the proposed enterprise architecture, but to become an advocate—looking for ways to arrive at the desired end-state themselves. This is why it is so important to maintain continuous stakeholder engagement throughout the enterprise architecting process.
If senior leadership is on board, the remaining step is execution. This is where theory truly leaves off, and real work has to take place in order to build realizable plans for fundamental enterprise transformation. This task can become very involved quite quickly.
|Figure 2. UAS Transformation Roadmap|
The fourth and final article in this series will describe the key lessons learned from this research and how the integration of the knowledge generated by each of the organizations involved ultimately provided a way ahead on an exceedingly complex socio-technical problem of significant future potential—integrated UAS operations in the National Airspace System.