Barrier To Adopting Reuse: Dynamic Tension Between Technical and Organizational Forces

 

Margaret (Maggie) J. Davis

Boeing Commercial Airplane Group

P.O. Box 3707 MS 6H-WL, Seattle, WA 98124-2207

Tel: (425)234-9457, fax: (425)234-5775

Email: maggie.davis@boeing.com

 

Abstract

A major consideration for adopting a domain-specific reuse approach is the dynamic, systemic tension between technical and organizational needs. Techniques for identifying what reactions will be triggered by a change are needed so actions to reduce tension can be deployed along with the change.

 

 

Keywords: Reuse adoption, domain-specific reuse, reusable architecture

Workshop Goals: Learn about component-based approaches and experiences with reuse adoption.

Working Groups: Components versus Objects, Success reuse adoption - is it possible?

1 Background

Reflecting on experiences while attempting to infuse domain-specific reuse first into the large defense contractor culture of Boeing where products are really extremely large, long-lived systems and now into the information systems culture supporting manufacturing and assembly of complex airplanes, I find it is often the dynamic tension between the technical and organizational forces that reduces the impact of a successful step towards adoption. Although inertia of business culture has long been recognized as "the" reuse problem, remedies such as securing a strong executive to champion the change have been effective only as long as the organizational structure is stable. The cultural adoption problem never goes completely away because there is a systemic and necessary tension between technical and organizational progress in adopting technologies into a culture.

 

2 Position

Each step towards adoption of domain specific reuse requires reduction in the systemic tension between organizational and technical issues. Forecasting what dynamic tension will be manifested in order to mitigate it is on a par with forecasting weather. That is, large trends are easy to spot while large consequences from minute details are difficult to foresee.

 

3 Approach

In my experience, every technical(organizational) step forward unleases an organizational (technical) reaction that works to erase the benefit to be gained. For example:

  • Organizational progress such as setting up cross-functional teams to coordinate and manage software architecture issues stumbles when one team endorses CORBA/Java as a technical direction for a component-based architecture and another insists the direction should be Microsoft╣s COM/DCOM and Visual Basic.
  • Technical progress such as reuse of a web-based machine operator's interface stumbles when functional organizations disagree as to which one has responsibility for acquisition, configuration management, and maintenance of the basic hardware and operating system on which the interface runs as well as of the distributed server environment.

    Predicting what reactions are possible in reaction to a technical or organizational change so that mitigation can be planned or incorporated into its deployment is problematic. To make a reasonable prediction requires understanding both the organizational culture/processes/strengths/weaknesses as well as its attitudes and history with respect to specific technologies. To reach that understanding may require use of socialogical techniques such as focus groups and more, which is an expensive proposition. It was hoped that establishing enterprise architectures for domains would allow this problem to be side-stepped. In my experience that is not sufficient and, sometimes, amplifies the problem.

    4 Comparison

    An elaborate role-based scenario could be used as a technique for identifying the direction/tactic that the natural opposing tension might take. Such scenario techniques have been advocated through the U.S. Department of Defense Software Technology for Adaptable, Reliable Systems (STARS) [STARS95] and even practised at WISR '95 [WISR95].

    References

    [STARS95] DoD STARS, Learning and Inquiry-based Reuse Adoption (LIBRA) 21 December 1995, available free on the WWW from ASSET.

    [WISR95] Sid Bailin and Scott Henninger, "Domain Processes and Engineering Working Group Report" WISR '95, St. Charles, Illinois, August 28-30, 1995.

    Biography

    Maggie Davis (maggie.davis@boeing.com)

    Ms. Davis is now a Computing Systems Architect using object and domain modeling techniques to support development of a factory computing system architecture for Boeing Commercial Airplane Group. She was Principal Investigator (1995-1997) of the Boeing internal research and development project titled ``Enabling Technology for Product Reuse,'' which concentrated on architecture frameworks as a motivating factor in systematic reuse adoption. From 1988-1995, Maggie was Reuse Technology Area Lead for the Boeing STARS Program, participating in the joint development of the STARS Conceptual Framework for Reuse Processes (CFRP) and the Reuse Strategy Model (RSM)

    Barrier To Adopting Reuse: Dynamic Tension Between Technical and Organizational Forces

    Barrier To Adopting Reuse: Dynamic Tension Between Technical and Organizational Forces

     

    Margaret (Maggie) J. Davis

    Boeing Commercial Airplane Group

    P.O. Box 3707 MS 6H-WL, Seattle, WA 98124-2207

    Tel: (425)234-9457, fax: (425)234-5775

    Email: maggie.davis@boeing.com

     

    Abstract

    A major consideration for adopting a domain-specific reuse approach is the dynamic, systemic tension between technical and organizational needs. Techniques for identifying what reactions will be triggered by a change are needed so actions to reduce tension can be deployed along with the change.

     

     

    Keywords: Reuse adoption, domain-specific reuse, reusable architecture

    Workshop Goals: Learn about component-based approaches and experiences with reuse adoption.

    Working Groups: Components versus Objects, Success reuse adoption - is it possible?

    1 Background

    Reflecting on experiences while attempting to infuse domain-specific reuse first into the large defense contractor culture of Boeing where products are really extremely large, long-lived systems and now into the information systems culture supporting manufacturing and assembly of complex airplanes, I find it is often the dynamic tension between the technical and organizational forces that reduces the impact of a successful step towards adoption. Although inertia of business culture has long been recognized as "the" reuse problem, remedies such as securing a strong executive to champion the change have been effective only as long as the organizational structure is stable. The cultural adoption problem never goes completely away because there is a systemic and necessary tension between technical and organizational progress in adopting technologies into a culture.

     

    2 Position

    Each step towards adoption of domain specific reuse requires reduction in the systemic tension between organizational and technical issues. Forecasting what dynamic tension will be manifested in order to mitigate it is on a par with forecasting weather. That is, large trends are easy to spot while large consequences from minute details are difficult to foresee.

     

    3 Approach

    In my experience, every technical(organizational) step forward unleases an organizational (technical) reaction that works to erase the benefit to be gained. For example:

  • Organizational progress such as setting up cross-functional teams to coordinate and manage software architecture issues stumbles when one team endorses CORBA/Java as a technical direction for a component-based architecture and another insists the direction should be Microsoft╣s COM/DCOM and Visual Basic.
  • Technical progress such as reuse of a web-based machine operator's interface stumbles when functional organizations disagree as to which one has responsibility for acquisition, configuration management, and maintenance of the basic hardware and operating system on which the interface runs as well as of the distributed server environment.

    Predicting what reactions are possible in reaction to a technical or organizational change so that mitigation can be planned or incorporated into its deployment is problematic. To make a reasonable prediction requires understanding both the organizational culture/processes/strengths/weaknesses as well as its attitudes and history with respect to specific technologies. To reach that understanding may require use of socialogical techniques such as focus groups and more, which is an expensive proposition. It was hoped that establishing enterprise architectures for domains would allow this problem to be side-stepped. In my experience that is not sufficient and, sometimes, amplifies the problem.

    4 Comparison

    An elaborate role-based scenario could be used as a technique for identifying the direction/tactic that the natural opposing tension might take. Such scenario techniques have been advocated through the U.S. Department of Defense Software Technology for Adaptable, Reliable Systems (STARS) [STARS95] and even practised at WISR '95 [WISR95].

    References

    [STARS95] DoD STARS, Learning and Inquiry-based Reuse Adoption (LIBRA) 21 December 1995, available free on the WWW from ASSET.

    [WISR95] Sid Bailin and Scott Henninger, "Domain Processes and Engineering Working Group Report" WISR '95, St. Charles, Illinois, August 28-30, 1995.

    Biography

    Maggie Davis (maggie.davis@boeing.com)

    Ms. Davis is now a Computing Systems Architect using object and domain modeling techniques to support development of a factory computing system architecture for Boeing Commercial Airplane Group. She was Principal Investigator (1995-1997) of the Boeing internal research and development project titled ``Enabling Technology for Product Reuse,'' which concentrated on architecture frameworks as a motivating factor in systematic reuse adoption. From 1988-1995, Maggie was Reuse Technology Area Lead for the Boeing STARS Program, participating in the joint development of the STARS Conceptual Framework for Reuse Processes (CFRP) and the Reuse Strategy Model (RSM)