How to Do Architecture Development that Benefits Programs and Pursuits 

Introduction

• Have you ever wondered if we could do a better job of leveraging architecture activities to contribute to the success of programs and pursuits?
• Why do architecture activities fail to provide much benefit? How can programs do architecture analysis without reaping a return?
• How can architecture activities have a significant benefit to programs and pursuits? How can programs and pursuits leverage architecture analysis to greater effect?

What was the most common factor in low performing architecture efforts?

• Lack of proper personnel?
• Lack of adequate training?
• Lack of adequate tools?

None of those! We didn’t have people doing things that added value.

Why They Fail

1. What can happen without architecture analysis?

Developing complex systems without understanding the implications of the architecture is a high risk activity.

Up front architecture analysis provides an opportunity to discover and mitigate risks before they impact development.

2. What you don’t see might sink you.

“The wise man knows he doesn’t know.  The fool doesn’t know he doesn’t know.” – Lao Tau

Focus architecture activities on uncovering what you don’t know, not on detailing what you already know. Answering the Zachman Framework™ interrogatives from relevant perspectives is one way to find out what you know and what you don’t.

3. The fallacy of single view architecture analysis.

An auto mechanic wouldn’t use a hammer as their only tool.

Multiple architecture views are necessary to capture all aspects of a system architecture.

4. Get to know the devil.

• The devil is in the details.
• Better the devil you know than the devil you don’t.
• Find out where the devil is and get to know him.

An architecture that over simplifies the system may be hiding details that will become issues later. Conversely, an architecture that goes into too much detail may be doing extra work and eliminating needed future options.

There are many complexities that need to be addressed by system architecture:

• Availability – Redundancy, fault detection and recovery
• Modifiability – Modularity and standardization
• Cardinality – Multiple elements which may be local or distributed and similar or different 
• Performance – Resource management and scheduling
• Security – Authentication, intrusion detection, auditing, etc.
• Testability – Internal monitoring, logging, etc.

5. (Not) the same as last time.

There is a natural tendency to pick the same approach we used last time. We need to overcome this bias. Overcoming that bias is like degaussing a magnetic field.

Reasons why the previous solution may not be the best solution this time:

• Technology changes
• Program unique constraints
• Customer differences

“Just because it worked in the past there’s no guarantee that it will work now or in the future” – Kenneth L. Cureton

Biases can be overcome by consciously looking for alternatives even when it seems like there are none. Experts recommend identifying at least three alternatives to address critical issues.

How To Succeed

6. Architecture planning, architect for a reason.

Developing an architecture is like developing a system.

• Do you know what the objectives are?
• Have you scoped the effort?
• Do you have a plan?

The primary goal of architecture planning is to set the work to the appropriate level. Do no more and no less than what is necessary to address the specific needs of this program or pursuit.

Have the following at this stage:

• Architecture Project Identification
• Architecture Scope including views and products to be developed
• Architecture Purpose and Viewpoint
• Tasking for architecture project
• Projected development effort
• Anticipated linkage to other architectures
• Software tools and formats to be used

7. Developing a good system architecture starts with understanding.

Don’t be so focused on the features and capabilities of products or established system boundaries that we miss the customer’s real needs in the context of their operational and support environments.

• What operations does the system need to support?
• What is the operating environment?
• What are the real requirements and constraints?

What seemed okay in the lab may not be so great in the heat of battle, or when the user has to give up something else to carry it, or when it is difficult to get needed support or supplies.

8. Find the simplest solution that addresses all requirements and constraints.

“Everything should be made as simple as possible, but not simpler.”

Don’t just consider material (e.g. new system) solutions.

Can objectives be met through changes in doctrine, organization, training, leadership and education or facilities?

Understand how new or changed systems impact doctrine, organization, training, leadership and education and facilities.

9. Use modeling and simulation to validate the architecture.

The nature of complex systems are often such that there are too many interactions between elements to be able to understand the behavior as simply the aggregate of the behaviors of the elements. This emergent behavior of complex architectures sometimes can only be fully explored through modeling and simulation. There are many types of models and simulations to address different system issues.

“All models are wrong, some are useful.” – George Box, industrial statistician

• Begin with the end in mind – Know what architecture questions you are trying to answer and how you are going to evaluate the data
• Use models appropriate to the questions to be answered – Every model has limitations in what it can represent and over what range of trade space it can provide useful information
• Develop simulation scenarios that exercise the architecture attributes necessary to answer the questions – Think about what you are trying to measure and how the scenarios exercise the model to produce those measurements
• Use modeling and simulation results appropriately for the capabilities of the model – Models can often provide valid comparisons between alternatives even when they cannot provide accurate absolute quantitative results

10. Make sure the implementation is consistent with the architecture.

Architecting doesn’t end when the implementation starts.

• Communication and Consensus – Make sure all affected organizations understand and are supporting architecture decisions
• Requirements Linkage – Significant aspects of the architecture should be reflected in the requirements
• Standards – The architecture should produce technical standards that guide implementation decisions
• Change Management – Changes that impact the architecture or compliance with the architecture should be reflected in architecture products and validated through architecture analysis

Summary

Davies’ Ten Commandments of Successful Architecture Development:

• Don’ts:
  1. Don’t build complex systems without using architecture analysis to mitigate risk.
  2. Don’t focus efforts on documenting what you already know.
  3. Don’t rely on a single view as the whole architecture analysis.
  4. Don’t simplify out complexities that the architecture needs to address.
  5. Don’t assume what you built last time is the right solution this time.
• Dos:
  6. Develop an architecture plan tailored to the needs of the program or pursuit.
  7. Work to discover unwritten requirements and constraints.
  8. Find the simplest solution that addresses all requirements and constraints.
  9. Use modeling and simulation to validate the architecture.
  10. Institute a governance process to make sure the implementation adheres to the architecture.