{'fraction_non_alphanumeric': 0.0222972972972973, 'fraction_numerical': 0.002027027027027027, 'mean_word_length': 5.553097345132743, 'pattern_counts': {'":': 0, '<': 0, '<?xml version=': 0, '>': 0, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
8.3.3 Use of Architecture for Engineering Systems; The Good, The Bad, and The Ugly

Many programs have created architectures yet they have not been effective in producing viable results. The primary reason for this the ineffectiveness is derived from how programs are managed. While System Engineers perform engineering activities by developing artifacts; the complex relationships among engineering processes, the final products, and the creation of systems that meet customer expectations have not been well‐managed. Resolving this issue can be difficult. Even though Systems Engineering processes can provide guidance in Engineering Systems, it requires customer support and effort to make architecture actionable. To be successful in providing solutions, the Systems Engineer must apply Systems Engineering concepts to the customer's problems by educating the customer and assisting them to drive the system development effort. The author will present examples of “The Good,” “The Bad,” and “The Ugly” he has observed in U.S. Government Federal Agency and Department of Defense programs as it relates to the application of architectural engineering. Based on these tendencies, recommendations are presented to improve architectural effectiveness by urging a return to fundamental systems engineering principles and insuring that the customer is a solid stakeholder in upholding, supervising, and executing the architecture as an essential element of the new system or program.