j
Shelley A. Hayes
Sysm Design and Management, January 2000
Professor Ed Crawley
Head of Aeronautics and A utics Department
Thomas A. Kochan
LFM/SDM Co-Director
George M. Bunker Professor of Management
MASSACHUSETTS INSTITUTE
OF TECHNOLOGY
JAN 2 0 M

Abstract
This thesis examines the issue of contrasting time scales impacting product-line development strategy. A product line development strategy involves deriving products, periodically over time, from a platform or set of platforms. The goal is to optimize long-term gain for the business and a plan is created to articulate the means of achieving the goal. However, as the plan is executed, focus on short-term gain causes the product development team to vector off this long-term plan.
The result is that the current product and supporting platform release in development is optimized at the expense of future products. This divergence from the original plan precipitates as higher costs resulting from rework, shortened platform lifetimes, and lost opportunities in market coverage due to future product delays.
This thesis examines the root causes of divergence from the long-term prescribed platform strategy and architecture on an information technology program. It proposes several methods for mitigation based on data from four product projects, which are part of a product-line program. A unique method of analysis was used, analyzing decisions in the Production Development Process as a means to understand the process, the impacts, and provide insight. Over 3000 data points and 150 decisions were gathered and analyzed as well as project collateral and processes.
The data supported and quantified the divergence of the current products from the strategic plan product-line plan and architecture. The root causes were centered on the trade-off between shortterm and long-term priority focus as well as poor decision-making processes. Half the decisions revisited on the projects were from poor decision-making process, which exasperates the long-term, short-term trade-off issue. Specific opportunities to maintain long-term, strategic plan focus were proposed in the categories of platform architecture and management, minimizing rework, and program management. The research approach, analysis and recommendations were based on a subset of SDM learning from Systems Architecture, System Engineering, Program Management,
Marketing, and Total Quality of Management.
Author: Shelley A. Hayes
Advisor: Professor Ed Crawley
Title:
Date:
Maintaining Architecture Robustness and Platform Focus in an Incremental
Development Environment
December 28, 1999

This document provides an opportunity to publish an acknowledgement and thank people supporting me during the thesis activity and during my 2-year program at MIT. The English language is incapable media to fully capture the depth of my appreciation for these people, especially my husband Jeff, however I offer the attempt below and hope it is acceptable.
First and foremost I thank my husband Jeff for providing a bottomless buffer of task and emotional support during this program while he has been full-steam keeping his lab going, serving on committees, and working on tenure. He never failed to place my needs above his own.
Furthermore, I especially admire him for the incentive and guidance he provides through his example of excellence in work, kindness in spirit and playfulness of heart.
I firmly believe that God sets our potential and our parents program our course. Every decision and action we make is rooted in what we did and did not learn as a child. Therefore, I am eternally grateful to my parents, Robert and Linda Almond for the lessons and love provided to me as a child and as an adult. In addition their unfailing support has continued to be a gracious gift.
As always, no ask was too great, including flying to Rochester to help with the kids for months at a time while I was in Boston.
My SDM cohorts have been the quintessence and joy of the program for me. I admire them as people and professionals. I cherish the friendship and lessons they have bestowed upon me.
For those in my professional life who have mentored and helped me in some way, my thanks and admiration are with you. In light that you did this on top of extremely stressful positions, in the midst of overly tasked days, and without any reward, these feats are exemplary of the level of integrity I admire in you.
Working with Professor Crawley has been a humbling and exhilarating experience. He always gives freely of his brilliance and is encouraging in every way. It has been a rare experience to be in the presence of someone very few of us could grow up to be. I am thankful for his guidance and kindness in accepting me as one of his thesis students. His assistant, Kathryn "squeaky-wheel-byproxy" Fischer is great fun and I appreciate her extra efforts in supporting a long distance relationship.
Last but certainly not least, I thank my daughters, Stephanie and Chloe for not minding too much that I've been spending so much time in the den over the past 2 years. Your smiles and witty comments have made my time as a "Masters In Training"' fly by.
'Definition of M.I.T. formed by Stephanie Hayes, summer 1999
3

Chapter 1 Introduction
Background
Problem Statement
Opportunities and Improvements Envisioned Possible
Research Approach
Research Program
Terminology
Chapter 2 Program and Projects Context
Product Development Process Phases
Phase 0 Define Product Family Mission
Phase Ia Define Architecture and Product Delivery Plan
Phase
Exit Refine Architecture and Plan
Phase 2 Define High-Level Design
Phase 3 Subsystem Detail Design and Build
Phase 4 Integration and Pilot
Phase 5 Launch
Phase 6 Maintain
Organizational Structure and Roles
Architecture Deliverables
Intangible Deliverables
Tangible Deliverables
Product Family Architecture
Goal/Needs
Corporate Drivers
Functional Chunks and Interfaces
Product 7 Back Office
Goal/Needs
Functional Chunks and Interfaces
Product 8 Relationship Management
Goal/Needs
Functional Chunks and Interfaces
Product 3 TeleSales Second Increment
Goal/Needs
Functional Chunks and Interfaces
Product
Electronic Business
Goal/Needs
Functional Chunks and Interfaces
The Architecting Process Provides an Environment to Study the Problem
Process and Balance of Short-term and Long-term Benefits
Remaking of Decisions
Natural PDP Process Contains Unavoidable Remaking of Decisions
The Process Can Contain Unnecessary Decision Recycling
Indications that the Problem is Available for Study
Configuration and Identification of Decision
4
7
7
7
7
7
11
8
9
14
15
15
16
19
20
20
20
19
19
18
18
18
18
17
18
18
16
16
16
21
21
22
22
23
11
12
12
13
14
14
14
14
14
23
26

Decision-making Roles _-
Source of Decision, Architecture Influence
Impact of Decision
Decision Revisiting and Remaking _29
Chapter 4 Data Summaries and Key Points
Decision Making Role
Description of Roles by Function Data
Interpretation of Roles by Function Data
26
_ 27
28
Categories of Architecture Influence
Description of Influence Category Data
Interpretation of Influence Category Data
Impact of Decision on Scope, Schedule, Architecture, and Costs
Description of Impact Decomposition Data
Interpretation of Impact Decomposition Data
Description of Influence and Impact Relationship Data
Interpretation of Impact and Influence Data
Revisiting Decisions
Description of Causes of Revisits Data
Interpretation of Causes of Revisits Data
Description of Impact from Revisiting Decisions Data
Interpretation of Impact from Revisiting Decisions Data
Description
Predictability Data
Interpretation of Predictability Data
Description Necessity of Decision data
Interpretation of Necessity of Decision Data
Chapter 5 Conclusions
Summary of Major Findings
Cycling during PDP between Short-term Gains and Long-term Plan is Significant
There is Avoidable Rework
Timing of Decisions is Reducing Flexibility and Creating Avoidable Rework
PDP Team is re-Storming and re-Forming at Each Phase of the PDP
Opportunities for Improvement
Formally Rerun the PDP Phases
Provide a Buffer for Environmental Change and Impact
Drive the Unknowns Out of the System Early
Reduce Platform Deoptimization and Rework by Making the Trade-offs Measurable
Reduce Platform Deoptimization through a Platform-oriented Organizational Structure and Strategy 55
Engineer the Teams across the PDP Life Cycle 57
Improve Project Degrees of Freedom and Product Quality 57
52
52
52
53
53
50
50
50
51
51
51
35
35
38
39
39
39
41
42
44
44
44
46
46
48
48
49
49
31
31
31
32
Further Research
Extended Recording Time
Study Other Programs
References
Exhibits
Data Gathering Tool and Content
58
58
58
59
60
60
5

Table of Figures
Figure 1 Product Development Process Platforms are developed as part of the product
Figure 2 Timeline of Product Family and Product Projects Used in Study (red checkmark indicates product projects studied)
Figure 3 Input/Outpu/Transformation Diagram
Phase
and
Figure 4 Organizational Structure
Figure 5 Product Family Architecture
Figure 6 Product 7 Back office Delivery Scope in Product Family Architecture
11
12
13
Figure 7 Product 8 Relationship Management Delivery Scope in Product Family Architecture 19
Figure 8 Product 3, TeleSales Delivery Scope in Product Family Architecture
Figure 9 Product
Electronic Business Delivery Scope in Product Family Architecture
Figure 10 Short-term and Long-term Balance
Figure 11 Diagram of decision-making activity in the PDP
Figure 12 User Interface for Data Gathering Tool
20
Figure 13 Percentage of Decisions Recorded by PDP Phase
Figure 14 Decision Roles by Team Member Function - All PDP Phase
Figure 15 Decision Roles by Team Member Function for PDP Phase 1, 2, and 3
31
33
34
Figure 16 Percentage of Decisions the Architect is Decision Maker, Facilitator, Must Buy-in, Will Act on, or Is Not
Involved in the Decision 35
Figure 17 Type of Decision, Main Decision Topic Percentage by Phase of PDP 36
Figure 18 Decision Topic Percentage by Phase of Total Decisions 36
Figure 19 Percentage of Decisions by Influence Category for each Product
Figure 20 Decision Influence Percentages for Projects completing phases 1 through 3
38
38
Figure 21 Impact of Decisions on Scope, Schedule, Architecture (Product/Platform), and Costs for All Products,
All PDP Phases 40
Figure 22 Impact of Decisions on Scope, Schedule, Architecture (Product/Platform), and Costs for All Products for Refine Architecture and Plan Phase
Figure 24 Impact of Decisions on Scope, Schedule, Architecture (Product/Platform), and Costs for All Products, for Build and Test
40
Figure 23 Impact of Decisions on Scope, Schedule, Architecture (Product/Platform), and Costs for All Products, for Subsystem Design 41
41
Figure 25 The Impact that Corporate/Business Need Decisions have on Scope, Schedule, Architecture
(Product/Platform), and Costs. 42
Figure 26 The Impact that User Function Decisions have on Scope, Schedule, Architecture (Product/Platform), and
Costs. 43
Figure 27 The Impact that System Decisions have on Scope, Schedule, Architecture (Product/Platform), and Costs.
21
22
23
26
Figure 28 Decisions Revisited Counts
Figure 29 PDP Phase Distance between Original Decision and Remake
Figure 30 Reasons for Revisiting Decisions and Percentage of Occurrence
Figure 31 Architecture Impact of Revisiting the Decision.
Figure 32 Rework Impact of Revisiting the Decision
Figure 33 The Architect's Estimate of the Probability the Decision Will Change in the Future.
Figure 34 The Percentage of Time the Decision is Make out of Necessity or Convenience.
Figure 35 Platform Architecture Aligned Organization and Plan
46
47
47
43
45
45
48
49
56
15
17
18
6

The goal of modem product development is to deliver products before the competition. The market dynamics require many different lines of products with frequent releases. This adds significant pressure on the product development teams and process to continually upgrade the products with rich feature/functions as well as continue to simultaneously improve performance and price over time.
The strategy to meet this goal has been a product-line strategy and platform-based architecture.
A platform-based architecture enables a line of products to leverage common elements. The features that are common across many products and that enable a vector of differentiation are allocated to the platform(s). The features that are specific to a market segment are allocated to product specific components for that market segment. Multiple products are delivered quickly and frequently by leveraging the platforms and adding market and product specific components.
The business defines the market segments and the timing of product releases. The product development plan reflects the business and market attack priorities by planning the series of platform and product releases. The architecture defines the structure of the platform and product chunks, interfaces, and feature/functions allocated to the chunks.
The strategy has several difficulties in implementation that negatively affect cost and delivery deadlines. As the plan is executed, focus on short-term gain causes the product development team to vector off the long-term, strategic plan. The architecture and design adaptability deteriorates as interface complexity increases and the functional decomposition looses encapsulation properties. Functions span previously encapsulated application chunks and tightly coupled relationships are introduced. Complexity increases and flexibility decreases.
The result is that the current product and supporting platform releases are optimized at the expense of future products. Higher costs are incurred due to the rework to migrate the implementation back to the specification and adaptable architecture supporting all products. The platforms have a shorter lifetime and must be retired earlier than the planned benefits are fully received. The business loses opportunities in market coverage due to delays in future product releases.
It is the goal of this research to understand the architecture process and recommend methods, tools and techniques to improve the balance in the trade-offs between long-term and short-term priorities. The expectation is that methods and tools can be defined to reduce the gap between the product-platform plan and the execution. The primary methods of interest will increase the robustness of the architecture implementation, which is the ability to absorb latent requirements with minimal rework and structure impact. The removal of rework and structure changes, resulting from the gap, will remove costs and improve delivery deadlines achieved for the product family.
The research approach is to understand the product development process and identify the causes of the deviation from the long-term plan and architecture specification. The method of analysis
7

is to examine the decisions made during the Production Development Process (PDP) and understand the decision's impact by examining the product deliverables. The decisions are examined from the perspectives of who is involved in the decision and what function they perform, what is the influence source of the decision, what is the impact of the decision, and what decisions are revisited and the impact. Upon understanding what decisions affect the architecture robustness and how they were made, methods and tools can be designed to improve the architecture robustness achieved and long-term plan alignment. The research must be done on a program implementing a product-line strategy and platform-based architecture.
The decision-making roles are divided into four groups and the PDP team functions filling the role is captured. The groups are decision-maker or who is accountable for the decision, must buy-in or who is responsible that the decision is aligned with success, facilitator or who frames the decision information and facilitates the group reaching consensus, and actors or the groups that must take action as a result of the decision being made. Gathering this information may help understand the process and relate the process to the impacts. Understanding the teamdynamics, the stability, and how PDP team functions are involved in the decision-making process will help analyze the process for its impact to staying on plan and opportunities for improvement in efficiency.
The source of the decision or influence on the product, plan and architecture is identified from 4 perspectives or topics. The decision may be native to Corporate or Business Needs, User
Functionality, Standards or Regulations, and/or Architecture Structure and Implementation.
Understanding the sources may allow the relationship of source to impact. If one of the sources creates the greatest number of decisions affecting the divergence from the long-term plan and strategic architecture implementation, then this will suggest that greater focus should be put on these decisions.
The impact of the decision on aligning to the strategic architecture specification and to the amount of rework caused is captured to help calibrate where improvements will be most beneficial. Placing additional process, method, or tools in place may require resource effort, training, and additional task duration time. Relating impact will allow recommendations to be inserted at a limited scope rather than ubiquitously across the entire project or program. If there isn't a compensating return on time or resources or if there is cultural change to be managed, the process, method, or tools cannot be inserted all at once across the project.
Revisiting decisions is examined. Revisiting decisions is done under 2 categories, as part of the natural process of discovery and convergence in a PDP, and also as a result of broken decisionmaking processes. These decisions are unavoidable and avoidable, respectively.
The research was performed on software dominated systems, specifically Information
Technology business systems. Over 3000 data points across 4 major product development projects and over 150 decisions were gathered and analyzed. The 4 projects belonged to a program implementing product-line strategy and platform architecture. A tool to facilitate data collection was created and provided to the lead architect assigned to each of the projects. This eased the burden of data entry and forced a workflow to improve the quality of the data gathered. Other subjective project collateral and processes were examined as well.
Multiple projects, platforms and products or applications are being developed and launched in parallel on the program. The projects and products have different development timelines and launch dates. There are 200 core product development team members responsible for the
8

development of new products/applications and platforms. These core members rely on extended groups for some system components and process task such as launch activities
The architecture and strategy group is a central function and provides varying levels of support on different projects. On the projects and products studied for this thesis, the group is fully engaged with a lead architect assigned to the project that produces or facilitates the production of the architecture deliverables. There are other products and applications in which the group has oversight or review responsibility.
There is a significant change management and re-engineering challenge for the program. The development team and organization must be migrated from legacy work and business processes as well as technologies to a new architecture and set of processes. The legacy is 5 to 40 years old.
There is a high rate of technology change and high rate of business goals and process change.
The organization is flat with hybrid integrated project teams and a functional team structure.
There are both matrix and non-matrix managed individuals on the team.
The following list of terms is provided to synchronize the reader with the author.
Architecting is fundamentally an act of synthesis. Synonymous with synthesis (noun) is: building a whole (meaning), creation, combination, formation, integration, formation, construction, arrangement, and aggregation. Synonymous with synthesize (verb) is: combine parts into a whole (meaning), fuse, harmonize, blend, coalesce, merge/unit.
Throughout the product development process the architect synthesizes or integrates the whole to achieve emergent properties of a system that satisfies the voice of the customer. The needs of each subsystem are sub-optimized as they are integrated into the larger system and larger goal.
A system can be anything composed of more than one part providing greater function than the sum of the separate parts. Therefore a large part of the architecting task is decision-making, specifically trading-off multiple needs, requirements, and goals to optimize the whole.
Architecting has some of the greatest impact on eventual success, factors in the greatest number of considerations is not primarily concerned with detailed or quantitative data, and is a Choosewatch-choose process2
A System is a set of functional elements (subsystems, modules, components) and interfaces brought together to satisfy user needs. The system function is greater than the sum of its parts.
Architecture is the structure of the system elements in terms of functional encapsulations or chunks or groups, interfaces, and performance/behavior. Expressed in terms of concept, logical functional elements and interfaces, physical configuration/instantiation, and principles/heuristics.
A Subsystem is a set of functional elements and interfaces organized to satisfy a system purpose or subset of user needs within a larger system context.
A Platform is the set of architectural rules and product platform elements that enables the planned product offerings and defines the basic value proposition, competitive differentiation,
2 Ed Crawley, System Architecting course lecture, 1998, 1999
9

capabilities, cost structure, and life cycle of the product offerings. Platforms are defined by one or more platform elements that serve as a foundation for the platform.
Platform Elements are subsystems (hardware and software), processes and process enablers that implement the defining features or technology within a solution offering and within a platform. Product platform elements are typically small in number, critical, and reused within the set of product offerings. They require high-investment, long lead-time, and require significant management attention. Product platform elements are a subset of the overall technology set necessary to develop the product offerings. Product platform elements may be reused across multiple product platforms. While they are a subset of the overall technology set necessary to develop the solution offerings, the Vector of Differentiation would be impossible to implement without them. Platform elements may be specific tools that are used across multiple offerings.
Product is a marketplace offering including the system or application, services, and any other packaging offered to a customer.
Product-line Strategy consists of providing a series of individual products that are part of a product line and the product lines are derived from a platform or set of platforms that embody the vectors of differentiation for the company in the market place 3
.
Vector of Differentiation is differentiation achieved through vectors instead of individual points. Vectors are themes such as "ease of use" 4
.
Design is the next level detail of architecture. It embodies the model of the physical instantiation of the architecture form.
System Engineering makes the architecture work. The system is validated to satisfy the goal, function and need of the customer, to have followed the architecture design and design intent, and to meet performance specifications. This is done as the system moves through the product development process, evolving from architecture definition to delivery.
3
Summarized from Product Strategy for High-Technology Companies, Michael E. McGrath, 1995
4 Summarized from Product Strategy for High-Technology Companies, Michael E. McGrath, 1995
10

The product development process used is based on a platform-based product family concept.
This process is the standard Product Development Process for the company however this program's implementation revisits phase 1 for each product release. Therefore the process shown divides phase 1 into la and lb, reflecting the program tailoring and implementation. All programs are required to follow the company's standard process although each program can tailor the process at the detail level so this re-execution of phase lb is acceptable.
The program studied is interesting due to the level of change management involved and the ability to launch viable products with only 5% of the architecture implemented. This is the cause for revisiting phase 1. The architecture and plans for such a large scope would take years to finish if done in a waterfall fashion. Therefore a high-level market, plan, and architecture is done for the program and then incrementally drilled to the detail required to enter design as needed for each product scope.
The tailored PDP process in use on the program is shown in Figure 1. The process is designed to encompass all tasks from product vision, mission, and market strategy through maintenance.
The platforms are developed and managed as subsystems within the product delivery team utilizing the majority of the functionality. The next chapter defines the products and the platforms in development that are studied in this thesis.
Product 1
1b. Refine
Figunr P hc Deelnt
Pln & Plan Lee
3. Subsystem .Integration
P Design ein
& Build
&
Pilot
Praduc 2
5. Launch
Refine
& Plan tl ben
Subsystem
& Build
Integration
&
Pilot p
**t"eae
6. Maintain
Launch Maintain
Product N4-1
Refine eIDefine High Subsyste
ArchitecturevlDsg Design
& Plan Lee ein & Build
Product N
Refine
Architecture H&g
& Plan Lee ein lntegration,.
&
Pilot
Subsystem lntegration,,
Desinn
& Build Pilot
Figure I Product Development Process - Platforms are developed as part of the product
The projects studied compose a family of projects in an incremental, highly parallel family of IT business applications. The mission, market, architecture and strategy were defined less than 4 years ago, and 3 products have subsequently been launched. The product program/projects
11

being studied are 4 out of 7 currently in the "Refine Architecture & Plan" through "Subsystem
Design and Build" phases. This is illustrated in Figure 2.
There has been major geographic and line of business reorganizations affecting the program boundaries and priorities since the original Product Mission and Strategy, Architecture, and
Product Family Plan. The architecture and technology assumptions and strategies have remained relatively robust against these changes. The original architecture form has continued to grant the functions required.
_________________Maintenance
Product 33 eeSlsScn nrmn
...
roduct 7 -- -
-..........
Product 109
Product 1 - usns
Time (years) Data Sample
Figure 2 Timeline of Product Family and Product Projects Used in Study (red checkmark indicates product projects studied)
This phase of the product development process established the voice of the customer and the product family vector of differentiation. The corporate strategy, key market and business drivers are considered and are part of the strategy. However, the product mission addresses the market only.
The goal of this phase is to define the strategy for fulfilling the product family mission. This involves segmenting the market, selecting the architecture concept and form, and defining the sequence of products to be delivered (Product Delivery Plan). The voice of the customer is driven down to further detail to goals and function statements. The business needs are well articulated and the architecture concepts are examined. The selected architecture form is
12

designed including major chunks, interfaces, performance deadlines, life cycle, and principles.
Platforms and products are identified. As discussed earlier, the architecture structure for this program is sufficient to validate the concept but is not a enough detail to begin the Phase 2
Design. The development organization is designed, aligned with the architecture form. An input/output/transformation diagram illustrating Phase 0 and Phase 1 is shown in Figure 3.
The details of the inputs for this phase and the "Define Mission" phase are shown in Figure 3.
Also the primary methods invoked to transform these inputs into the deliverables of the phase are shown. These methods may be used in part or in entirety depending on the priorities of the project in the areas of speed and risk.
The exit of phase one is accomplished by completing the next level of detail of architecture and planning for a product delivery. The portions of the architecture required to deliver the product are refined down two or three levels of detail from the la phase so that the functional chunks and interfaces are clearly identified. The goal is to have confidence that all the interfaces are identified and the goal and size of each interface is understood. The detailed specification of the interfaces and functionality comes in the next phase. A level plans for all phases and a business case is developed for the product. Detail, B and C level plans are developed for the next phase, high level design.
Key Business Drivers
*Customer Segments
Custome Demographics
Marke Attesk
-Competitie Ervironment System
Needs
*User Segments & Demographics
*Desired State Business Process
-Core Competencies
*Structure aLoad
Current stateStarting Point eBusiness Process eSystem
-Core Competencies
Decisins
ID Key Business Goals/Requirements
System Scope
Technology Options and Selections
Arch Form and Build Phasing
Synthesis/Optimize opposites/trade-offs
-natural build order vs schedule desires ohorizon/iong-term vs first phase/subset optimization erework vs first release speed
-organization capabilities, new technology absorption eOptimize solution
strategy complementary asset analysis, porter s-curve analysis esystem compledty, adaptabilityexaminations
Time, Budget-
Legacy
Infrastructure Capabilities
Downstream Needs, Capability, Delivery
Architect Capabilities
Phase
U a
Product Mssion product Delivery Plan
Platform Delivery Plan
*Arch Concept & Form
-Build Strategy
* Lifecycle (lineage, heritage, retirement management)
Principles
Phasel
*lnitial QFD- Level 0 & 1
*Function
1
Behavior
*Arch Form Decomposition eInteface Definition and flow
*Ufecycle
*System and Subsystem
Run-time deadlines
*Design Recommendations
*Organizational Design
Selection
Figure 3 Input/Outpu/Transformation Diagram of Phase 0 and 1
13

The purpose of this phase is to design each of the architecture chunks and specify in greater detail the interfaces. Run-time performance is validated via paper models and technology readiness experiments are performed to increase confidence. The chunk designs are inspected for system integrity of product and the surrounding system (e.g. platform integrity maintained for future products, interfaces to peer products/applications).
Validation and verification plans are made. Test cases are identified but not fully defined.
The architecture chunks are allocated to the development organization.
The development groups perform the detail design of each chunk, perform development, and complete unit testing. The integration test team fully develops the test cases and readies an integrated test environment. Beta and Pilot plans are defined.
The system chunks are brought together for full system integration testing. A pilot in a portion of the production market is performed or a conference room simulation with market customers is performed.
The product is delivered to the target market segments as planned. This can be as slow or as accelerated as the project determines. The most common case is a very aggressive rollout if no major issues have been discovered in the previous phase pilot.
Additional functions and user populations are added to the product scope. These can be substantial features and not just bug fixes. Substantial changes in essence execute phases lb through 6.
The products and platform strategy, architecture, development, and launch functions hard line report to the Corporate Technology Officer for Information Technology, as shown in Figure 4.
There is dotted line reporting to several marketing and sales organizations, finance, and manufacturing. Subsystem development is both internal and external supplier provided. There is a core Product Family Strategy and Architecture group providing the architects and system engineers for the product and platform development projects. There is a Corporate IT
Architecture group that provides regulations in the form of preferred technologies, architecture patterns (especially in the area of security), and vendors to all the programs. The Product
Family Core Strategy and Architecture group follows these regulations.
The product manager (or platform manager) has responsibility for development, integration, launch and marketing/user functionality. A lead architect and several functionally deep architects are assigned to support the project. System engineers may or may not be assigned
14

from the strategy and architecture group due to resource limitations. When a system engineer is not available, the task is divided between the architects and product development leads.
Corporate
Technology
Officer
Senior VP
CEO and Staff
Business
Operations
Senior VP
Business
Operations
Senior VP
Other
Technology
Officers op
Geographic
Technology nfice
Global, Line of
Business Technolat
Officer
Corporate
Technology
Development
Europe Developing
Technology Markets
Officer Tech Officer
Core
Strategy &
Architecture
Communications r
Product 6 -
Product
Manager uct o uct Business age Function
Quality Office Maintenance y
System lopment
I Help Desk
System
Integration and
Verification
Project
Management and Quality
Bus ness
Function/
User Rep
Figure 4 Organizational Structure ssesrtgtoscesulgrwscalagsytmreiigteodsystem and paradigm
There are tangible and intangible contributions that the architect is responsible for delivering to the program office and project he/she is assigned to. The bulk of the intangible deliverables deal with facilitating decisions on the projects and decisions made by senior management.
Strategic Decision Facilitation pertains to researching the problem space, organizing the options including impact analysis, and facilitating the senior management staff decisioning process. Examples on this program are how new technology impacts business models and the system, strategy to successfully grow such a large system, retiring the old system and paradigm simultaneously, etc.
15

Project Manager, Technical Lead, Developer Council is provided through informal and formal design reviews and coaching sessions. The architect provides a "sounding board" for working through decisions.
Task Force Leadership is provided by the architect for expediting a solution to a critical problem. Examples of tasks are resolving elusive system problems/defects, re-engineering development processes to improve speed and quality, etc.
Except for the Product Delivery Plan, which is worked in Phase 1, the deliverables are incrementally completed through progressive refinements throughout phase 1 and phase 2.
These deliverables are also revisited for each release.
The Product Delivery Plan summarizes the market and customer segments and summarizes the user profile and needs. The platforms are identified and products for each market segment are planned.
A Functional Decomposition and Applications Architecture shows the functional chunks of the system.
The Integration Architecture shows the major interfaces and information flows across the system chunks.
The Data Architecture specifies the structure, syntax, and semantics of the at rest data utilized within an application, the information flows, and the overall system model.
A Performance Model that allocates the run-time deadlines to the system and specifies a temporal view of the system.
A Physical Architecture shows the physical topology of the applications and data and the HW,
OS, and Network infrastructure.
Lifecycle Model shows the growth and end-of life strategy for the product or platform.
The Organizational Design and Vendor Selection maps the development organization to the system deliveries and development process functions.
Architecture Principles and Design Intent provide the guidelines for future system decisions and design patterns, heuristics, and practices to follow.
The business is reorganizing from a process silo model to an integrated process. This facilitates end to end (customer request to fulfillment) business process speed. The IT systems supporting the business processes must be transformed to facilitate the end-to-end operation and view.
The business transformation will enable double-digit revenue growth. Characteristics of the transformation include aspects of customer satisfaction, global view, different market approaches and focus, and expense reduction.
16

The current legacy systems are decades old and as a result have outlived their design life. The technologies are old and unsupportable, the designs are brittle, and the cost are escalating. The
Information Technology drivers are to reduce the total cost of ownership of the IT portfolio and increase overall architecture and system adaptibility (e.g. Easily upgradable, Accurate, Timely,
Comprehensive, Consistent, Robust, Easy to Use, Easy to Access, 24*7 Availability).
The IT strategy for achieving these goals is to reduce the complexity and redundancy by migrating to a set of purchased commercial off-the-shelf packages which leverage the industry investments and provide a base of platforms from which business applications and products can be quickly delivered.
The products/applications are based on a set of platforms as shown in Figure 5. Each platform is a substantial set of application feature/functions embedding business logic and the persistent data associated. There is a platform whose purpose is to provide a common integration backplane. This platform reduces the interface complexity by isolating communications between the application platforms. The desired state is that these applications are Commercial off-the-shelf (COTS) packages purchased from industry suppliers and configured to support the specific business functions of the Corporation. There are several platform elements that compose the platform and one supplier may not provide all elements. In most cases, there are 3-
6 suppliers in current state, and it is expected that in the future, the number of suppliers will decrease and a single supplier will provide more functionality (larger platform elements).
Figure 5 Product Family Architecture
The products/applications are derived off one or more of the platforms using portions of the platform elements and/or subsets of features/functions. Platform function growth is prioritized
by product releases. Portions of platform functionality is implemented and released to support incremental product/application delivery.
17

Provide a system to support all the business processes and multiple user groups in the Order,
Manufacturing, Fulfillment, Delivery, Billing, and Collections area of the business. Provide a platform that is aligned with industry technology trends to enable sustained growth and technology absorption.
Green indicates functionality implemented in release,
Gray denotes functionality not implemented.
Figure 6 Product 7 Back office Delivery Scope in Product Family Architecture
Provide a system to support understanding and managing the customer relationship throughout the enterprise to "enterprises can better serve their customers and further increase their chances of retaining them"
5
. This includes market modeling and management, campaign management, customer interaction management across all touchpoints, and stewardship of market and customer information.
The major chunks of functionality are
* Analytic, Reporting, Dashboard environment
* Market and customer models and reports
5 Vendor Selection For Sales Organizations: An Uncertain Market, GartnerGroup, W. Close, R. Desisto, J.
Golterman, M. Maoz, December 1998
18

.
Market and Campaign construction and simulation
* Selling channel configuration and customer and product mapping
" Customer information, interaction summary, relationship action indicators/triggers communication across all touchpoints and management interfaces
* Market Customer Information management including creation and distribution.
" Front-office and Back-office territory management including creation, communications, and rules processing
Green indicates functionality inplemented in release,
Gray denotes functionality not implemented.
Figure 7 Product 8 Relationship Management Delivery Scope in Product Family
Architecture
Aggressive expansion of telesales, telecoverage, and telemarketing to grow revenue and enhance productivity.
The TeleSales application decomposes to several subsystems and employs several technologies.
The scope of development thus far is shown in Figure 8. The platform applications have not been ready so the TeleSales releases thus far have used the legacy applications as a substituted.
19

Once the platforms are ready, there will be a set of rework to retrofit the interfaces and business semantics from legacy to the platforms.
Grewn indicates functionality implemented in release,
Gray denotes functionality not implemented.
Figure 8 Product 3, TeleSales Delivery Scope in Product Family Architecture
Support open market commerce on the World-Wide-Web and extranet business to major customers.
The Electronic business system application decomposes to several subsystems and employs several technologies. There is an Ebusiness platform from which the open market product/application and the extranet products are derived. This detail is not shown in the diagram. The scope of development thus far is shown in Figure 9. The platform applications have not been ready so the Electronic Business releases thus far have used the legacy applications as a substituted. Once the platforms are ready, there will be a set of rework to retrofit the interfaces and business semantics from legacy to the platforms.
20

Decision Support
Green indicates functionality inplemented in release,
Gray denotes functionality not irmplemented.
Figure 9 Product 11 Electronic Business Delivery Scope in Product Family Architecture
As stated before, the research approach is to understand the product development process and identify the causes of the deviation from the long-term plan and architecture specification. The method of analysis is to examine the decisions made during the Production Development
Process (PDP) and examine product deliverables to understand the decision's impact. The architecture process is fundamentally a decision making process with a focus on providing an architecture specification and implementation aligned with long-term strategy. Therefore, the high-level of decision-making activity and the content of the decisions makes it an ideal environment to apply the research method for the questions around long-term strategy and architecture divergence.
During the architecting process, multiple influences on the architecture are considered and decisions are made as to their priority. A primary activity is integrating opposites for the best possible results and making decisions about the architecture construct itself. Important for this thesis is the integration of long-term and short-term opposites. As each decision is made on a project, the team is deciding based on the short-term, current product and long-term, product family implications and tension as illustrated in Figure 10. The architect must facilitate the decision-making process by articulating the short-term and long-term implications to the architecture and primarily the platform structure. Based on these implications, the management team must decided what is the optimal balance to achieve across thousands of decisions made and what is the current balance. The tangible and intangible deliverables embody the decisions and their key meaning and therefore can be examined to determine level of balance.
21

:Deliver Current Product
-Optirruze Function for
-Deliver Platforms for
Product Line(s)
-Optimize Schedule and
,FamilIy
Figure 10 Short-term and Long-term Balance
During each phase of the Product Development Process, some decisions are made and some are held open. Decisions are revisited and re-made as a natural part of the process, which is
6 characterized as "Choose-watch-choose " by Eberhardt Rechtin. Also, decisions are unnecessarily re-made due to poor decision-making processes. Re-made decisions cause rework and in extreme cases, cause a backup in phases of the PDP.
This avoidable and unavoidable decision making and remaking process is illustrated in Figure
11. As shown, there is a natural re-cycling of decisions inside each phase of the PDP and not an area of primary concern. Once the decisions made converge on the set required to exit the phase, the project moves into the next phase set of decision-making. Decisions that were made in a previous phase, which get revisited in a subsequent phase, effectively reset that portion of the product development back to that previous phase. The project must then rework the phases from the reset phase to the current phase. This reset happens informally and unofficially most of the time and therefore outside the rigor of the product development process phase gate examination.
The unavoidable decision remakes are the decisions made because the only way to get smart enough is to proceed as part of the "Choose-watch-Choose" process. Also, decisions remade because the environment changes are considered unavoidable.
The decisions made because it is the only way to get smarter are revisited because as the decision is acted upon and the ease or difficulty and impacts of the decision are know. As the details of the benefits and drawbacks become known, an alternative previously deselected or deprioritized becomes more viable and therefore the decision is remade or changed. For example, an architecture decision on a technology to use may be more difficult to implement during the design or build phases. It takes moving into the design and build phase to discover this.
The decisions remade are remade due to environment changes such as technology innovations in the marketplace, industry or market changes, or changed user requirements and goals are also causes of unavoidable decision remakes. Reducing or damping the dynamics in an environment is difficult. It is difficult to foresee, and then more difficult to a priori compensate or control market dynamics caused by competitors or technology innovations desired by consumers.
2
Systems Architecting, Creating and Building Complex Systems, Eberhardt Rechtin, 1991
22

Even if the environment remained static, there would still be natural and unavoidable decision remaking due to the first case, the decisions made because the only way to get smarter is to move forward into the next phase(s) of the PDP. However, a high technology environment, which is the context of the program being studied, is not stable. New competitors with innovations in technology or manufacturing method frequently enter markets and cause rapid acceleration of an S-curve or create a new S-curve.
The decisions that are remade unnecessarily and can be avoided affect rework, costs, and time delays. These decisions should be removed from the product development process through process improvement and better communication. This thesis examined 3 categories of unnecessary decision remaking causes. These are decisions remade because of organizational memory loss of the original decision, original decision buy-in was not achieved, and/or easily obtainable information was not gathered when the original decision was made.
*Product
PA DfineRefine
Pa--&
A rchitectur= eieHg
Plan Lee ein
N
Subsystem Integration
Design &
& Build Pilot
Launch Maintai-
Decisions fDecisions to exit paere-visit
Decisions ma to exit phase remade requiring of OUS se
Figure 11 Diagram of decision-making activity in the PDP
The architecting process provides an environment to examine the decisions affecting the architecture and the nature of their impact against following the strategic, product line and platform plan. The intra and inter-phase decisions can be examined for the amount of alignment to the plan by examining product deliverables. The decision remakes that are a natural part of the product development and architecting process and cannot be avoided can be quantified as well as the decisions affecting the divergence from the architecture and strategy that are avoidably reworked.
There are several subjective indications that the issue of drifting off the strategic, long-term plan and architecture exists on the program for study and the resulting negative impacts to system robustness, cost, and schedule occur. Subjectively the architects on the projects are not satisfied that the strategic architecture is implemented with enough speed and that substantial incidences of alternative implementation exist. Considering the subjectivity of these statements and the tendency of the architects to naturally focus on discontinuity as part of their role, more
23

substantial evidence was considered. Examining the tangible artifacts of the architecture, there is harder evidence of long-term plan and architecture divergence in the implementations of the current products. The interface specifications are not followed and roughly 50% of the interfaces are specialized and/or tightly coupled. Also, the projects implemented redundant functionality in their products to get an amount of optimization for their product.
While there is recognition that perfect execution of the long-term plan and strategic architecture is not a reasonable goal, there is consensus among the architects that there are opportunities for improvement. The architects believe the plan and architecture transitions should continue to be aggressive in order to lead the organizational change required. This follows the guideline that
"The chief purpose of an adaptive enterprise architecture is to facilitate rapid change in business processes, the applications that enable those business processes, and the underlying technical infrastructure that runs the applications." 7
In addition, dividing the architecture transitions into smaller steps cannot be done without substantially increasing interface work to support the smaller transition.
The level of improvement is not known or defined in a quantitative way. Therefore, in addition to providing tools to mitigate the strategic architecture and plan divergence, the study should provide data useful in calibrating the expectations of long-term plan and strategic architecture alignment achievable in the transitions of the long-term plan.
7 Build for Business Innovation, Flexible, standarized enterprise architectures will product several IT benefits,
Roger Fournier, November, 1999
24

Chapter 3 Definition of Data Gathered
The data had to enable 2 primary areas of analysis of a product-line, platform architecture PDP.
The first area is to quantify the divergence from the strategic architecture and long term plan and the second area is to identify the sources or causes of divergence. A list of questions for each category was created. Then the data to be collected and the method of collection were designed.
To understand the divergence from the strategic architecture and long term plan, several questions to answer were postulated. What is the amount of divergence and the impact in rework and strategic architecture divergence? When is the divergence happening during the
PDP? Is the strategic architecture structure stable or are flaws found? What architecture influences are the sources of decisions?
Supposing that divergence occurs as decisions are made and remade in the PDP, the decisions were closely examined to answer the category of questions around sources of divergence. How often is the decision remake a result of the "choose-watch-choose" process or external environment influenced and how often is the remake a result of decision-making process and roles? What roles do the project team functions play in the decision-making process? How often and when are decisions made during the process that are optimizing or de-optimizing the architecture and plan?
Four product development project teams within the program were selected for study as outlined in the previous section. Two of the product teams were also developing and delivering a major functional platform as part of the project. Two of the projects leveraged the functional platforms but were not responsible for the delivery of any platforms. The lead architect assigned to each product team was responsible for gathering data. The data was collected real-time during a 10-week period and historical data, decisions made prior to the sample period was collected as well. After capturing the history of decisions, the lead architects on each of the 4 projects periodically logged, over a 10-week period, the decisions being made on the program.
To avoid a Hawthorne effect, logging was performed without anyone on the team knowing except for the lead architect gathering the data.
A tool shown in Figure 12, was provided to the architects to facilitate logging of the decisions and the architects were level set on the terminology. The tool was a form-fronted database that automatically filled in defaults for some attributes, checked formats, and maintained rules for required entries. Data was provided to the author in 7-14 day increments.
After the decisions were collected in the tool, the alignment to the strategic architecture and plan was assessed and the impact characteristics entered into the database for each decision. This was done as a separate step to logging the original decision. The lead architect facilitated the collection of this information after the decisions had been logged. This was done so a review of the strategic plan and architecture could be performed to improve consistency across the projects in the gap assessment collected and for work efficiency purposes.
The data is gathered to understand who is involved in the decision and what function they perform, what is the influence source of the decision, what is the impact of the decision, and what decisions are revisited and what it the impact. The specific data elements gathered to inform in each of these areas is discussed further in the following sections of this chapter.
25

Figure 12 User Interface for Data Gathering Tool
A set of elements for each decision was need to identify the decision. These elements are a unique number and user supplied ID, description, date logged and the date and TTM phase the decision was made.
+ Description of Decision A text description of the decision logged.
+ Date Logged Automatically filled in.
+ Date Made The date the decision is made or a date in the future if the decision has not been made yet.
+ PDP Phase TTM phase the decision is made.
The decision-making roles are divided into four groups and the PDP team functions filling the role is captured. The groups are decision-maker or who is accountable for the decision, must buy-in or who is responsible that the decision is aligned with success, facilitator or who frames
26

the decision information and facilitates the group reaching a decision, and actors or the groups that must take action as a result of the decision being made. Gathering this information may help understand the process and relate the process to the impacts. Understanding the teamdynamics, the stability, and how PDP team functions are involved in the decision-making process will help analyze the process for its impact to staying on plan and opportunities for improvement in efficiency.
The roles are defined as follows.
+ Who is the Decision Maker? This is the person/group accountable for the impact of the decision to the corporation.
+ Who must Buy-in? Who is responsible? This is the person/group responsible for successful implementation of the decision in the organization.
+ Who Facilitates the decision-making? This is the person/group that organizes the pertinant information and facilitates the rest of the organization's consumption of the information and decision-making.
+ Who Acts on the Decision? Who is informed by the decision? This is the person/group that may change action or direction as a result of the decision.
For all the questions, multiple PDP persons/functional groups are allowed however, the desire is to isolate the primaries. The following persons/functional groups are permitted as answers:
+ Senior Management Referring to Figure 4, this is anyone above the Product Manager.
+ Business Operations The group that has fiduciary responsibility and metrics aligned with operational performance.
+ Business Process The representatives on the project representing the Business Operations priorities and users. As the voice of the user, this group outlines a process and requirements for the product but is not in the operational organization.
+ Product Manager/Chief Engineer The manager responsible for getting the product to market and meeting the metrics (penetration, cost, etc.)
+ Strategy and Architecture Responsible for the product or platform architecture and the fit with the super-system architecture and strategy.
+ Development Subsystem development groups responsible for implementing the chunks of the product architecture. This includes platform elements.
+ Launch Training, distribution, help desk,..
+ Other If it is important to clarify and segregate from the categories above, then there is an opportunity to do so.
The source of the decision or influence on the product, plan and architecture is identified from 4 perspectives or topics. The decision may be native to Corporate or Business Needs, User
Functionality, Standards or Regulations, and/or Architecture Structure and Implementation.
Understanding the sources may allow the relationship of source to impact. If one of the sources creates the greatest number of decisions affecting the divergence from the long-term plan and strategic architecture implementation, then this will suggest that greater focus should be put on these decisions. Preferably there is only one influence identified, but more than one is also acceptable.
+ Corporate/Business Need These are requirements at a high-level usually relating to the company business strategy and operations of which the product and platform's being
27

developed must enable and are synergistic with. Grow Revenue by x% and brand identity requirements are examples.
+ User Functionality These influences are specific features and functions that a market, market segment, or user class desires. For example, user steps in a preferred workflow may be a desire to support a user class.
+ Standards/Regulation These are industry defacto or regulated and corporate specifications on technology, tools, and process. For example, Software Engineering
Institute Capability Maturity Model requirements or corporate preferred technology and vendors.
+ Architecture Structure or Design, These are decisions whose source is project or program internal and the content is architecture and design structure and development. For example, repairing an interface that has become tightly coupled, or re-designing a module that has become brittle or in other words, cannot easily incorporate new features.
The impact of the decision on aligning to the strategic architecture specification and to the amount of rework caused is captured to help calibrate where improvements will be most beneficial. Several elements were gathered and these were the architect's subjective assessment after examining project deliverables.
* Impact to Architecture 1=small, 2= medium, 3= large This field captures the amount of re- architecting that must be performed due to the change in decision.
+ Rework 1=small, 2=medium, 3=large This field captures the amount of rework which must be performed.
The following sets of attributes are used to isolate the project impact area primarily effected by a decision. These were not collected real-time but were added at the end of the data collecting period. Each decision was reviewed and the following elements were added in the database for each decision.
+ Scope The decision causes increases in or the inclusion of new user groups, feature/functions, geographies, etc.
+ Schedule The decision causes a schedule change, predominately a sooner or later delivery date for launch of a feature/function or product.
+ Cost The decision primarily results in an increase or decrease in spending.
+ Organization Competency or Structure The decisions results in a change in organizational structure and/or reporting mechanisms or a change in the competency required of the staff/team.
+ Platform/Product Architecture Delivery These decisions primarily change the architecture (functional chunking, interfaces, and performance characteristics) and/or the timing of the delivery of the architecture chunks. There are 4 scenarios, product is optimized, platform is optimized, the product is optimized but at the expense of deoptimizing the platform, or the platform is optimized but at the expense of de-optimizing the current product's ability to tailor to a market segment or user class.
* Product Optimization The decision optimizes functionality and/or interfaces encapsulated in the product specific components and not visible or causing changes in any platforms used by the product or future products in the family.
* Platform Optimization The decision optimizes the functionality and/or interfaces in the platform(s) without affecting deoptimizing feature/functions or interfaces in the product. In this case, the product's ability to satisfy the market segment or user class is not lessened.
28

* Product Optimization resulting in a Platform De-Optimization The decision requires an optimization in the product architecture, function and/or interfaces and also causes a platform to be impacted in such a way that future product family derivatives are lessened in their ability to get to market in the time planned, functionality, and/or robustness.
* Platform Optimization resulting in a Product De-Optimization The decision requires an optimization in the platform which enables future product derivatives in the family to be achieved at great speed and/or with higher time to market velocity as planned or better than planned in the long-term strategy. However, this platform optimization requires the current product to have lessor functionality than an integrated architecture, product specific implementation.
A set of elements is gathered to provide insight on the revisiting of decisions. Revisiting decisions is done under 2 categories, as part of the natural process of discovery and convergence on a design and implementation, or as a result of broken decision-making processes. These decisions are unavoidable and avoidable, respectively.
Indigenous to the PDP process is making decisions that result in the architecture and design and then as they are acted upon, watching to see if they are producing the anticipated and desired result. These decisions will get revisited if unforeseeable negative results are discovered by further development or if the environment changes in an unforeseeable way. These types of decisions cannot be removed from the PDP and are unavoidable. The level may increase or decrease with amount of volatility in the environment or with the level or experience and abilities of the architect and design team. However, these revisits will not entirely disappear.
The count of the revisit, why the revisiting was occurring, natural and unavoidable reasons or avoidable and process deficiency reasons was gathered.
Revisit # This is a count of the number of times a decision is revisited.
If revisiting decision, why? This is to capture the reason for the decision change.
+ Originally made to get smarter, Environment/Need/Direction/Technology Change -
As discussed previously, decision re-makes are a natural part of the architecting and convergence Product Development Process. Remaking a decision so the development process can proceed and by doing so, the team can learn if the decision is creating the desired results or difficult to make work is a necessary part of development. External influences, those influences that are external to the team's ability to control, will also cause decision revisit.
+ Didn't have the Subject Matter Experts involved in the original decision/meeting,
Organizational memory loss, Lack of original buy-in A decision re-make can also be a result of poor decision-making processes and thereby invoke unnecessary rework.
Assessing the architect's intuition on probability that the decision being made was going to be revisited was gathered. It would be opportunistic if the architects could accurately predict revisits a prior.
Probability of Future Change .1 = Low, .5 = Medium, .9 = High The probability that the decision will be revisited and changed in some future phase of the PDP. If the probability is .9 or .5, then there is an area to optionally record what would be needed to make the decision more stable.
29

Several elements were gathered to understand if the decision being made had to be made at that time and if not, what was the gap from the deadline, measured in PDP phases. Again, it would be opportunistic if a large amount of the decisions being remade are simply caused by the decision being made too early in the PDP.
* Why make the decision now? Only way to get smarter, Have information, Proper
Phase in the PDP The reason for making the decision. More than one reason can be identified but it is preferable to identify the primary reason.
* When do we need the decision? The PDP phase.
30

After the 10-week data gathering period ended for the four projects and the final attribution of the project impact areas and architecture divergence was completed, the data was analyzed using
Excel'. This chapter shows the data views and key points discovered from each view or topic of interest. Relationships between findings of the separate data views and conclusions drawn from the relationships are summarized in the Summary of Major Findings chapter which follows.
Again, the questions of interest in analyzing the decisions are who is involved in the decisionmaking process and how, what are the sources of the decisions or area of influence on the architecture, how does the decision impact the strategic architecture structure and the program rework, and what is the nature of decisions being revisited on the program.
The architects recorded 150 decisions in the following PDP phases: lb Refine Architecture and
Product Delivery Plan, 2 Define High Level Design, and 3 Subsystem Design and Build. The majority of the decisions recorded were in phase Ib, 107 (71%). The remaining decisions on the projects were recorded in phase 2, 19 (13%), and phase 3, 24 (16%). As shown in the graph below, the projects replicate the overall percentages. Large variations are due to the percentage of the phase executed by the project. For example, Product 7 is just entering phase 2.
100%
90%
80%
20%
10%
0%
-u-
-x-
Figure 13 Percentage of Decisions Recorded by PDP Phase
The following charts show the percentage of instances each team member facilitates the decision, is the decision-maker, acts on the decision, and/or must buy-in on the decision when
31

involved in a decision. The team functions may be responsible for than one role in a decision therefore the percentages will be over 100%.
Because these roles are not mutually exclusive, Figure 16 is provided to show the percentage of decisions the architect is acting in one of the roles separately or in combination with other roles.
It shows that the architect is facilitating 65% of the decisions. It is noteworthy that 14% of the decisions did not have any architect involvement. When examined, these were low level development internals, organizational decisions (such as outsourcing chunks of development), and small user feature/function or schedule decisions (such as presentation look). All the architects participating in the study did not uniformly log these decisions, rationalizing these are decisions they are aware of but not interesting to the study.
There were 2 decisions affecting "Other" areas than those specifically offered in the category buckets and these were discarded as insignificant.
Interpretation of Roles by Function Data
This data shows the team dynamics changing as the PDP is executed. The architect plays a role in fewer decisions as the PDP phases progress. Assuming the number of decisions on the project is not decreasing at the same rate, then there is a shift in primary facilitation and involvement in decisions from the architect to another function. The team functions fulfilling multiple roles in a decision declines by roughly 25% from phase lb to 3. And the division of decision-making roles between the functions is changing between phases, at times some function have zero involvement representing roles.
It is interesting that the groups specifying the product need and functionality are highly involved in decisions in phases lb and 3 and less involved in Phase 2 Design. These are the groups titled
"Corporate", "Operations", and "Process". There are several related factors causing this difference in interaction. These are where transfers of knowledge are designed into the PDP, business process change timeframes, and the ability of humans to finalize based on paper models.
The primary factor is the design of the PDP. The goal of phase lb is to transfer the function and use of the product to the design and build team. Therefore, the deliverables and phase exit questions drive the group to have conversations and make decisions concerning function.
However during phase 2, the engineering staff is required to produce internal product design and therefore the conversations with the groups specifying functionality decrease. During phase 3, the activities begin to verify functionality and so this causes the interaction between the build engineers and those specifying function to increase.
A second factor can be considered for causing the changing levels of interaction, the business priorities, process, and user functionality changes. Business models are changing at increasing rates of speed, from a change every 7 years in the 1970's to a change every 3-9 months in the later part of the 1990's
9
. The project phases are taking 2-4 months to complete and in examining the descriptions of the decision, there are changing business priorities and user functionality.
The third factor influencing the level of interaction differences is as there becomes a working model system in phase 3, details and implications not envisioned previously are processed. As the Corporate, Operations, and Process groups see the product operate in phase 3, they can better
9 Enterprise Architecture Conference papers, The Meta Group, 1997
32

90%
80%
70%
60%
50%
40%
30%
20%
10%
0% understand how the user will satisfied that when paper models and descriptions are used. This promotes an increase in interactions and decisions among the team members.
Decision Roles by Function
All Phases
" Decision WMker
* Facilitates
5 Acts on Decision/Informed by
" Buvs-in
L0
C SC
00
W
2
.0C
0
Figure 14 Decision Roles by Team Member Function All PDP Phase
4)
33

Decision Roles by Function
Phase 1b
M Decision Maker
M Facilitates
O
Acts on Decision/Informed by
1 Buys-in
90%
80%
70%
10%
50%
40%
30*/*
20%
10%
0%
00
1 o
0
% a%
Decision Roles by Function
Phase 2
Q
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
20%
0w0
0
Decision Roles by Function
90%
801/
70%
60%
50%/
400/
30%
20%
10%
0% o
0
0
00
Figure 15 Decision Roles by Team Member Function for PDP Phase 1, 2, and 3
34

Acts on Decision only
15%
Not Involved in Decision
14%
Decision Maker And
Facilitator
35%
Buy-in, not
Maker or Facilitator
Decision Maker, not
Facilitatina
1%
Facilitator, not Decision Maker
30%
* Decision Maker And Facilitator
* Decision Maker, not Facilitating
" Facilitator, not Decision Maker
Buy-in, not Decision Maker or
Acts on Decision only
Not Involved in
Figure 16 Percentage of Decisions the Architect is Decision Maker, Facilitator, Must Buy-in, Will Act on, or Is Not Involved in the Decision
There were 4 classifications for the type of the decision or main topic of influence on the project and architecture. These were Corporate or Business Need, User Function, Regulation/Standard, and System. Corporate or Business Needs and Regulation/Standard are less pliable influences than User Function and Architecture Structure and Design or Implementation decisions. The
Corporate or Business Need and Regulations are program external influences that optimize the enterprise goals and projects are subservient to these needs. All Programs and product families will be subservient to these corporate needs.
There is not a universal rule that user function will drive the system. The user function needs and system capabilities must be integrated. There may be cases when it seems that the system or architecture is prioritized over user function. This is not actually the case. The Corporate or
Business Needs to leverage industry trends and reduce the total cost of ownership appears to be prioritized over the user function. The User Function is reprioritized in favor of supporting a corporate strategy on platform-based systems.
35 affiamiM
MIM

Over all the product projects, the Corporate/Business Need and User Function decisions occupy about 50% of the architect's decision space. It is noteworthy that this breakdown stays constant through phases 1 b, 2, and even 3, the Build and Test phase. As illustrated in Figure 18, the total number of decisions processed declines rapidly after phase Ib.
100%
All Projects
80%
40%
20%
0%
M
0 Regulation
U User Function
E Corporate/Business
Need lb 2
PDP Phase
3
70%
60%
50%
400'M
40%
10%
0%
Figure 17 Type of Decision, Main Decision Topic Percentage by Phase of PDP
Architecture/Desigr
0 Regulation
1b
Figure 18 Decision Topic Percentage by Phase of Total Decisions
36

When the decision type data is broken out per project, there are significant differences. Product
7 and 8 architects are involved with and note similar levels of Corporate/Business Need and
User Function decisions, between 45% and 55%. The Product 3 architect records a much higher percentage of Corporate/Business Need and User Function, 60 to 75% depending on the PDP phase. Also, the Corporate/Business Need influencing decisions drop from 40% in the first two phases to 20% in the third phase, Build and Test.
Product 7 has not exited phase Ib, Refine Architecture and Define Product Delivery Plan.
The Product 11 Architect is not recording User Function decisions and did not record any
Corporate/Business Need influences after phase lb. In addition, the architecture structure or form accounts for the major chunks of function and has been proven during the first release of the product. This is the only product of the four studied going through the PDP for the second time. After the first PDP pass, the product was covering approximately 25% of the need functionality and able to cover less than 50% of the market. At the end of the second PDP cycle, the product will cover approximately 30% of the functionality and 60% of the market.
The primary goals for the second release are completing critical portions of the product functionality and reworking portions of the architecture that did not follow the design intent and specification during the first product delivery or for which the architecture design and specification have changed. An example of the architecture specification change is the decision to switch suppliers and application components that change because of the different supplier products.
70%
60%
50%
40%
30%
20%
10%
0%
1b
MrchiteteDesign
User Function
M Corporate/Business
Need
Product 3 Product 7
100%
90%
80%
70%
60%
50%
40%
30%
20%
10%
0%
2
PDP Phase
3 lb 2
PDP Phase
3
Product 8
70%
60%
50%
40%
30%
20%
10%
0% lb PDP hase 3
__________________________________________________________________________________ J~.
70%
60%
50%
40%-
30% -
20% -
10%
0%lb
Product 11
2
PDP Phase
3
37

Figure 19 Percentage of Decisions by Influence Category for each Product
It is concerning that the percentage of Corporate/Business Need and User Function being processed by the development team does not decrease. The source of the concern is that the
PDP implementation does not overtly acknowledge and support this. Some of the user function is refinement of requirements already architected (allocated to the structure) and designed
(system chunk implementation design), however most are changing priorities for the system resulting from scope changes and/or changing business priorities. For example, one of the cases of Business/Corporate Need in phase 3 was a priority for global deployment verses the local, US geography priority given to the team in phase lb. The allocation of need and function to the architecture chunks and design are phase lb and 2 activities so processing these items is informally resetting the team back in PDP phases.
Examining the percentages of influence with respect to the total decisions made for projects 3 and 8 as shown in Figure 20, which are the projects that have logged this data for the 3 phases, the Corporate/Business Need is still a concern. One-third of the Corporate/Business Need influences on the projects is occurring past phase lb, the phase that is designed to process these influences.
This may be indicative of the PDP design and/or the environment. It may be that implication to the user workflow and functionality can be understood in phase Ib if additional methods of discovery and analysis were performed in phase lb.
70%
60%
40%
30%
20%
10%
0%
Products 3 and 8
1 2
PDP Phase
3
% Architecture/Design
0 Regulation
.
User Function
U Corporate/Business
Need
Figure 20 Decision Influence Percentages for Projects completing phases I through 3
38

Description of Impact Decomposition Data
This set of charts analyzes the disposition of the decisions that impact the architecture product and platform chunks. Decisions can optimize a chunk without negative impact to other chunks or decisions can optimize a chunk that imposes a deoptimization in another chunk. The decisions containing a deoptimizing effect are a tone of yellow in the figures.
Throughout the 3 key development phases, 53% of the decisions recorded by the architect concerns the platform and/or product architecture. For all phases and product projects studied, there were a relatively equal percentage of the product/platform decisions made optimizing
(42%) and deoptimizing (39%) the platform.
However, examining the breakdown of the Product/Platform decisions by PDP in Figure 22 through Figure 24, the levels of optimization and deoptimization for product and platforms vary.
Specifically, in phase lb, 29% of the Product/Platform architecture decisions are deoptimizing the platform and 3% deoptimizing the product chunk. In phase 2 and phase 3, this percentage jumps to 73% and 62% platform deoptimization, respectively.
Interpretation of Impact Decomposition Data
This is the most significant and interesting data in the study. The lifecycle of platform optimization and deoptimization contains large swings. It appears that the architect optimizes the platform delivery specification for the full product-line and family in phase 1 and then in phase 2 and 3, design, build, and test, the product team de-optimizes the platform for the product family in favor of optimizing the current, individual product delivery. Two explanations are possible, an overly aggressive architecture implementation step size is specified or designs are changed to accommodate schedule issues caused by late requirements and discoveries.
One explanation is the architect is providing an overly aggressive specification for the time and resources available. As the architect synthesizes the business needs and user functionality into an architecture implementation specification, the specification may require more development competency and resources and/or schedule duration than available. Although the architects consider organizational capability to execute during architecture synthesis, the details of the plans are obviously not done so the architect estimates. Also, the framework or infrastructure, especially in the case of a platform element, is a larger percentage of the first phases of development verses features. The architect as well as the development managers may under estimate this level of effort.
Two, as additional requirements and needs are placed on the development, the time, resource, and function triangle, immovable on the delivery date, must flex on the resource side of the equation to accommodate the functional requirements. This results in selecting less resource intensive implementations that de-optimize the platform. In this case, if current legacy development practices and design patterns are available and the strategic architecture technology, development practices, and design patterns are not well know, the legacy implementation will provide faster results with less effort for the current release. The long-term benefits are enabled by the strategic architecture but the long-term looses priority when faced with short-term pressure.
This gain-flexibility-through-design-changes interpretation is supported by observation of the plans and teams during these decisions. Adding resources to compensate is limited quickly by budget constraints and the natural laws of how fast engineering resources can be added to the
39

RM ON
..
-
'Rii l --
team. New team members do not immediately become productive and software engineering resources are not easily available
0
.
- - -
Figure 21 Impact of Decisions on Scope, Schedule, Architecture (Product/Platform), and
Costs for All Products, All PDP Phases
Figure 22 Impact of Decisions on Scope, Schedule, Architecture (Product/Platform), and
Costs for All Products for Refine Architecture and Plan Phase
10 Statement supported by Meta Group, GartnerGroup, Giga Group industry analysis papers
40

Figure 23 Impact of Decisions on Scope, Schedule, Architecture (Product/Platform), and
Costs for All Products, for Subsystem Design
Figure 24 Impact of Decisions on Scope, Schedule, Architecture (Product/Platform), and
Costs for All Products, for Build and Test
The breakdown of Product/Platform decisions by topic of influence in Figure 25 through Figure
27 shows a reduction from 57-59% of the deoptimization in the case of Corporate/Business
Need and User Function Influenced product/platform decisions, to 35% in the case of System
Influenced decisions.
41

-- ----Imam=
Corporate and User influences result in 34% to 24% Platform Optimization without a resulting
Product deoptimization, respectively. The system indigenous decisions result in a 51% Platform optimization without incurring a Product deoptimization.
When the Corporate Need or User Function is the source of the architecture and/or design decision, the platform de-optimization impact increases 12-15% over system design and technology isolated decisions. This data supports the previous interpretation that function is reprioritized and/or increased through new additions or the discovery of implementation details while the delivery schedule is held. Therefore the only remaining flexibility is resource level changes by selecting design short-cuts that can be delivered quickly.
Another theory is that the team is making system structure, design, and technology decisions with the specific goal of optimizing the platforms as a part of the system influenced decisions category and therefore these percentages would always reflect higher levels of platform optimization. It is common for engineers to make design improvements and this activity falls into the "System Influences" category. The engineers take opportunities to rework areas they previously implemented quickly in a less robust way when time pressure to release was high.
Figure 25 The Impact that Corporate/Business Need Decisions have on Scope, Schedule,
Architecture (Product/Platform), and Costs.
42

Figure 26 The Impact that User Function Decisions have on Scope, Schedule, Architecture
(Product/Platform), and Costs.
Figure 27 The Impact that System Decisions have on Scope, Schedule, Architecture
(Product/Platform), and Costs.
43

Description of Causes of Revisits Data
The following charts show the decisions revisited on the projects. In Figure 28, the percentage of time a decision is revisited once, twice, and greater than 3 times is shown in contrast to decisions not revisited. The decisions being revisited are 14% of the total recorded. The decisions remade within phases and the decisions remade that are earlier phase decisions and resetting that portion of the project back to earlier phases are shown in Figure 29. Of the 14% of the decisions revisited, 28% require 2 phases of the PDP to be reworked, and 24% require one previous phase of the PDP to be reworked. Also, 16% of the decisions are changes from previous product deliveries in the family and PDP executions and occurring in phase 3.1 when examined.
In Figure 30, natural PDP decision revisitation that occurs as the product converges on delivery is highlighted in blue tones. Unproductive and avoidable revisitation of decisions counts greater than 0 are highlighted in yellow tones. These were evenly divided with 51% of the reworks a result of unavoidable changes in the external environmental influences or as a result of the
"choose-watch-choose" nature of development.
Figure 31 and Figure 32 show the impact to the architecture and the rework impact.
Architecture impact also includes changing technologies and/or suppliers and changes in the performance requirements for chunks of the architecture that do not impact the architecture form.
Interpretation of Causes of Revisits Data
Decisions are being revisited and causing the projects to informally revisit previous phases of the development project. This is being done informally and without the rigor of phase exit reviews and in some cases, without producing the deliverables required. Also, a third of the decisions are remade within the phase causing a delay in exiting the phase and may be increasing the duration of the schedule.
There were 16% of revisited decisions across products. These revisits are done after a product is released and may impact product-line coherency and consistency. Also, the principle that the difficulty in fixing a bug increases with the distance between when the bug was inserted and found" may relate here. Although these are not software bugs in the strictest definition, the change in implementation is still required and the loss of memory of design is still present.
Over half of the decisions, 54%, that are revisited are due to the natural characteristics of the
"Choose-watch-choose" process of architecting and developing a product and environmental influence. The only opportunity for removing these revisits from the system may be in improving the architect's ability to predict and select the solutions. Decisions originally made because proceeding through the development process is the only way to get smarter and determine correctness would be revisited less with improvements in intuition. Environmental changes, changes in product priorities, resource availability to execute, design robustness and technology trends or innovations are difficult if not impossible to avoid. Therefore significantly reducing decision remakes in the choose-watch-choose and environmental influence cases are not expected.
The primary opportunity for reducing decision revisits is in the decision-making process area with 46% of the revisited decisions being unnecessary. Although these are human systems and
"1 Microsoft Secrets, Michael Cusumano, 1995
44

will never be perfect, process improvement can achieve reductions. Although there is no reference point, remaking decisions half the time because of poor process seems high.
0 Revisits
86%
Revisited Once
Revisited Twice
3%
Revisited 3x
1%
Figure 28 Decisions Revisited Counts
Reset Back 2
Phases
Reset Back 1
Phase
24%
Remake across
Products in
Product-line
16%
Remake within
Current Phase
32%
Figure 29 PDP Phase Distance between Original Decision and Remake
45

Lack of original buy-in
23%
Originally made to get smarter
23%
Org memory loss
15%
Didn't have
SME(s) in original meeting
8% environment change
31%
Figure 30 Reasons for Revisiting Decisions and Percentage of Occurrence
The following charts quantify the impact to the architecture and product development rework.
Architecture impact in the conceptual, strategic structure and form was not identified. The impact to the architecture took the form of new technologies and/or supplier package insertions into the form, changes in scope and areas the architect was specifying, reworking interface specifications or other architecture collateral to add functionality to the release, and so on. There is a natural progression of growth or build sequencing and violations of this progression are also logged as architecture impact due to the temporary structures that must be put in place. An analogy commonly used is "city planning". A natural build sequence is water, road, communication, sewage, and electrical infrastructure, then houses. Houses have a build sequence such as basement, frame, wiring and plumbing, dry wall, and finishing. Building a house prior to the water and sewage would require temporary structures to provide water and sewage services. As the figures below show, about one-third of the decisions revisited had a medium or high architecture and rework impact.
Reducing the occurrence of decisions remade should reduce the architecture specification and implementation rework occurring. Considering that one-third of the decisions have a mediumhigh impact of rework and architecture deviation, decreasing decision revisits should decrease costs and increase product delivery speed. If "temporary" structures are being put in place because the natural build order of the architecture is being violated, there may product robustness increases enjoyed by removing revisits.
46

Figure 31 Architecture Impact of Revisiting the Decision.
Figure 32 Rework Impact of Revisiting the Decision
47

The following figures show the architect's estimate of the probability that the decision will change, the reasons why the decision must be made now, during the current PDP phase, and the percentages of decisions falling into each category. Decision categories for why a decision is made now are not mutually exclusive.
The architect is either overly conservative in his estimates of change or all the decision changes are not being logged. The architects are predicting 33% of the decisions to have a high probability of change however only 14% of the decisions are being logged as reworked.
Another possibility is that the architects are right and decision revisiting increases in the future.
This last theory is supportable when considering that the platform deoptimization will have to be revisited in the future and will be consider decision remakes when the implementation is migrated back to the architecture specification to support future products.
This data may simply reflect that when asked, people will subconsciously divide their answers evenly between the categories offered. This may be the likely case and therefor the information is less meaningful. Perhaps restricting the number of decisions the architect can put into the
"high probability" and "medium probability" categories would be more useful. For example, if only 10% of the decisions could be logged with a ".9" probability of changing in the future, then this would yield a small set of decisions to put effort into being adaptive to change.
Figure 33 The Architect's Estimate of the Probability the Decision Will Change in the
Future.
48

The following chart shows the percentage of time decisions are made out of necessity or convenience. Decisions made out of necessity are made because the PDP phase cannot be exited without the decision. The necessity decisions are broken down into the percentage of the time there is a sufficient level of proper information to make the decision and the percentage of time there is not proper information to make the decision. Decisions made out of convenience are decisions made in a PDP phase earlier than the PDP phase that requires them to be made. The typical scenario is that there is sufficient information available to make the decision, the team is constantly striving to close as many decisions as possible, and therefore these decisions are made. There are 41% of the decision being made without a requirement for closure.
The relatively high level of decisions being made early, 41% is a concern. Decisions lock down degrees of freedom and therefore should be kept open as long as possible. Also, action and work is taken once a decision is made. There is an opportunity to avoid the rework from a decision remade that could have been delayed. This would have to be studied further. It is also possible that by making the decisions earlier than necessary, the "choose-watch-choose" discovery process occurred earlier and the best decision known earlier. And this may shorten the duration of the project.
(Convenient (Not
Proper Phase but
Have Info)
41%
Proper Phase and
Have
32%
Proper Phase and
Only Way to Get
Smarter
27%
E Proper Phase and Have
Info
" Proper Phase and Only
Way to Get Smarter
R (Convenient (Not Proper
Phase but Have Info)
Figure 34 The Percentage of Time the Decision is Make out of Necessity or Convenience.
49

This chapter summarizes the key findings in the data and then provides methods for improvement. There were four major findings in the data. Three were related to the objective of the study to understand and improve long-term vs short-term balance in Product
Development. One finding was in the area of team organizational processes and was unanticipated.
The three major inhibitors to maintaining alignment with the long-term product-line strategy and architecture are the cycling during the PDP between short-term gains and long-term plan is significant, avoidable rework, and the timing of decisions is reducing flexibility and increasing rework. There are several methods offered to manage the long-term trade-offs and to decrease the rework in the PDP. They are increasing reaction buffers and driving discovery of requirements earlier in the PDP, formally rerunning PDP phases for decisions resetting back to earlier phases, measuring for long-term alignment and reorganizing around platforms.
The data also indicated that the team dynamics were changing between phases. This suggested that methods could be introduced to accelerate the team storming and norming taking place at the beginning of each phase.
The trade-off between long-term, product family optimization and short-term, individual product optimization was evident in the decisions studied. There are several findings that suggest management and architecture practices to raise the visibility of the trade-off and manage the trade-off decisions and impact better can suggested.
Throughout the critical architect, design, build, and integrate PDP phases there are roughly equal amounts of decisions optimizing and deoptimizing the Product Platform. The interesting finding is that the bulk of the optimization of the platform occurs in PDP phase 1, 52% and drops to 15 to 18% in subsequent phases. Simultaneously, the decisions deoptimizing the platform start at 29% in phase 1 and grow to 73 and 62% in subsequent phases.
Upon examination of the data, the decisions deoptimizing the platform and optimizing the product were more often a result of schedule pressure than a deficiency in the end state or definition of next delivery in the progression towards end state. The priority to remain on schedule is higher than the priority to avoid incurring rework of tactical implementations. The majority of the platform de-optimizations were found to be divergence from the functional decomposition, re-designing interfaces for current product optimization, and optimizing functions so that they became localized to the first market segment or user group.
Not all chunks of the architecture are scheduled for build during the first release due to requirements phasing. When the requirements prioritization changes and the result is that functionality in architecture chunks not currently in the build process is required, then putting the functionality into existing chunks of the architecture in the PDP build process is faster than starting a new chunk of the architecture.
New or changing requirements may require additional interfaces to support the function. A faster delivery is achieved by overloading an existing interface or using an easily available
50

resource or technology rather than creating the new interface as per the architecture specification.
Tailoring the product to fit the detail requirements of the first market segment and/or user group caused the platform function to be less adaptable to future market segments. Because the future market segments were not understood at the same level of detail and the project priorities were not currently focused on future segments, there was less pull to trade-off time for future adaptability. A much more intensive and longer study would be required to quantify the level of impact to future products.
Of the 14% of the decisions revisited on the projects, 54% were unavoidable and due to the
"choose-watch-choose" nature of the architecting and PDP process. However the remaining
46% of the decision revisits which occurred due to avoidable work process deficiencies presents an opportunity for improvement. These decisions include those revisited due to a lack of original buy-in, gaining all easily obtainable information, and maintaining organizational memory of the decision.
Decisions are closed as required to exit a PDP phase. It is natural for some decisions to be made when the set available information required to make the decision with a high confidence of correctness, robustness is available. As well, it is PDP process reality for some decisions to be
"tentatively" made because the information required to make the decision can only be provided
by further discovery in subsequent phases of the PDP per the "choose-watch-choose" nature of architecting and development. However, it was a slight surprise that the percentage of decisions were almost evenly divided between the two categories, 53% and 47%, respectively.
The data showed that 41% of the decisions made during the PDP phases 1 through 3 were made out of convenience. These are decisions for which information is available so the decision is expediently processed in the current phase rather than holding the decision open until the subsequent phase when the decision is required. There was not sufficient data to quantitatively determine the impact the early decision making had on rework levels. A more extended time period of study would be needed for this.
The data showed the team dynamics changing as the PDP is executed due to the architect's changing level of involvement and the participation in decisions changing. The architect plays a role in fewer decisions as the PDP phases progress. Assuming the number of decisions on the project is not decreasing at the same rate, then there is a shift in primary facilitation and involvement in decisions from the architect to another function. The multiple roles the team functions fill declines by roughly 25% from phase 1 to 3. The percentages each function is a decision-making role type changes for the functions and in some phases, function have zero involvement representing roles.
51

The following recommendations are based on the management, architecture, and engineering concepts, methods, tools, and heuristics presented during the System Design and Management
(SDM) program course, special sessions, and readings. The course lecture material, books, and special seminar notes are referenced.
Obviously only a subset of the material presented over the two-year {SDM
program is applied due to the needs represented by the studied projects. These needs and proposed solutions will apply to other programs in the IT industry as well as across other product development industries, as the opportunities for improvement of this set of projects are indigenous to architecture and PDP in general. In harmony with the intent of the SDM mission, both management and engineering topics are presented in cohort and industry based terminology.
The data showed that decisions get reworked for a variety of avoidable and unavoidable reasons.
When a decision from phase lb or 2 is changed in phase 3, this change must be reflected in the phase lb and phase 2 analysis, design and test specifications thus resetting that portion of the development back to phase lb. Currently this is an informal process and therefore is done without benefit of the phase gate reviews and an expedient process and buffer for the work.
The team should design a mechanism in the PDP for recognizing the need to "rerun" the PDP phases for a subset of the decisions, and for reserving resources and schedule time to absorb this work. This would invoke the deliverables and methods for phase lb and phase 2 that increase product robustness and success. The phase gate reviews would make visible the long-term plan trade-offs being made.
Given the consistent level throughout the PDP phases of changes in corporate needs influencing the project, there should be accommodations in the management plan and processing to support the changes.
A response buffer should be built into the phase 2 and phase 3 plans so that the corporate need changes can be absorbed without impacting the architecture realization plan (precipitating as platform deoptimization and rework), quality of life for the project team (overtime), or the planned delivery date. Even if a need or change in direction is added during phase 2 or 3, the need still must to flow through the phase 1, 2, and 3 PDP tasks, so this buffer must include resources to support the tasks from all three phases.
The program team must manage this buffer and its allocation or release guarded. Given the heuristic "Any task expands to fill the allocated time", the project will have the tendency to expand to fill the buffer time without any additional task or changes in direction. The buffer should be placed at the end of the project plan "to protect the completion date".1
2
As a general good practice, a buffer should be added to minimize product completion date misses. Given most engineers estimations of task duration is a .3 probabilistic number 3
, additional tasks and changes inherent in the Product Development Process, the probability of overrunning a delivery date is high.
12
13
Critical Chain, Eliyahu M. Goldratt, 1997
Project Management Course Materials, 1998
52

There are several Marketing and Total Quality of Management techniques for understanding and prioritizing market and customer requirements. These should be examined in order to determine their ability to migrate some of the user functionality influences on the architecture and design from Phase 3, Build and Test to the earlier Phases 1 and 2, architecture and design.
There is little room for design changes during phase 3 and the quality of design work under the approaching delivery deadlines is in question.
Therefore, moving the discovery and understanding of the function to earlier phases allows the features to be designed during the appropriate phases, according to the PDP guidelines. This improves proactive development planning and management, positively effecting quality and architecture alignment.
Specific market investigation methods such as non-intrusive user observation, pilots, and conjoint engineering can be used to increase early discovery.
User observation calls for the product development staff to visit several users and observe, noninvasively, the user with the product. This technique enhances a teams ability to ensure "the products you bring to market are direct hits with your customers, higher in quality and lower in price than your competitor's,..."".
Apply conjoint engineering While the fuzziness of market and customer requirements importance is not completely removable, qualitative information of the market and customer needs is obtainable through a number of methods. Market studies, market testing (through prototype pilots in this case), and customer surveys can be periodically prohibitive due to time and/or moneys. Conjoint analysis allows an alternative for gathering rich customer preference statements and identifying the critical preference parameters at a reduced cost. Based on the orthogonal properties applied also in Taguchi Method Robust Design, conjoint analysis allows for a small number of market/customer data collections to reveal priorities, noise and signal for a larger number of requirements thus allowing the team to focus on the critical parameters.
The data showed that during the Product Development Process design and build phases, the original architecture specification was not followed and the result was a deoptimization of the platform implementation. This deoptimization was characterized in the previous sections as making design decisions that optimize the function, cost, and/or schedule of the current release at the expense of the function, cost, and/or schedule of the platform support of the entire product family.
The thought that the architecture transition targeted was too large and too aggressive is worth consideration. Smaller, more frequent deliveries may provide benefits because smaller chunks are less risky to manage. However, it is not clear that the primary root cause of the platform deoptimization is the size of the implementation. Calibration of the architecture step size would require further experimentation and analysis. The impact to creative tension and long-term focus that is provided by the architecture specification would have to be understood.
A more productive goal of reducing the amount of platform deoptimization if offered instead.
The two methods are proposed. They are establishing platform architecture measures and by organizing more closely to the architecture.
14
Customer Service: The Last Word, John Case, Inc. Magazine 1991
53

There are informal reviews by the architecture group to subjectively determine the health and alignment of the platforms being delivered by the product teams. There are no regular, consistent methods for architecture and platform alignment measurement.
"Why Measure?
Organizations are driven to measurement by customer mandate, competition, and the desire for internal insight to make tough program and system optimization decisions. Measurement is important to customers, quality assurance, managers, and engineers through enabling positive and negative trend detection, planning and estimating through historical, fact-based data.
Process and product improvement, progress assessment, prediction and control, and most measurement work to date have been performed in this area. In measurement, companies need to figure out 'What is a best practice and how do we insert it?"' 15
Perhaps the most compelling reason to measure the health of conceptual integrity and architecture compliance is that "a system's conceptual integrity is of overriding importance, and that systems without it fail.""
6
The Platform(s) architecture should be examined and measured at phase 2 and 3 exit as it aligns with the planned architecture (current release and futures) of the platform and products that are articulated in phase 1 and phase 1 exit of the PDP. The PDP process should be enhanced so that at phase 2 and 3, the design and implementation changes that have been made from the phase 1 specification are identified.
Ideally these decisions are processed real-time, pre-implementation with the lead architect, not post-implementation at the exit. The list at the phase gate exit is to maintain organizational memory of the items and review from a "larger picture".
Each change should be categorized as
1. A change in the original architecture due to a defect.
2. A change in the delivery schedule which results in lessor functionality delivered but within the architecture specification.
3. A change in the design of the delivered platform product that is not aligned with the architecture specification and the architecture specification is not in error.
Each category 3 change should be measured by rework, speed, and cost. The team should define the rework that is incurred to realign the release with the architecture and when the rework will be required. Rework should include the rework for the product and the rework across all products envisioned to use the platform. The schedule benefits enjoyed by the current product release and the schedule impact of future releases should be identified. These impacts should discuss all products impacted by the change in platform delivery. The cost of the rework should be defined. This should include development costs and lost opportunity due to delays in market response.
There should not be a goal to reduce the category 1 and 2 changes occurring in phases 2 and 3 to
0 occurrences. In the case of category 1, "A change in the original architecture due to a defect", as discussed earlier, this is a natural side-effect of the architecting "choose-watch-choose" and
15 Summarized during System Engineering Course Lecture, Summer, 1998 by Dr. Donna H. Rhodes, Systems
Engineering Technology Manager, Lockheed Martin Federal Systems, 8/98.
16 The Mythical Man Month, 1975, Frederick Brooks
54

product development processes. While this number should be relatively low, it will never become 0 especially in a rapidly evolving technology space.
In the case of category 2, "A change in the delivery schedule which results in lessor functionality delivered but within the architecture specification", the occurrences in this category are preferred over category 3 because of the rework incurred in category 3. Due to this reason and also because these types of changes are a result of the natural tension created by a vision to current reality gap this category should not reach zero occurrences. The natural tension is highly desirable because it a symptom of "vision" and promotes creativity.
Further understanding is needed to determine the optimum levels of category 1 and 2 occurrences. Some questions to be explored are "Are the product delivery releases too aggressive in time-resource-function size? Would smaller chunks of time-resource-function reduce the rework over several increments? Would these smaller chunks have the detrimental side-effect of removing creative tension from the project due to the less aggressive goals?
Would smaller chunks of architecture steps in direction be unstable thus removing the best practice of stable intermediate forms? " "A system will develop and evolve much more rapidly if there are stable intermediate forms than if there are not." 17 should be kept in consideration.
In addition, the project team may not be smart enough on the first platform release in phase 1 to precisely identify the platform and interface specifications. There may be a "learning" release necessary.
The current organizational structure does not align with the logical architecture model and reenforce the design encapsulation, modularity and interfaces. An organization and plan that aligned to the architecture is shown in Figure 35. "Which architectural structure does the team structure mirror? The best bet is the module or logical structure." 1 8
. The organizational structure doesn't obviate an integrated product architecture in fact, it may encourage it. The team incentives are aligned with the product delivery first and the platform delivery second. The development of the platform is prioritized based on the priorities of the product being managed
by the team. The team managing the platform consistently reprioritizes other peer product team priorities for platform features.'9 It is difficult for the architect to inspect for and mitigate tight coupling by providing a focus that is product-line and product family based verses single product based.
17
18
The Art of System Architecting, Eberhardt Rechtin and Mark Maier, 1997
Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman, 1998
19 Based on examination of requirement priority lists of the projects.
55

Time (years)
Figure 35 Platform Architecture Aligned Organization and Plan
McGrath 20 proposes 6 trade-offs to achieve strategic balance. They are the balances of focus and diversification, short term and long term, current platform and new platform, business A and business B, research and development, and high risk and low risk. The current organizational structure provides little long term tension or second business tension. The balance is highly biased towards short term and project business, and to a slightly lessor extent, current platform release.
Organizing such that platform teams are managed external to the product deliveries should be considered and explored. Several advantages may be realized. Higher levels of information hiding, modularity, and loose coupling of system products and platforms can be insured. More efficient organizational communications and production processes will result from minimized pair-wise discussion due to the architecture not being reflected by the organization.
Prioritization of platform features that enable a vector of differentiation across several products can be increased. Incentives for producing a platform that achieves the lifecycle expectancy and supports the family of products as planned should be inserted for managing the platform team. This balances "business A and business B" type trade-offs. The overall result is higher levels of long term focus and understanding.
20
Product Strategy for High-Technology Companies, Michael E. McGrath, 1995
56

The changing roles and levels of interaction captured throughout the PDP can be managed to improve efficiency at phase start by reducing the forming and norming time. Also, considering the level of system architecture and design changes occurring in PDP phase 3 of the projects examined, there are project management opportunities for improving the platform focus and realization. The summation of team lifecycles in the following paragraph suggest team launches at the beginning of each phase can reduce the time to action.
"Teams have a lifecycle forming, storming, norming, performing, reconstitution, and disposal.
This lifecycle is happening during the PDP in which different project sub-teams form across the product lifecycle phases from concept, feasibility, technology and process readiness, production, installation and Ops, and disposal. Even when sub-teams are not changing/forming at each phase, conducting team launches for EACH PHASE of the project, roles and responsibilities definition, and "manager-as-coach" are important success factors. Team structures and leaders evolve and change across the life cycle.""
The team launches or phase kickoffs should confirm existing roles and responsibilities or explain changing ones from phase to phase. In the case of the architect, there should be a role and responsibility articulation in phase 2 and 3 that defines prioritization of system integration for success of the current release and the monitoring of the architecture and design for future release optimization as the architect's focus. Concurrently, the architect will be preparing for phase 1 of the next increment of development. As the data shows, Corporate/Business Needs and User
Functionality continue to influence the project during phase 2 and 3. The architect will need to allocate these influences to the current release, to future products in the line, or to other product lines and platforms.
The current PDP process calls for the lead architect to complete all tangible and most intangible deliverables by the end of phase 2, and then move to another project which is beginning phasel.
However, if there is not anther project needing architecture coverage, the architect should remain with a project through phase 3.
There should be defined tangible and/or specified intangible deliverables the architect is responsible for during phase 2 and 3. These should be tasks and deliverables that are pertinent to enabling the "choose-watch-choose" process such as design reviews, system integration walkthrough, and/or integration and test review. And the architect should be involved or responsible for tasks that process influences on the architecture such as requirements processing.
The incentive system of the program should be analyzed for balance between long-term plan and short-term execution. Each product team and the program should be analyzed per the cultural, political, and structure views of the system.
Are degrees of freedom reduced by making decisions earlier than required and thereby limiting the quality of the design and customer satisfaction as well as the cost, and speed of delivery?
Does the process sufficiently encourage the architects and designers to revisit decisions at the subsequent phase as if the decision was still open? Are the people on the project predispositioned not to revisit and change decisions?
21Summarized during System Engineering Course Lecture, Summer, 1998 by Virginia A. Lentz referrencing the following resources "Concurrent Engineering Playbook: The Sports Team Metaphore Applied to Concurrent
Engineering", Virginia A. Lentz & Jean Stanford, NCOSE '92, and "Wisdom of Teams", Jon R. Katzanback &
Douglas K. Smith
57

As recommended by Marco lansiti and Alan MacCormack in their 1997 Harvard Business
Review article, "Sensing Customer and Market Needs as a Project Progresses is One Element of a Flexible development process."
2
There should be a process for continually testing the key customer and market requirements, testing the alternative solutions, and revisiting decisions to maintain alignment. Frequent customer involvement through conference room pilots and limited beta releases are suggestions. To minimize rework, action based on decisions should be delayed as long as possible, especially for decisions made very early out of convenience.
There is an opportunity to understand more deeply the PDP process and specifically, the platform lifecycle including the optimization and deoptimization of the platforms. It is not clear that the platform can be fully designed at version one. We may not be "smart enough" to design the optimal level of abstraction and least complex yet most flexible interface architecture.
Perhaps over several releases there will be a development lifecycle strategy of "get the functionality and learn phase" and an "optimize the architecture phase" lifecycle emerging as the best way to achieve long-term results.
A more extended time period of study should be used to determine the impact and manage the implementation of the recommendations made in this paper. Especially to design and collect data to understand the impact on rework and flexibility of changing the timing on convenience decision-making.
Benchmark studies should be performed to discover the average levels and best case benchmark levels of decision revisits due to "choose-watch-choose" natural, unavoidable processes and decisions revisits due to avoidable inefficient decision-making processes.
Gathering architecture decision-making data across other programs, industries, and disciplines could offer comparisons that expand best practices and methods.
22 Marco lansiti and Alan MacCormack, Developing Products on Internet Time, 1997, Harvard Business Review
58

The following is a complete list of references quoted in this document or consulted in the writing of this document. It is provided to both support the claims in the document as well as direct the reader to other sources of topical information.
Professor Ed Crawley, System Architecting course lectures, 1998, 1999
Systems Architecting, Creating and Building Complex Systems, Eberhardt Rechtin, 1991
Product Strategy for High-Technology Companies, How to achieve growth, competitive advantage, and increased profits, Michael E. McGrath, 1995
Software Architecture in Practice, Len Bass, Paul Clements, Rick Kazman,1998
Managing for the Future, Organizational Behavior and Processes, Deborah Anacon, Thomas
Kochan, Maureen Scully, John Van Maanen, D Eleanor Westney, 1998
Technology Strategy course material, assembled by Rebecca Henderson and Scott Stem, 1999
Systems Engineering course material, assembled by Professor Charlie Boppe, 1998
Marco lansiti and Alan MacCormack, Developing Products on Internet Time, 1997, Harvard
Business Review
Microsoft Secrets, Michael Cusumano, 1995
Customer Focused Product Development by Conjoint Analysis and QFD, Anders Custafsson,
1996
Intent Specifications: An Approach to Building Human-Centered Specifications, Professor
Nancy G. Leveson, MIT
Why and How of Requirements Tracing, Robert Watkins and Mark Neal, Abbott Laboratories
Diagnostic Division, 1994, IEEE Software
The Art of Systems Architecting, Eberhardt Rechtin, Mark W. Maier, 1998
Critical Chain, Eliyahu M. Goldratt, 1997
Customer Service: The Last Word, John Case, Inc. Magazine 1991
The Mythical Man Month, Frederick Brooks, 1975
Build for Business Innovation, Flexible, standarized enterprise architectures will produce several
IT benefits, Roger Fournier, November, 1999
Vendor Selection For Sales Organizations: An Uncertain Market, GartnerGroup, W. Close, R.
Desisto, J. Golterman, M. Maoz, December 199
GartnerGroup, Giga, Forester, and Meta Group selected articles and conference materials from
1995 through 1999.
59

Exhibits
The following screen shots show the data gathering tool interface and a portion of the data gathered considered industry neutral. The data-gathering tool was a Microsoft Access Database with a Forms user interface. This tool helped facilitate consistency and completeness in the data gathered. It forced the architect to enter complete data in a consistent order of workflow.
60

52
Despite corporate reorganization combining USA and Canada into NA, do not integrate Candaian DRO and USA
DRO in Dl
1/1 7/1 999,
1/15/1999!
3.1
1001
This decision will not be changed
51 5m
01

=
53
Despite limits on inbound fax functionality and integration into CTI layer, employ Xerox product CentreWare for inbou nd and outbound fax solution (great marketing, which overrides functionality concerns)
1/17/1999
20i
Functionality outweighs marketing benefit
0

__
54
Continue to inform FTF force of lead using VMAX, but do not tell them the lead details force them to call the center to get the details
3.1
20
FTF requiring data sooner/faster
Sales Force
0

551
Donot put controls in place on entering new establishments into MDB i h alcne
/7199
S/15/19981
3..1
Poluton f heMDB database
11
5

56 not co
)o not create separate development, testing and pilot infrastructures until 2000 to save money
1/17/1999
/15/1999
Fhis decision will not be changed s is a decision of "no tion", so no actors
N Ok
A ffkswwr
-N

V
.57
Train on technology independent of business process
-- teach "how" not "why" in classes
1/17/1999
/15/19.99
3.3
___
This decision will not change
0

becision Tracking Log
IMA will not integrate directly to ASST. Instead, ASST integration for leads will be via Early Cloud.
1/1 7/1 999
1
1/15/1999'
Need for efficiency; new SFA; Telecoverage full implementation
3100
1
0 i

Tracking Log
TeleCoverage and TeleSales will employ ASST; IMA will not be used for Territory Management
117/1999,
/15/1998,'
3.11
Delay in new SFA tool
0

Decision Tracking Log
60
ValueQuX will be used for Order Entry;
IMA s Order Entry capability will not be integrated to the ValueQuiX server,
1/17/1999
/15/1998 elay in integration of browser-based front end
0
1'
L

Inen
61 1rture Fulfillment will continue to be via Early Cloud; IMA's literature capablt ilntb sd
0

62-
The first release of the new TeleWeb Center technology will be primarily concerned with "Market Penetration", not
"Employee Satisfaction" -- compromises will be made that will negatively impact the TeleWeb employees in favor
1/17/1999i
3.1
1001
Next Major Release
I
_
0a

Scope TeleCoverage down to TeleMarketing functions rather than partnership model that would include TeleMarketing and TeleSales.
implement the fl T oTl~vrg e
Copetion of negotiation with FTF n

Decision Tracking Log
1'
Ultimately, the MTO and OTC MCKB for front office and backoffice, analytics and operations lives in an ERP.
/07/1999
/07/1999
3.1
0.11
1 Um nI

7
--
2
Decision
ERD will be designed by EDM team and be built, instantiated in the authoritative system.
07/199
1/1/2010!
3.1
___
0.5

becision Tracking Log
Vendor(s) for analytics will be Oracle 11 for horizon state, Viador Oracle, and Tapestry for transitions
/15/1999'
/
2 2
/1
9
9j
this is based largely on tech trends and
level partnership.
3.1
0.51
3.1
Projects in same functional area now

becision
Log
Europe is in scope as far as IBT and account role up reporting, analytics, and dashboard. Real-time integration of
disposition, territory configuration, and other global operations is a future possibility.
/15/1999!
1/01/2000i
3.1

Decision Tracking Log
5
Prioritization of Business Goals and Needs is estab, account data quality, IBT, MAC, Front-office integration
/16/1999
/10/1999,
3.1
0 iin

becision Tracking Log
6
Feature/Function Requirements Prioritized and first strategic Nugget/Deliverable Selected
/16/1999,
/10/1999i
33.1
0
M- W

becision Tracking Log
7
Scope for mckb system is operational data and macro processes around customer, analytic, reporting environment.
/16/1999
/16/ 1999::

__
8__
Project Organizational Structure is flat
4
/16/1999"
/01/1 999''
3.1
0-

9
Legacy retirement strategy defined
/1 6/1 999
1/02/1 999'
3.1
.
.
.
0, 1

becision
10
Gobal Reporting for IBT and Major Accounts must be in first transition, first target release
/09/199
/0/1 999i
0

__
Bulk data movement architecture principles defined
/20/1999
/20/1999 iCommunication with the responsible/buy-in
]community

Decision Tracking Log
12
Selection of 3rd party suppliers for marketing data and match/search services
/20/19991,
7/01999
Ne uppliers will be considered if differentiating
00

becision Tracking Log
13
Review of Hatch and Axiom as possible suppliers of Marketing info
/20/1999i
/20/1999
3.1
ill continue to review as new suppliers are found.
1 lj ii

Tracking Log
14.
What is the structure, ERD and semantics for world-wide estab, prospect, customer, account?
7/20/1999i
/20/1999
3.1
3.
Better design process
0M

13_
____0 structure, ERID for estab
3.1
/2/999
/2/999,
3.1
0.9 i better design process

Decision Tracking Log
Primary global analytics will be in the North American instance.
/20/ 1999
3.1
organization stability
0.R

becision Tracking Log
17
-
Dun&Bradstreet contract will be managed globally to reduce cost and increase the amount of establishment content we can buy
1/08/199
1/08/19991
3.2
0.1
3.1
3,p
0

becision
Need to define the market/customer information required by front and back office, architect source of record and flows.
1/81999,
1/819991
-0.9
concensus on business functionality statement, globally
-- -0 ci

20MV
Review E piphiny for ETL and DSS web vendor insertion
1/08/1999 n /01 /1998 epngdut pinle o enors0f

-- - -- -- - - --- --- - --- - ---- - -

EAI for Xerox is the MB platform
1619
08/19??
0.. 5, v

.
.
..
j-
.............
ILL

becision Tracking Log
26
Decision Team will be decentralized to the business
1/08/199
/01/1999
3.3
0.91
3

28,
Technology Readiness using top 64 accounts will be performed. Goal is to determine robustness of current state legacy, value of D&B, and understand insertion path for ETL and analytic/report engines and delivery
1 /08/1999.
1/5/1999 of the priority to do this work
01

Decision Tracking Log
29,7
Customer information on Order will be placed on digital order by front-office pull of back-office authoritative source(s).. (OTC ERP, MDB/CHI, MCKB)
1/08/1999
1/05/1999
3.3

Decision Tracking Log
3017
Will translate the territories to comp system "data unit' for y2k config
1/08/199
1/8/1999;.
eCOTS in place

Decision Tracking Log
31
account results measures are the primary need
1/12/1999
1/1 2/1999
3.1f

32
In-process measures for major accounts are a primary neede
1/12/1999,
1/12/19991,
3.3
!
-
Ma

34
Bltrnfers are a responsibility of the MB platform
12/1999,
999
9991

35
Review Epiphany for ETL tool
16/1 999
33.3
-0.l 1

361
MCKB team should only provide database and integration, Report, Analytics design and build shoul ed
Knowledge Team.
311

NONE
S IM
-m-l!RIS, 71-1 9 7 ' mK.
.
. .
.........