Sie sind auf Seite 1von 15

Celsius Tech

Company Case Study


1) A case study in successful product line development, 1996, Brownsword/Clements
2) A project management model based on shared understanding, 2000, Cederling et al.
3) Software Architecture In Practice, 1997, Bass/Clements/Kazman
Why Look At Celsius Tech?
• They build & sell products that are similar in
nature to those produced by Sensis.
• Their customers are governments – like Sensis.
• During their growth they encountered a make or
break crisis situation that Sensis may experience in
the near future.
• They successfully (but painfully) overcame the
crisis by executing a major socio-technical
paradigm shift via strong managerial & technical
Company Description
• Celsius Tech is a Swedish naval defense contractor
• They develop increasingly larger distributed,
embedded, real-time shipboard command &
control systems
• Customers: Scandinavian, Middle Eastern, South
Pacific navies
• As of 1996, Celsius Tech had 2000 employees and
annual sales of $300 million
• All of their contracts are fixed-price
Sensis/Celsius Tech Product Line Similarities

Celsius Tech Command &

Product Line

SS2000 Product Line Performance: 55 sold to seven different countries

Typical system “instantiation” has 1 -> 1.5 million SLOC, 30-70 CPUs connected via dual redundant LANs

Data Comm
Future Sensis
Product Line ?
Large ASDE-X “like” ATC systems Sensor
Guidance & HMI

The Road To Change
• 1975-1980: small real-time, single embedded
CPU, individual weapon fire-control systems
• 1980-1985: Increasing push toward integration of
fire-control/weapons/command and control
functions led to product size/complexity increases
and distributed systems with point-point comm.
links (network technologies too risky).
• Pre-1986 Summary: > 100 systems in the field
ranging in size from 30K to 700K SLOC in the
fire-control domain.
The Road To Change
• With increase in size, conventional (one-of-a-kind,
isolated) system development techniques started to
– Unpredictable and lengthy integration
– Led to increasing cost & schedule slippage
• Crisis Event: simultaneous award in 1985 of 2
contracts (Swedish & Danish navies) for even
larger products than previously built!
The Road To Change
• Based on the awards and “awareness” of
deteriorating performance of preceding product
developments, senior technical AND management
staff took a hard look at their business/technical
development model.
• Conclusion: schedule, cost, and functionality for
the new systems were ALL at enormous risk by
“staying the course”.
• A major change in the company’s business &
technical model was required.
Slaying The Dragon
• Because of many product
overlaps/similarities and anticipated 20-30
year life-span,
– management and technical staff were able to
envision schedule/cost/quality benefits of a
more disciplined, forward-looking, product line
architecture based strategy.
Slaying The Dragon
• The New Strategy:
– Proactive, reuse in-the-large of “domain functions”.
– Leverage past domain expertise and product development
experience to create/define a generic Product Line Architecture.
– Define/develop/test and maintain over time, a set of large, flexible,
robust, interoperable, architecture-compliant building block
product line “core assets” from which new systems could be
“assembled” and tested with relative ease.
– As new requirements arise over time, new core assets can be added
to the product line to sustain business viability.
– Architecture constraints/rules imposed on each core asset to ensure
inter-operability, high quality, low ongoing maintenance cost,
system-wide conceptual integrity, and rapid “assembly” of
customer-specific product instances.
Slaying The Dragon
Old Way

functional and quality
Development System
Customer Customer

New Way

Sales System Baseline
Team Architecture


functional and quality Development System
requirements Team
Customer Customer
Hurdles That Were Overcome
• Three company ownership changes occurred
during the transition in business/technical
• Massive technical infrastructure changes required
• To accommodate the 20-30 year life-span.
– Minicomputer to microcomputer processors
– Point-to-point based comm. to LAN based comm.
– No fault-tolerance to redundant, fault-tolerant
– Waterfall to iterative/incremental development process
– RTL/2 to Ada83 language change
• Large upfront investment required.
Hurdles That Were Overcome
• Massive paradigm shift from old ways
(developing with no constraints) of doing things to
new ways (assembling with constraints).
• Temptation to abandon ship when the inevitable
collisions between old/new ways arose.
• Unfamiliarity of customers with the product line
approach’s affect on conventional
contractual/technical/business practices.
Painful Actions Taken To Get “There”
• Major internal company reorganization was
executed to accommodate the new
architecture-based strategy.
– Old organizational structure reflected the old
custom, single-system approach and was
incompatible with the product line architecture-
based approach because the org. structure was
architecture “unaware”.
Painful Actions Taken To Get “There”
• Dedicated Architecture Team Created
– Small group of full-time senior engineers with
extensive domain and hands-on product development
– Initial architecture development
– Continued ownership and overall control of the product
line to ensure design consistency and unambiguous
interpretation across all functional areas.
– Frequent communication to technical/managerial staff
of product line principles/concepts/rationale/economic
The Payoff for Celsius Tech
• The capability to produce large sophisticated
systems quickly and reliably (agility).
– Verbatim code reuse on new systems averaged almost
– Inverted its SW/HW cost ratio from 65:35 to 20:80 (!)
• The capability to enter new adjacent markets
– Air-defense business was jump started by taking 40%
of their code, directly from the ship systems business.
– Also considering other markets where distributed, real-
time, sensor-based, human-in-the-loop, command and
control systems are dominant.