Celsius Tech

Company Case Study

6/30/04

References:
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
leadership.
 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

Sensor
Surveillance,
Celsius Tech Command &
Control
HMI

Product Line
Weapon

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
Device
Future Sensis
Product Line ?
Large ASDE-X “like” ATC systems Sensor
Surveillance
Guidance & HMI
Control

Guidance
Device
 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
fail:
– 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

Product
functional and quality
Development System
requirements
Team
Customer Customer

New Way
Product-Line
Architecture

Marketing/
Sales System Baseline
Team Architecture

Requirements
Negotiation

Product
functional and quality Development System
requirements Team
Customer Customer
 Hurdles That Were Overcome
• Three company ownership changes occurred
during the transition in business/technical
strategy!
• 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
experience.
– 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
benefits.
 The Payoff for Celsius Tech
• The capability to produce large sophisticated
systems quickly and reliably (agility).
– Verbatim code reuse on new systems averaged almost
80%.
– Inverted its SW/HW cost ratio from 65:35 to 20:80 (!)
• The capability to enter new adjacent markets
quickly.
– 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.