Discussion

balusuyaswanth

Rinker_-_Final_Project.pdf

Home >Information Systems homework help >Discussion

Final Project

New Product Introduction to Manufacturing

Doug Rinker

August 9, 2009

ICT 4010: Enterprise Architecture

Professor Steven Else

Table of Contents

General Background 1

Identification of Major Architecture Issues 4

Analysis of Major Architecture Issues 6

Issue 1 - Integrating Stakeholders / Broader Environment 6

Issue 2 - Knowledge Gaps 9

Issue 3 - Joint Planning 11

Issue 4 - Silos of Data and Systems 12

Issue 5 - Alignment of Business and IT Models 16

Issue 6 - Design-to-Manufacturing Machine Data Transfer 18

Issue 7 - Support of Product/Test Element Standardization 19

Issue 8 - Predictive and First-Build Process Cert Capabilities 23

Solutions 26

Roadmap 33

Appendix (Business Scenario Excerpts) 36

References 45

Executive Summary

This paper describes a project conducted for The Aerospace Company

(TAC) to address a significant set of problems that are limiting the

competiveness of TAC‟s Electronics Operations (EOP) organization.

Inadequate knowledge of optimal product design-for-manufacturability

techniques, and poor integration of organizational processes and data within

EOP, is causing serious readiness problems when newly designed electronic

control products are first introduced to the factory for initial manufacturing.

In analyzing the current state of the organization, its processes, and

information architectures, several key issues and solutions are identified.

The company lacks the needed processes and structured analysis framework

to fully dissect the problems and model proper solutions; the well accepted

TOGAF framework is recommended and architecture solutions and roadmaps

are provided based on the TOGAF‟s architectural development method. The

remedy for the described problems is, essentially, for many stakeholders in

different functions and locations to be able to seamlessly and easily access

and provide timely data when the development process calls for it. To this

end, a product lifecycle management toolset based on a powerful and

efficient service-oriented architecture (SOA) is recommended. This platform

approach provides a supportable, high performance, reliable, scalable, cost-

effective, and flexible solution that can provide for the immediate and future

needs of EOP.

General Background

Note: Although 18 references are cited in the analysis and solutions

sections, this background section contains no citations as the information is

based on my personal recollections of the state of affairs at my prior

employer. No material was referenced to create the background section.

The Aerospace Company (TAC) faces customer-driven and competitive

pressures that require newly designed electronic aircraft controls products to

be introduced to the early manufacturing phase in a much more mature

state, such that optimum manufacturing costs and quality levels can be

reached much more rapidly and efficiently. The primary design center is in

Illinois and the primary factory is in Arizona; however, other in-house design

centers and plants located in other states and in Europe are also involved in

these same supply chains.

Currently, many new electronics products are introduced to

manufacturing with designs, parts lists, assembly processes, supporting

manufacturing technologies, and design documentation that is incomplete

and/or unproven, often requiring one or more years and hundreds of units to

be produced until costs and processes reach a mature “optimum” state;

additionally, the proliferation of previously unused electronic components

(purchased parts) in new designs often result in early supply chain

shortages and special error-prone setups that cannot initially take advantage

of preferred automatic insertion equipment and high volume fixed setups.

These early manufacturing issues combine to create a significant negative

impact to product and organizational cost performance, product quality, and

customer / business unit satisfaction.

The overall electronics product development process has evolved

through a series of process improvement and cross-functional initiatives, but

the key process steps pertaining to production readiness remain too

sequential and are not adequately data-driven. The hand-off of engineering

data to the factory for initial production of units is a done in a manner more

akin to building engineering prototypes in a development lab, and not in a

manner that ensures upfront readiness for the optimal automated

manufacturing processes needed for long term production (and fulfillment of

the product‟s business model).

The following related operational problems are observed:

 The remote plant personnel have difficulty manufacturing and testing

new immature products where support/test equipment, engineering

data, and design “capability” (the ability to consistently meet product

specs, given designed-in natural variation that occurs in assembly) is

inadequate; as a result, the special interim equipment, temporary

manual workarounds (in lieu of optimum automated processes), and

inadequate fault diagnostic support require an inordinate amount of

long distance design engineering support to make critical early

deliveries.

 The profitability of business models for new product development

contracts are often placed at risk due to the higher than expected

costs of early production “learning curve” units, and periods of

“developmental “ manufacturing that last longer than expected.

 Due to these early manufacturing inefficiencies, the ability of new

product designs to meet long term, optimum unit cost and quality

targets cannot be physically verified early enough to efficiently make

any needed design corrections. By the time the true optimum

capability is understood, the design is effectively locked in due to the

heavy investments already made in certifying the existing design for

airworthiness.

 The fully automated manufacturing assembly equipment, which is

geared to support the existing production base of high volume

components, is not exploited, since parts selection for new designs is

not constrained to a set of preferred parts that are already well

supported at the factory.

The project this paper describes is aimed at analyzing these issues

from architectural perspectives, providing solutions and recommendations

for approaching the problems, and providing a preliminary roadmap for

migrating to an improved target architecture.

Identification of Major Architecture Issues

1. Integration of Broader Company Environment

The organization is lacking a formal framework for integrating the larger

company initiatives and goals such that potential synergies and long term

integration/unification opportunities can be exploited in any new

architecture.

2. Knowledge Gaps

The evolution of larger, more centralized organizations has eroded the

total product and lifecycle knowledge needed by team members to

reliably define optimum designs and manufacturing processes for new

products.

3. Joint Planning

The key stakeholder organizations, Engineering and Manufacturing, do

not have adequate mechanisms for jointly setting goals or

defining/funding projects that would better unify their tools and

processes.

4. Silos of Data and Systems

The current architecture does not facilitate straightforward and timely

access to key data across disparate systems and locations, impeding the

integration of processes and key data awareness among design,

manufacturing, and other remote internal and external partners.

5. Alignment of Business and IT Models

Business (product development) process models do not align well with

the data and system models and solution blocks used by those processes.

6. Design-to-Manufacturing Machine Data Transfer

The architecture does not support the seamless transfer of data from CAD

tools to automated shop floor assembly / verification equipment, nor from

automated test/inspection equipment to interested remote stakeholders.

7. Support of Product/Test Standardization

The architecture does not adequately support the creation, availability

and analysis of standardized design element / component libraries that

designers need to effectively design new products, or the associated test

software, based on these elements.

8. Predictive and First-Build Process Certification Capabilities

The architecture does not adequately support, or link, the necessary

modeling and prediction tools/data needed to create early, pre-build

confidence for a new design‟s ability to realize product cost and quality

targets.

Analysis of Major Architecture Issues

Issue 1 - Integrating Stakeholders and the Broader Environment

Business Case. The organization is lacking a formal framework for

integrating the views and participation immediate stakeholders as well the

larger company initiatives and goals such that potential synergies and long

term integration/unification opportunities can be exploited in any new

architecture. The flowdown of strategic plans and top level business

objectives have served their purpose in guiding general, mostly localized

departmental process improvement initiatives, but many of the challenges

and opportunities facing the organization require strong, structured cross-

functional collaboration to achieve the type of holistic full lifecycle product

development and bottom-line improvements needed. Without a structured

framework and a set of guiding methodologies, this initiative is likely to only

result in more local optimizations, less synergy with other potential

benefactors/contributors around the company and industry, and inadequate

understanding and fulfillment of the key stakeholders‟ needs (The Open

Group 2008).

Principles. To define and bridge the new architecture expectations to

top level strategies and objectives that are already in place as a result of

organizational flowdown, a set of more specific principles need to be

adopted. These can make guiding philosophies, preferred methods, and

outcome characteristics clear to all involved. These principles are made even

more effective by publishing them as concise statements, supplemented with

explanations of rationale and the implications of following them (to address

the “why?” and the “what will it cause to happen?” and “how will it affect

me?” aspects) (Minoli 2008).

Teams and Governance. Defining these principles, as well as the

scope of the project, the stakeholders, interested/helpful internal or external

third parties, potential links to other ongoing or planned efforts, and the

make-up of the analysis and solution teams, would be among the first tasks

of the needed EOP architecture leadership team. Since engineering and

manufacturing functional department managers are most knowledgeable and

engaged in current and past improvement efforts, hold many of the key

analysis and solution development resources, and understand the problem

space well, they would be best suited to form the core leadership team. This

team would be supplemented with transformation reps from local and

central IT. Executives responsible for the net end-to-end effectiveness of

these organizations, as well as a sampling of program managers that are

responsible for contracted program execution, should also be engaged in a

steering, review, and advisory capacity.

Framework. To provide structured guidance to this new team,

especially given their lack of experience in formal architecture analysis and

transformation, a formal, well-established, and industry-accepted framework

is needed. TOGAF, and its ADM approach, are a framework and holistic

methodology that are uniquely strong in several key process guidance and

architecture flexibility areas important to EOP (Sessions 2007), including the

creation of a strong business process foundation and clear value linkage

based on the most important business objectives (Beveridge and Perks

2000).

TOGAF and the ADM are very prescriptive and recipe-like, not in

forcing specific models or solutions, but in guiding the phased process of

capturing requirements, engaging stakeholders, modeling and analysis,

solution development, conducting lifecycle iterations, and governance. The

how‟s of each step are flexible, with a range of methods offered, but the

keys are in driving toward the outputs expected from each stage; this

supports stage-gating which is important to keeping a new team on track.

TOGAF is flexible enough to support many types of architectures, integrated

or otherwise, and provides support for newer platform-based styles - like

SOA which has shown to be increasingly important to PLM and integrating

design-manufacturing environments (Deurinck 2007) - all of which is

important considering the EOP legacy assets and the needs for much more

complete integration and openness. Finally, the provision of the “enterprise

continuum concept” that can supply flexible reference models for general as

well as platform, network-based services, seems well suited to handling the

integration of the many dispersed, disparate systems and data-sharing

needs of EOP (Sessions 2007; The Open Group 2008; Beveridge and Perks

2000).

Issue 2 - Knowledge Gaps

Business Case: The evolution of larger, more centralized

organizations has eroded the total product and lifecycle knowledge needed

by team members to reliably define optimum designs and manufacturing

processes for new products. This phenomenon appears to be typical of

organizations that, for growth and cost efficiency reasons, have migrated

from smaller product-focused groups where total product ownership and

lifecycle knowledge is tribally strong, to large matrixed everyone-serves-all

organizations where local processes are optimized but overall product and

lifecycle knowledge are lost. The impact of such a loss of knowledge means

upfront designs are inadequate from a manufacturability standpoint, and

many of the undesirable features get locked-in due to the difficulty in

making downstream changes; upfront awareness of optimum design and

manufacturability considerations are key to producing competitive products

and avoiding costly backend overruns and delays (Sherman 2008).

This impact of lacking key “global” knowledge is amplified in the EOP

case, given that knowledge is not only needed upfront about specific product

family success factors, but also about the new company-wide standard

design elements, which are aimed at solving many of the engineering-

manufacturing cost and speed problems through platform and modular

element re-use concepts applied at the product level; without a level of

knowledge about these standard elements, the pay-off and cost

improvement strategy, and the ability to access data about them on-

demand, designers will revert to designing with their own personal set of

preferred parts.

Supporting Data and Tools. Several specific type of data and tool

capabilities rise in importance when addressing these knowledge gaps.

Architectural focus must shift toward PLM-type data, applications, and

services that work well across many locations and provide data where and

when it is needed to any interested member of a new product‟s engineering

or manufacturing team (Sherman 2008; Gould 2008). The standards

mentioned above must be readily available along with the supporting data to

support design analysis when these elements are used.

Enhanced, universally accessible cost/simulation models are also

needed to allow designers to evaluate preliminary design data for

compliance and to see the true cost impact of using or not using preferred

elements (for the inevitable trade-off situations). These models also can

serve to “educate” and fill knowledge gaps by showing designers how

parts/circuits they perceive as non-optimal are actually less costly when all

direct and indirect production costs are considered. Not only do designers

need ready access to these interactive modeling applications, but those who

understand the underlying cost standards must continually evaluate and

update the database used by the model to ensure an accurate reflection of

manufacturing capability and all significant cost drivers. Key tools such as

this, where there is heavy user interaction by a variety of players with

different roles, require stakeholder views to be formally developed and

analyzed to ensure that architectures and solutions provide the proper utility

and ease-of-use (The Open Group 2008).

Issue 3 - Joint Planning

Business Case. The key stakeholder organizations, Engineering and

Manufacturing, do not have adequate mechanisms for jointly setting goals or

defining/funding projects that would better unify their tools and processes.

Without such joint planning, the business performance goals of speed, lower

cost, and initial quality will not be met because the critical flows of

information between the organizations will not be properly designed process-

wise, or adequately supported by infrastructure. The type of integrated

architecture needed, where lifecycle management is supported through data

available to all that need it in a form they can use, can only come about with

a coordinated architectural effort and a sharing of responsibility for it and

the products that flow through the system.

Care and Feeding. It would seem that the joint architecture

leadership team would make this coordination happen naturally, but this

manufacturing organization, like many, suffers from years of operating in a

local, self-sufficient, tightly-constrained investment environment where most

planning was tactical rather than strategic (Masson 2006). All parties,

particularly manufacturing, will need to be groomed and educated as to the

big picture significance of the project, the important empowered role they

play in it, and the critical knowledge that only they possess (but must be

shared).

Issue 4 - Silos of Data and Systems

Business Case. The current architecture does not facilitate

straightforward and timely access to key data across disparate systems and

locations, impeding the integration of processes and key data awareness

among design, manufacturing, and other remote internal and external

partners. The lack of freely flowing information prevents designers from

understanding new product cost, quality, and test performance in early

builds when timely corrective action is most important, slows assembler

access to proper work instructions and operating theory, and reduces the

ability for all stakeholders to use and maintain critical knowledge-based

models and simulations for predicting and driving designs to the best high

quality and lowest cost practices. These constraints place the timely delivery

of profitable, high quality products at significant risk.

The Manufacturing Lag. The current silo-like architectures are to

some degree the result of past business paradigms that many manufacturing

enterprises suffer from (including this one), where individual sites became

very frugal, independent, and relied on low cost home-grown solutions on

local networks and workstations for self-sufficiency and a perceived sense of

destiny control (Masson 2006). The limited architectures caused by these

factors have continued to exist even though modern open-system wide-

network architectures, such as SOA, have very high promise in

manufacturing environments (Masson 2006) (especially where there is a

need to interact seamlessly with a variety of other remote lifecycle and value

chain partners as is the case in EOP). The joint leadership team and the big

picture objectives of the architecture, along with the views captured from

other key stakeholders outside of manufacturing, should all help in getting

the new cultural alignment needed.

Identifying the Operating Model and Maturity Stage. Taking a

view of the operating model and maturity stage positions for the desired new

architecture helps to understand the architecture direction and style needed.

Since the best practice improvements such as standard design elements and

standards-based test equipment are being sought across an environment

consisting of multiple design centers, and multiple product line centers

within the factory, the operating model now needs to be one of unification

(with a small amount of replication in those cases where some business

units need to retain more independence in their operations).

As this unification occurs, the architecture needs to move from the silo

and partial technology standardization stages, to the “optimized core” stage,

at least with respect to the PLM and supporting platform that enables the

types of data interactions targeted in this project. It also stands to reason

that this new architecture could readily mature to the very powerful

“business modularity” stage (Ross, Weill, and Robertson 2006) if the

platform, low level service blocks, and API/network standards are deployed

in a manner that allows for easy combining and orchestration by new

applications.

Alignment with a Platform Approach. Given this desired and

needed shift in operating model and architecture maturity, there is a clear

need for a high performance platform approach that allows free access to

data from disparate systems, across high speed networks within and

between remote sites, with results and interfaces easily tailored to the needs

of the stakeholders in engineering, manufacturing, management, and

interested product program leaders. The availability of the general purpose

TRM and III-RM (a data-oriented platform reference model, fit for the needs

here) seem like good starting points for general guidance on the analysis

and alignment of data flow, applications, services, and interconnecting API

and network infrastructure layers. Given the easy access of all organizations

involved to standard local and high speed WAN IP-based services, the lower

level communication layers are quite appropriate.

Industry Trends and Successes. The literature shows that, in

recent years, several manufacturing organizations (even electronics ones

focused on integrated product development) have had very good success

achieving similar goals with formally developed PLM platforms, some of

which were implemented very successfully using SOA where there were a

number of remote stakeholders requiring similar services and a high degree

of data interaction and collaboration (Gould 2008; Deurinck 2007). Such

approaches were also proven to be keys to success in solving organizational

knowledge gap problems (P&G) of the types that EOP has (product lifecycle

knowledge, cross-program lessons, and company-wide initiative support

such as standard design elements) (Sherman 2008). Furthermore, and even

more recently, Manufacturing Operations Management (MOM) service based

systems that ride on standard SOA offerings are emerging, specifically

targeting the problems of global access and control of pre-production

engineering changes coordination and accounting (even for highly regulated

aerospace companies), easily developed and accessible illustrated work

instructions, tight CAD data configuration management, and quality

feedback and analysis from test and inspection; these features can exist

while integrating new or existing PLM tools or any other legacy applications

(Gould 2008; Sherman 2008; Business Wire 2009; Elam 2005).

The review of these industry experiences are not to form a foregone

conclusion toward a specific solution, but to show that more companies with

similar challenges are moving to PLM, and even MOM, via SOA due to its

flexibility and ability to adapt and seamlessly connect previously isolated

applications and data stores, using granular reusable services that are

available to everyone; such a platform style should lay nicely onto the

generic TOGAF TRM and III-RM starting architectures, and fits well with the

needs of EOP. Most of the other architecture issues relate to the current

silo‟d architectures, and become easier to solve with such a platform as a

foundation for all stakeholders to utilize.

Issue 5 - Alignment of Business and IT Models

Business Case. Current business (product development) process

models do not align well with the data and system models and solution

blocks used by those processes (one of many current shortcomings). Given

that a service-oriented platform approach to the new architecture seems

appropriate (see last section), defining business processes in a way that will

match up well with collections of low level services becomes even more

important, and possibly more difficult. Without such alignment, service

functionality may miss the target and the flexibility, reuse, interoperability,

and thin application expectations of SOA will not be met (The Open Group

2008). This would translate into higher costs, greater customization of

solution blocks, lower performance, and reduced supportability.

Appropriate Business Modeling. There are a few strategies that

need to come into play here to prevent service blocks developed

downstream from not meeting their intended usefulness in meeting the

product development business objectives. Each strategy supports the

concept of fully defining processes, using perspectives and methods that

create definitions best aligned with the modular and fairly granular service

boundaries.

First, one of the TOGAF‟s ADM strengths is the emphasis placed on

business architecture, and the detailed modeling of business processes so

that they can serve as meaningful multi-view requirements for the lower

level architectures. With this focus, and the wide variety of modeling

methods supported, the ADM is well particularly well-suited to guiding the

translation of business requirements and processes into meaningful service

requirements (The Open Group 2008).

Since services are intended to be loosely-coupled abstractions of

operations that hide their data, and to interact with other layers and services

using simple, asynchronous requests and messages, modeling the business

processes they support in a similar fashion merits consideration. Success has

been demonstrated by manufacturing companies using a GRAI grid to model

the event-driven and data interactions between manufacturing and other

product development functions, using both near term (real time operations)

and longer term (planning) time horizons for the analysis (Tucker and

Leonard 2001); this provides a view of functional interaction that may align

well with some service definitions. Another manufacturer made use of OOA

methods to create a reference model of what they called the “fuzzy front-

end “ of new product introduction to manufacturing (Williams, Kochhar, and

Tennant 2005); OO methods provide encapsulation, event-driven

interactions, and data abstraction in a manner that might prove useful as a

requirements format for services (since services has similar attributes).

Issue 6 - Design-to-Manufacturing Machine Data Transfer

Business Case. The architecture does not support the seamless

transfer of data from CAD tools to automated shop floor assembly /

verification equipment, nor from automated test/inspection equipment to

interested remote stakeholders. One of the most fundamental features of an

optimized new product engineering-manufacturing interface is the automatic

transmission of CAD data to automated shop floor equipment, without any

need for human intervention. Anything short of this could cause costly

delays in manufacturing readiness, slow response to urgent changes, and

operator-induced translation errors that could lead to scrap and rework.

Standards. Until recently, the most common and well-supported data

standards for communicating CAD outputs have been inadequate to convey

all information needed for high quality assembly, and better standards were

so numerous and varied there was no broad support for complete tool sets.

This is one reason that this problem has not been remedied. Recently, NEMI

has taken the lead in integrating two of the most popular and capable CAD

output data standards (GenCam and ODB++). This is leading to complete

toolsets that fully support the communication of this CAD and BOM data to

all popular forms of electronic manufacturing equipment in machine-usable

formats (Allen and Bergman 2001). The new architecture should attempt to

integrate these standards and tools into the machine communications layers

of the architecture platform.

Issue 7 - Support of Product/Test Element Standardization

Business Case. The architecture does not adequately support the

creation and dissemination of descriptive and analytical data for

standardized design elements and preferred component libraries (i.e.,

preferred common circuit design blocks and preferred purchase piece parts

that can be accommodated on a single, permanent manufacturing assembly

equipment setup. This well-conceived, powerful, and differentiating

enterprise-wide initiative has consumed a large amount resources and time

to develop, and is one of the major cornerstone strategies (aside from this

project) for expected improvements in electronics design and manufacturing

non-recurring and recurring costs, quality, and speed. Unfortunately without

the IT architecture to make the related technical and decision support

systems available to all sites involved (in a highly usable form for any

particular stakeholder type), the initiative will likely suffer from the “doom

loop” syndrome; this occurs when breakthrough change is attempted

through rhetoric and exhortation without the time to develop the necessary

knowledge, tools, and understanding needed by those who must implement

and support the change locally (Sherman 2008).

Power of the Product Platform. The concepts in the following

subsections analyze the needs and possible approaches to meet these goals.

Interestingly, this “platform” approach to product and test equipment design

may be one of the greatest enablers to addressing the major problem set

forth in this project; that is, providing full production ready designs,

documents, and equipment when first needed by the early pre-production

builds in the factory. Standard circuits reduce design time, qualification time,

bring established quality, allow for lower costs through less inventory and

re-use of existing assembly set-ups that require no changeover between

products, and once learned, are much more supportable by all involved.

Likewise, standard testing blocks applied to these standard product features

becomes a matter of assembling existing interface connection schemes and

existing software test blocks, the avoidance of custom test hardware and

software development means on-time delivery of test equipment, lower test

costs, less unique and capital-intensive equipment, and less integration and

debug time due to pre-established performance and quality.

Extreme Competitive Advantage. Said another way, this product

platform design approach brings to product design and manufacture many of

the same advantages that III-RM or SOA-type platforms bring to IT

architectures. Combining these strategies in the same business has the

potential to create a very competitive business approach in a complex and

inherently high cost industry. Neither strategy can deliver full value without

the other.

Enabling a “Product Platform” Approach. The architecture must

make the preferred circuits and component information available on

demand, as designers need it at their workstations or in design reviews. For

a designer, the the information database must provide circuit diagram views,

allow for the circuit or component to be extracted and “placed” into an actual

design schematic, provide analysis, specs, and theory information needed

for him to correctly “apply” the design. Manufacturing assembly, testing,

and process developers will need their own unique views with data most

suited for developing physical processing of the parts or for testing and

troubleshooting circuit and component functions. Another class of

stakeholder will be responsible for managing changes to the approved

standard and related data, as well as modifying the standards database

accordingly.

Cost models and simulators will need to reflect the true cost of

assembling and testing standard components in comparison to traditional

products with fully unique and custom designs and BOMs. Designers will

need to be able to readily access these tools and provide them with snapshot

version of preliminary designs; in return they will receive high confidence

aggregate and itemized cost estimates for their designs. Such feedback will

not only be essential for confirming early compliance with cost targets, but

also for performing trade-offs in non-ideal situations and for learning the

true total cost benefits of using standard elements (which many designers

initially believed to be more expensive due their traditionally limited

BOM/material-oriented perspective on cost) – this is a key part of the

knowledge gap closure process. Additionally, these tools can be used to

confirm compliance, or violations, in the use of standard design elements,

triggering the necessary exception reviews as appropriate.

Currently, these tools and data are made available through adhoc

portals (that each require access rights not available to all stakeholders).

These portals provide less than optimal access to multiple databases and

provide limited viewing capabilities. Also, the maintenance of this

information must involve multiple experts due to the specialized and

separate systems involved. All of this causes delays and inaccuracies due to

staleness and synchronization problems. The requirements suggests a

single, easy-to-maintain relational database that is capable of storing,

retrieving and displaying disparate types of data (some graphics, some text,

some design tool models) in a format appropriate for different stakeholder

types through commonly available network services with common access

and view configuration services that work reliably regardless of location.

Enabling a Corresponding “Test Platform” Approach. To dovetail

with, and further extend the improvement leverage of common product

circuits and parts, the test equipment design must be developed using test

requirement blocks and automated testing blocks (software source code that

runs interpretively on a standard automatic tester) that directly correlate

with the standard circuits used in the product design. The needs of

stakeholders and the supporting IT architecture are analogous to those

described above for the standard product design elements.

The benefits are potentially quite large. One of the biggest stumbling

blocks to smooth early production readiness is the late delivery of full-up

automated test systems. This approach removes much of the test and

equipment engineering lead time in that it allows starting earlier at the

product “block” diagram phase, and allows for simply assembling hardware

and software test blocks instead of engineering intricate custom test

solutions for each product. Additionally, integration and test equipment

debug time is reduced significantly since the building blocks are already

proven.

Issue 8 - Predictive and First-Build Process Certification Capabilities

Business Case. The architecture does not adequately support, or link,

the necessary modeling and prediction tools/data needed to obtain early,

pre-build confidence for a new design‟s ability to realize product cost and

quality targets. If contracted program business models are to be upheld and

the expected profitability delivered, it is essential that these parameters be

confirmed as early as possible in the development cycle. Without this

confidence, any misses will not likely be fully recognized until after many

units have been produced and factory complaints begin to filter back, at

which time it is often too late to affect any major corrective redesigns due to

costly product qualification and aircraft certification efforts that are already

complete or underway.

The Tools Challenge. The issues involved in understanding and

addressing this problem overlap somewhat with the standard product

elements issues discussed in the prior section. The standard element design

libraries and simulation/modeling tools must make known cost and quality

performance (e.g., CpK or defects/unit) available for those reviewing the

design while it is in progress. The database feeding those models must be

updated regularly with actual test and inspection quality feedback from the

shop floor equipment. Additionally, designers and manufacturing process

owners must be able to review the automatically collected records of

inspection and test on any particular production unit, or set of units. This

allows analysis of product and process performance down to the circuit,

component, and assembly process level. This type of data must be acquired

and stored for instant access on even the earliest units as another means of

verifying new product capability and cost; for this to be possible the required

automated inspection and test equipment must be programmed and

operational for the first units (which underscores the importance of the

earlier availability of standardized test solutions, as described in the prior

issue section).

Literature shows that service-oriented applications are commercially

available for real-time quality and test data collection, analysis, and

reporting, including the ability to report on what-if predictive impacts on

yields and test coverage (Helsel 2005; Elam 2005). However, a total solution

must be able to integrate such applications into the larger service platform

to make the utilities and data readily available to all interested stakeholders,

regardless of location.

Solutions

Issue 1 - Integrating Stakeholders and the Broader Environment

Recommended Solution. TOGAF and its ADM are recommended as

the framework and methodology to address overall process, stakeholder

views and engagement, requirements and company environment

considerations. The reasoning for this and the associated leadership

approach is detailed in the analysis section.

Alternatives: The other option considered was to expand the local

improvement frameworks (implemented via company improvement

standards) to include the cross-functional scope of the product development

process and new product introduction. This idea was rejected because of the

lack of phased analysis, requirements management, and prescriptive

processes present in those frameworks.

Issue 2 - Knowledge Gaps

Recommended Solution. A formalized PLM structure is

recommended (for this as well other issues involving broader access of

product development data), using the P&G MEGA models for guidance on

emphasizing data and outcomes versus work process detail (Sherman

2008), but implemented on SOA as described in Issue 4. This structure will

allow key information on early product quality (either predictive or actual),

test effectiveness, and product/test design element standards to be available

to engineering and manufacturing stakeholders as needed in appropriate

formats. The simulation and modeling tools that will be universally available

from this platform will provide educational reinforcement as to the true value

of standardized product elements, and proper matching of design features

with manufacturing capabilities, in the context of any actual product‟s design

data. Work procedures and stage gate review criteria will be modified to

require the use of these tools to support quantitative review criteria for the

design as it progresses. The PLM tools and supporting platform architecture

will support a common database supported common services to ease access

and support of data by all stakeholders and applications.

Alternatives. Enhanced web portals were considered but rejected

because, although user interfaces could be improved, this approach did not

address the underlying issues of having too many data and application silos

and thereby inhibiting common data management and shared services.

Issue 3 - Joint Planning

Recommended Solution. The solution, and the alternative, for Issue

1 addressed this issue as well. The ADM business architecture and models

fully integrate and unify the requirements, interactions, and architectures of

both organizations.

Issue 4 - Silos of Data and Systems (and a service platform solution)

Recommended Solution. Several key factors of the goals and

current problem space, including the unification operating model and the

unified core maturity stage being sought (Ross, Weill, and Robertson 2006),

aligned well to the capabilities of SOA, as described in this issue‟s analysis

section. The overall architectural solution is recommended to be one of SOA,

with more specialized PLM and analysis services and applications layered on

top of it; the use of SOA to support PLM and engineering/manufacturing

interactions has been shown to be quite successful in more recent literature,

as described in the analysis section. This provides the best blend of

maintaining the necessary, unique legacy equipment and tools needed for

specific CAD and factory automation operations, but allows common, more

standard services to be shared across the entire landscape. It also enables

common data storage and management so that separate pockets of less

accessible, less integrated data (and its special support) can be eliminated.

Other key features of SOA important to this problem space are 1) much

tighter integration among the many remote stakeholders who all have a

common interest in data in other locations, 2) reusable, repeatable, and

relocatable processes and services that can easily be adopted for new

stakeholders and new needs in the future regardless of location, and 3) the

greater granularity of core services allows for them to be combined in new

ways as process needs change (Deurinck 2007).

Commercial packages. In the literature reviewed, many

commercially available solutions exist that, due to the open standards used

for interface layers and communications infrastructure, can be readily

adapted as a backbone and service platform for this architecture. It is

recommended to purchase at least the core service infrastructure of the PLM

and SOA, as there is inadequate in-house resource and experience to take

on the complexities of developing a general purpose platform. Several strong

contenders were found in reviewing literature and recent articles. Perhaps

the most complete solution for advanced, SOA-based PLM “2.0” functionality

is the V6 system from Dassault (Gould 2008).

Like most contenders it supports the quality, test, work instruction,

and tight CAD and configuration management integration needed to handle

the high number of engineering changes that occur early. This system is

heavily used in the automotive industry but has also extended functionality

that supports CAD and data types more associated with electronics and

aerospace industries (one concern that would require further research and

consultation is the extent to which it supports electronics development, since

its roots are in mechanical engineering environments; however, an

interesting opportunity arises as to the extent this system could also be

readily leveraged by the mechanical products side of the company, making

long term leverage and near term executive support possibly stronger). V6

has a key set of advanced virtual 3D interaction and “social networking”

tools that allow online 3D visualization of product and equipment by all

stakeholders, even those who are not CAD users; such collaborative features

place this product in the coveted “PLM 2.0” category, and seem well suited

to helping to solve the knowledge gap problems addressed by this project.

The SOA architecture supplied to support this PLM allows for all other legacy

data systems, CAD tools, and disparate applications to be wrapped and

tightly linked in as necessary. A key feature is the strong support for single

centralized database and data management services which would be key to

unifying and improving access to the many types of currently separated data

in the EOP organization by all partner involved organizations regardless of

their location. In terms of transitional roadmap support, Dassault provides

the PLM services as an online pay-as-you-go software service model,

allowing new users and who want to ease into SOA without heavy upfront

learning curves and support to do so (this could be a key option for EOPs)

(Gould 2008).

Existing cost and quality estimating tools which focus on the standard

design element usage issue, along with specialized, commercially available

analysis tools such as SigmaSure for quality statistics analysis and yield

predictions, and FaultDetective to assess and report on test effectiveness,

are recommended as bolt-on applications to the SOA architecture. This

ensures a rich out-of-box feature set exists in these key areas. They would

be wrapped into the SOA application API layer to assure consistent

widespread access as described above (Helsel 2005; Elam 2005).

Constructing the Platform Solutions from Reference Models. The

TOGAF III-RM service-based data exchange model should be used as a

starting point, because it is flexible, yet loosely aligned with the SOA style

that is targeted, provides for IP-based communications, and the common

services (applied from the TOGAF TRM) needed for the overall PLM, such as

security, single database and data management, data format translation,

network communications, and user interface. The specific services from a

vendor solution such as V6 would be selected based on need and populated

as a refinement to the model. Legacy assets or new applications that must

be maintained due to their specialized features (such as specialized CAD

tools, low level machine data translators, specialized SPC analysis tools, test

data capture tools, programmable shop equipment, etc.) would be wrapped

so that they could communicate with the rest of the architecture services

through the standardized SOA APIs, allowing consistent data management

and user interface SOA services to be exploited and making the legacy tools

fully accessible by all. The mentioned TOGAF models, any industry models,

and refined models created when solution blocks are identified and plugged

in, would be placed in the enterprise continuum repository to maximize

reuse of internally and externally created models (Gould 2008; The Open

Group 2008).

Alternatives. Other potentially useful PLM and SOA solution blocks

used successfully by other electronics firms could come from iBASEt and

Solumina (though these require a significant investment in SAP business

systems)(Business Wire 2009) or from service bus solutions such as

WebMethods, which would require more in-house development of higher

level services (Smith 2008). These would all be carefully evaluated along

with the V6 option using decision criteria in a tool such as Accord; criteria

would need to include the support of low level manufacturing data

standards, use of open standards and open development tools, embedded

management capabilities, ease of integration for existing applications that

must be maintained (Robust Decisions 2008).

Issue 5 - Alignment of Business and IT Models

Recommended Solution. As discussed in the analysis, it has been

shown that OOA methods can be used to effectively model business

processes for product introduction into manufacturing (Williams, Kochhar,

and Tennant 2005; Minoli 2008), and it seems this type of event-driven and

encapsulated type of process modeling might lend itself better to service

solution block definitions since they have similar characteristics. The UML

modeling language is recommended for this since it is commonly used, is

flexible, supports OO methods well, and is rich in constructs (Minoli 2008).

Issue 6 – 8 Solutions

The solutions for issues 6 through 8 are supplied by the service based

architecture and solution blocks described under Issue 4, which serve to

fulfill the detailed expectations and guidance described in the issue analysis

sections. Note that for issue 6, the SOA services are expected to support the

NEMI ODB++ CAD output data standard the NEMI helped drive as the

leading industry standard (Allen and Bergman 2001).

Roadmap

Migration Planning Considerations

The roadmap in the table below shows the 6 major phases

recommended for migrating to the target architecture, along with duration

and key activities and milestones. This plan assumes that the TOGAF ADM

phases up through “E” have been completed, which obviously would lead to

further plan refinements. These phases recognize that a series of smaller,

transitional steps, with incremental improvements for the stakeholders, are

important to managing risk, addressing lessons, and maintaining stakeholder

support (The Open Group 2008). The rationale for the sequence of activity is

to bring important, and relatively straightforward functions online first, while

giving more time for the more complex efforts (such as the consolidation of

databases).

The plan estimates should be refined with a tool such as SEER which

can bring experiential fidelity to the costs, resources, and time needed for

each phase. Caution should be taken in overestimating the ease with which

SOA-based systems can be developed. The Software Engineering Institute

has pointed out that purchased SOA-based systems are patterns with

supporting products, but do not provide complete architectures out of the

box. They also note that the cost of integrating legacy tools can be

significant, standards help interoperability but don‟t guarantee it, and initial

testing can be more challenging due to the many possible paths and

asynchronous nature of service communications (Galorath 2008).

Six Phase Migration Roadmap Table

Phase 1:

3months

(assumes

prior

completion of

ADM phases

A-E)

1) Utilize Accord and SOA SBB decision criteria

described in Solutions, Issue 4

2) Complete automatic data transfer; temporary

solution to allow direct CAD programming of

automated shop equipment

3) Complete standard product/test design element

definitions and education using current systems

Phase 2:

5 months

1) Procure and install basic SOA package and initial

services for establishing basic network

communications for data transfer and basic access

to legacy test and quality point databases.

2) Conduct focused IT training on SOA architecture,

app development strategy, interfaces, and SOA

management tools

3) Procure specialized quality and test analysis

applications and begin SOA app wrapper

development.

Phase 3:

5 months

1) Bring basic SOA communications layers and

services online, along with SOA-enabled CAD-to-

shop data transfer capability.

2) Develop wrappers for legacy assets that remain

(permanent) and modeling/prediction tools and

standard design element library databases

(temporary)

3) Begin development of central SOA database that

will replace most all legacy point databases

Phase 4:

3 months

1) Integrate legacy assets and tools from phase 3

into SOA application API layer

Phase 5:

3 months

1) Integrate new single database (from phase 3) and

populate with data from legacy systems; maintain

old data base connectivity for fallback until project

completion.

Phase 6:

4 months

1) Conduct integration testing across the complete

system.

2) Define needs for additional SOA management

tools based on experience to date with embedded

tools in monitoring and diagnosing problems;

evaluate and install appropriate commercial

solutions.

3) Compare user experiences with that called for in

business scenario (see appendix).

4) Analyze performance against requirements, and

determine what if any ADM phases should be

iterated to address gaps.

5) Systems are available and fully operational for

key stakeholders at the end of this phase.

Appendix

Business Scenario Excerpts

The following appendix sections are excerpts from the earlier Business

Scenario developed for ICT 4010. This scenario was written for the same set

of problems that this paper addresses. These sections provide additional

detail into stakeholder roles and interests, and provide a more detailed

description of needed outcomes and capabilities. These expectations could

be used to evaluate the adequacy and focus of the architecture definition

and solution decisions as the team progresses through the ADM phases (The

Open Group 2008).

Detailed Objectives and Requirements

Objectives and Requirements for Product Design Tools. Product

designers must be provided with desktop-accessible tools and data for

choosing from standardized design solutions and features that will yield the

best results for low cost, high quality, rapid start-up manufacturing.

Specifically:

1) A limited set of clearly defined, cross-functionally approved

preferred parts and circuits must be defined and released to a

design standards repository that is read-accessible by all

stakeholders, and write-accessible by a cross-functional design

standards committee that must initially create, and then approve

any changes or additions to, the preferred list; such a capability

must be based on the existing parts database infrastructure and

be in place within nine months to support the launch of several

major programs that will pilot this new “platform” approach to

product design. The rationale for this objective is to support

optimal design decisions that are best aligned to the interests of

components engineering, the overall design community,

purchasing, and manufacturing; as such this database must

provide the technical data needed to facilitate design analysis as

these components are incorporated into the design so that use of

the database becomes the path of least resistance for busy

designers. With respect to early manufacturing optimization, the

new preferred parts list will be constrained such that all defined

parts can be supported as permanent, automatically replenished

setups on the automated insertion equipment (thereby

eliminating early manufacturing shortages and special setup-

related errors, costs, and delays). Finally, by using standardized

circuits that have already been proven to meet a known set of

requirements, a significant driver of prior design maturation

delays can be eliminated.

2) An online, desktop-accessible cost modeling tool must be

developed that allows product designers to submit snapshots of

design and parts list data and then receive detailed

manufacturing cost estimates based on a database of actual

manufacturing cost standards associated with specific design

features; this capability must be deployed within nine months and

must be based on the technology developed in TAC‟s

manufacturing cost modeling pilot project XYZ, where vendor

expertise is used to create the detailed models based on plant

standards and process expert interviews. The rationale for this

objective is that designers can verify their designs for optimum

manufacturability at any time, as well as try what-if scenarios for

competing options. The automatic analysis and easy access of

this tool should make it the preferred design approach for

designers, and gives them instant and painless access to the

“voice of manufacturing” much early and often throughout the

design cycle. This capability not only helps to make designs

optimal from the outset, but alleviates time consuming

manufacturing reviews and feedback that previously were done

late in the design cycle when modifications were much more

difficult to make. By checking and tweaking designs often to best

match up with manufacturing capabilities, the ability for initial

design releases to be first manufactured on standard automated

machines with established setups is greatly enhanced.

3) An online, desktop-accessible tool for designers to easily access

and view remote manufacturing inspection reports, test results,

and optical imagery of early manufactured circuit card assemblies

must be deployed within nine months; this shall be based on the

current localized factory processes for collecting such data, but

the data storage architecture must be modified to accommodate

remote read-only access by design engineering stakeholders. The

rational for this objective is to give designers free and easy

access to real-time factory quality data (even for first-run units),

allowing design-induced defects to be addressed, and refinements

made, well before the design must be locked down. This timely

form of feedback also allows designers and program managers to

determine if design objectives for manufacturability and quality

have been reached before the formal production readiness

milestone arrives.

Objectives and Requirements for Test Equipment Tools. Just as

product designers will improve early manufacturability through increased use

of standard parts and circuits that align with factory capabilities, test

engineering must take advantage of this same standardization as a means to

have full automated test capability in place for early manufacturing of new

products. Specifically:

1) Test equipment engineers must develop a set of cross-functionally

approved, standardized, production tests (textual descriptions and

associated software blocks for test automation) that correspond to the

standard circuits described in design objective 1; these standardized

tests must be compatible with the generic standard automated test

platforms already deployed in the factory. The rationale for this

objective is that standard test blocks (and associated automated test

software blocks) that are aligned with standard product circuits, can

dramatically speed up the deployment of high quality automated test

solutions. This allows initial manufacturing of a new product to enjoy

the repeatable, thorough, and fast, automatic nature of such testing,

thereby reducing learning curves, improving diagnostics, and providing

full design and manufacturing verification on even the earliest

production units. The faster availability of test systems in this

approach is based on the speed by which standard test building blocks

can be assembled (both for test documents and for test software)

without the lengthy analytical and engineering work previously needed

to create custom test solutions for every new product.

2) An online desktop-accessible test data system must be deployed within

nine months that allows test designers, product designers, and factory

test technicians to access and analyze automated product test results,

as well as allow for storage and retrieval of the standard test block set

used for testing any particular new product; this test block set data

serves to provide a modular technical reference for developing and

viewing the test specification, as well as for driving the automated test

software system (in this way, the test specification and test software

become available at the same time and remain in sync). The rationale

for this objective is to eliminate the need for custom test software

development by automatically interpreting and executing the specified

standard test block sequence, thereby dramatically improving initial

test quality and speeding up the development and readiness of fully

automatic testing. The availability of test results data to all

stakeholders allows for early and frequent analysis of test

measurements, and early detection and correction of any marginal

circuit designs.

Process Update Objectives. The stakeholder processes that make

use of the improved technologies (as described above) must be

institutionalized through “standard work” procedure revisions within the

affected departments. This ensures consistent application by way of the

standard work gateway reviews conducted in each new product development

program.

The Overarching Bottom-Line Objectives. The following objectives

define the ultimate business results expectations from the new capabilities

defined in this business scenario:

1) The actual optimum cost and defect rates achieved by new products in

manufacturing cannot exceed design targets by more than 5%.

2) The optimum defect rates and cost targets must be achieved within

three months of first unit manufacture, or by the tenth unit, whichever

occurs first.

3) Optimum performance as described in objectives 1 and 2 must be

achieved using fully documented designs and tests, fully automated

testing, and the fully automated manufacturing assembly processes

intended for long term production.

Actors and Roles

Product Design Engineers. Create the product design data that is

electronically transferred to the remote factory. Must utilize the standard

circuits and parts tool to select design elements. Must utilize the cost

modeling tool early in the design to verify and optimize the design to meet

planned cost and quality targets. Must review defect data from the plant to

address any shortcomings in the design that become apparent during initial

manufacturing. Must iterate the design if manufacturing data indicates that

cost or quality targets are not being met.

Test Equipment Engineers. Create the automated test system

solution in time for manufacturing to use for initial manufacture of a new

product. Must support the development and use of standard test blocks that

correlate with the standard test circuits used by the product designers. Must

utilize test results data from the factory to determine proper operation of the

test system. Must ensure that the software blocks that implement the

standard circuit test definitions are accurate and performing correctly on the

target test platform.

Manufacturing Engineers. Must ensure that standard circuit and test

definitions are in line with the preferred, automated capabilities of the

factory. Must ensure that the manufacturing cost modeling tool used by the

design engineers is populated with accurate estimates and standards that

are agreed to by the factory. Must access the defect database to understand

and act on any manufacturing process issues, and ensure that engineering is

aware of any design-related defect trends.

Manufacturing Test Technicians. Must access and execute the

appropriate test block sequence released into the database by test

engineering. Must access test result data to carry out diagnostic and repair

operations.

IT Staff. Must revise the detailed architecture requirements for the

tool systems that this scenario‟s changes are based on, and carry out the

implementation of solutions within the required nine month time frame.

Tools for Data. As described in the objectives sections.

Stakeholder Views and Models

The detailed views for the stakeholders mentioned as actors above,

and the models of information and data architectures will be defined in a

future iteration of this scenario as part of the detailed business process

modeling to be developed in the business architecture phase of the ADM.

References

Allen, R., and Bergman, D. 2001. All together now: design data exchange for

new product introduction. Circuitree 14.6 (June): 106.

Beveridge, T., and C. Perks. 2000. Blueprint for the flexible enterprise.

Intelligent Enterprise 3 (4).

Business Wire. 2009. iBASEt‟s Solumina manufacturing operations

management (MOM) leverages latest SAP services oriented

architecture (SOA) for aerospace and defense companies. Business

Wire (March 31).

Deurinck, P. 2007. The new biopharmaceutical blueprint: service-oriented

architecture in manufacturing. Pharmaceutical Technology (2007): S6.

Elam, E. 2005. SigmaQuest manufacturing insight software, SigmaSure, now

available on service-oriented architecture. Business Wire (Oct 24): 1.

Galorath, D. 2008. Some gottchas of estimating service oriented architecture

systems (SOA). http://www.galorath.com/wp/some-gottchas-of-

estimating-service-oriented-architecture-systems-soa.php (accessed

August 9, 2009).

Gould, L. S. 2008. PLM gets unified: basing PLM on a service-oriented

architecture makes a „single source for truth‟ possible, helps broaden

the PLM „footprint', and brings enterprises closer to integrated

manufacturing. really. Automotive Design and Production 120.7 (July):

46-48.

Helsel, B. 2005. Test optimization for a new product introduction. Evaluation

Engineering 44.3 (March): 13.

Masson, C. 2006. SOA can light up manufacturing IT. Computer Weekly (Nov

14).

Minoli, D. 2008. Enterprise architecture a to z. Boca Raton, FL: Taylor &

Francis Group.

Robust Decisions, Inc. 2008. Accord users manual - version 2.5. (accessed

August 9, 2009 from the document sharing area of Denver University

ICT 4010 online course).

Ross, J. W., P. Weill, and D. C. Robertson. 2006. Enterprise architecture as

strategy. Boston: Harvard Business School Press.

Sessions, R. 2007. A comparison of the top four enterprise-architecture

methodologies. (accessed August 9, 2009 from a syllabus link page of

Denver University ICT 4010 online course).

Sherman, B. 2008. Product lifecycle management (PLM) & MEGA. (accessed

August 9, 2009 from the document sharing area of Denver University

ICT 4010 online course).

Smith, R. 2008. Electronics manufacturer leverages service-oriented

architecture into a higher level of customer service. InformationWeek

(Sep 15).

The Open Group. 2008. TOGAF version 9. USA: The Open Group (accessed

August 9, 2009, from the document sharing area of Denver University

ICT 4010 online course)

Tucker, D., and R. Leonard. 2001. An innovative approach for using the

GRAI methodology for reengineering the new product introduction

process. The International Journal of Flexible Manufacturing Systems

13 (2001): 177-193.

Williams, M. A., A. K. Kochhar, and C. Tennant. 2005. An object-oriented

reference model of the fuzzy front end of the new product introduction

process. International Journal of Advanced Manufacturing Technology

34 (7-8): 826-841.

Doug Rinker Bio:

In his 28 year career at a major U.S. aerospace company, Doug Rinker held positions as an electronics/embedded software design engineer, project

manager, and engineering manager of several design departments. In these positions, he was responsible for many aspects of the development of

custom electronic aircraft controls hardware, software, and associated automated test systems. He holds a Bachelors in Electronics Engineering

Technology degree from the University of Toledo, and a Masters of Business Administration degree from Northern Illinois University. Doug is currently

pursuing a second career in web development and is completing his final coursework for the Masters of Applied Science in Information and

Communication Technology degree (Web Design and Development specialization) from the University of Denver.