Embed Size (px)
Citation preview
beyond software evolution: software environmentalism
@girba
an E-type system must be continually adapted or it becomes progressively less satisfactory
as an E-type system evolves, its complexity increases unless work is done to maintain or reduce it
Lehman, Belady 1974
074 0 -74 5 9 /12 / $ 31. 0 0 © 2 012 I E E E JULY/AUGUST 2012 | IEEE SOFTWARE 19
IMPACT
Editor: Michiel van GenuchtenOpen Digital [email protected]
Editor: Les HattonKingston [email protected]
IMPACT
Compound Annual Growth Rate for SoftwareMichiel van Genuchten and Les Hatton
Six impact columns published over the past three years and a couple of precisely measured products let us calculate the compound annual growth rate.
MANY OF US subscribe to the belief that software is growing. This is gen-erally fueled by apocryphal stories, rea-soning that as hardware speeds up, the software seems to slow down almost in proportion, and because software can’t
just slow down, there must be more instructions for it to carry out; there-fore, it must be growing. But how fast? Statements such as “software doubles every two years” are still sufficient for many audiences due to a lack of empiri-cal data. There is some data available from open source products, but size data from industrial products over a longer period of time is scarce.
In this installment of the Impact de-partment, we want to discuss software
growth in more detail, a discussion we base on the data published in previous installments that cover products (10 since 2010). Six out of the 10 provide the software size at a minimum of two points in time.1–6 This lets us calculate
the approximate growth rate over that period of time. Table 1 contains the data as previous-installment authors have described it.
Note that these products vary in
application;safety criticality (for instance, magnetic resonance, oil explora-tion, and flight management sys-tems were characterized as safety critical);
software size (orders of magnitude difference, both at start and at the end); and team size (from a few engineers to hundreds of them).
The sizing data covers periods rang-ing from seven to 22 years. Note that we don’t yet have enough data for de-tailed statistical analyses, but the val-ues are quite robust.
A Compound Annual Growth Rate for SoftwareThe last column of Table 1 states the compound annual growth rate (CAGR). CAGR is year-over-year growth over some number of years. For example, doubling in five years can be explained by a CAGR of 1.15 (1.155 = 2.01). CAGR is often used in analysis reports summarizing the expected fu-ture growth of markets or revenue. The CAGR of the six products listed fall within a surprisingly small range. To be clear, we didn’t cherry-pick these prod-ucts based on their CAGRs, nor will we in the future. The CAGR ranged from 1.11 to 1.29 for the six products listed.
Because software can’t just slow down, there must be more instructions for it to carry out; therefore, it must be growing.
the approximate growth rate over that period of time. Table 1 contains the data as previous-installment authors have described it.
Note that these products vary in
safety criticality (for instance, magnetic resonance, oil explora-
ight management sys-tems were characterized as safety
A Compound Annual Growth Rate for SoftwareThe last column of Table 1 states the compound annual growth rate (CAGR). CAGR is year-over-year growth over some number of years. For example, doubling in five years can be explained by a CAGR of 1.15 (1.155 = 2.01). CAGR is often used in analysis reports summarizing the expected fu-ture growth of markets or revenue. The CAGR of the six products listed fall within a surprisingly small range. To be clear, we didn’t cherry-pick these prod-ucts based on their CAGRs, nor will we in the future. The CAGR ranged from 1.11 to 1.29 for the six products listed.
carry out; therefore, it must be growing.
May ❘ June 2000 IT Pro 171520-9202/00/$10.00 © 2000 IEEE
LeveragingLegacySystemDollars forE-BusinessLen Erlikh
A lthough many firms have rapidly andenthusiastically adopted distributedarchitectures, many more are stuckwith mainframe-based mission-critical
systems that continue to isolate them from theirpartner, supplier, and customer systems. Indeed,IDC estimates there are more than 10,000 largeIBM mainframe sites worldwide with 200 billionlines of legacy code still in use.
Most companies want to transform their appli-cations to meet new businessdemands, but because legacysystems tend to be unwieldy,monolithic, and inflexible,many firms regard modern-ization as somewhere betweenimprobable and impossible.Reeling from the Y2K deba-cle and saddled with years ofapplication backlog, the mostthese companies can hope foris to keep their legacy systemalive.
And keeping it alive is get-ting more expensive.According to an informal in-dustry poll, 85 to 90 percent of IS budgets goes tolegacy system operation and maintenance.It is alsobecoming harder to find qualified personnel to dothe maintenance. All of this makes it difficult toadd new functionality and keep up with businessrequirements.
The ideal solution is to transform legacy systemsto newer,more productive platforms so that com-panies can exploit faster and cheaper develop-ment technologies, like Java and XML (ExtensibleMarkup Language).The focus then shifts to func-tionality, not the infrastructure, which means acompany can respond more quickly to its chang-ing business requirements and technologyenhancements.
NOT A TRIVIAL PURSUITBut this legacy transformation isn’t trivial,
which is why many companies avoid it. The e-business architecture emphasizes just abouteverything foreign to a legacy system—distrib-uted heterogeneous platforms, componentencapsulation, the merging of standards, open-ness. The challenge is to preserve the wealth ofcaptured business knowledge and have the sys-tem fit into the component world of the new e-architecture.
RescueWare, legacy transformation softwarefrom Relativity Technologies, breaks businessknowledge into stand-alone pieces, or e-compo-nents.The e-components are basically collectionsof objects that perform specific business services,have clearly defined application program inter-faces (APIs), and are accessible through modernindustry-standard protocols.
Because these e-components encapsulate indi-vidual business processes and because other com-ponents can freely access them, a company canmore precisely control individual businessprocesses. This divide-and-conquer approachallows companies to do rapid concurrent devel-opment. Each large-scale business processbecomes a self-contained unit of manageable size,making it easier to deploy in a Web-based envi-ronment.
Legacy transformation in RescueWare beginswith understanding what parts of the legacy sys-tem are worth transitioning to the e-business
Legacy Modernization ResourcesHunting for Business Rules
Inside
Converting a monolithic legacysystem to stand-alone components can turnthis source of businessknowledge into acompetitive edge.
May ❘ June 2000 IT Pro 171520-9202/00/$10.00 © 2000 IEEE
LeveragingLegacySystemDollars forE-BusinessLen Erlikh
A lthough many firms have rapidly andenthusiastically adopted distributedarchitectures, many more are stuckwith mainframe-based mission-critical
systems that continue to isolate them from theirpartner, supplier, and customer systems. Indeed,IDC estimates there are more than 10,000 largeIBM mainframe sites worldwide with 200 billionlines of legacy code still in use.
Most companies want to transform their appli-cations to meet new businessdemands, but because legacysystems tend to be unwieldy,monolithic, and inflexible,many firms regard modern-ization as somewhere betweenimprobable and impossible.Reeling from the Y2K deba-cle and saddled with years ofapplication backlog, the mostthese companies can hope foris to keep their legacy systemalive.
And keeping it alive is get-ting more expensive.According to an informal in-dustry poll, 85 to 90 percent of IS budgets goes tolegacy system operation and maintenance.It is alsobecoming harder to find qualified personnel to dothe maintenance. All of this makes it difficult toadd new functionality and keep up with businessrequirements.
The ideal solution is to transform legacy systemsto newer,more productive platforms so that com-panies can exploit faster and cheaper develop-ment technologies, like Java and XML (ExtensibleMarkup Language).The focus then shifts to func-tionality, not the infrastructure, which means acompany can respond more quickly to its chang-ing business requirements and technologyenhancements.
NOT A TRIVIAL PURSUITBut this legacy transformation isn’t trivial,
which is why many companies avoid it. The e-business architecture emphasizes just abouteverything foreign to a legacy system—distrib-uted heterogeneous platforms, componentencapsulation, the merging of standards, open-ness. The challenge is to preserve the wealth ofcaptured business knowledge and have the sys-tem fit into the component world of the new e-architecture.
RescueWare, legacy transformation softwarefrom Relativity Technologies, breaks businessknowledge into stand-alone pieces, or e-compo-nents.The e-components are basically collectionsof objects that perform specific business services,have clearly defined application program inter-faces (APIs), and are accessible through modernindustry-standard protocols.
Because these e-components encapsulate indi-vidual business processes and because other com-ponents can freely access them, a company canmore precisely control individual businessprocesses. This divide-and-conquer approachallows companies to do rapid concurrent devel-opment. Each large-scale business processbecomes a self-contained unit of manageable size,making it easier to deploy in a Web-based envi-ronment.
Legacy transformation in RescueWare beginswith understanding what parts of the legacy sys-tem are worth transitioning to the e-business
Legacy Modernization ResourcesHunting for Business Rules
Inside
Converting a monolithic legacysystem to stand-alone components can turnthis source of businessknowledge into acompetitive edge.
an E-type system must be continually adapted or it becomes progressively less satisfactory
as an E-type system evolves, its complexity increases unless work is done to maintain or reduce it
Lehman, Belady 1974
@girba
moosetechnology.org
@girba
moosetechnology.org humane-assessm
ent.com
@girba
moosetechnology.org humane-assessm
ent.com
pharo.org
@girba
moosetechnology.org humane-assessm
ent.com
pharo.org
gt.moose
technolo
gy.org
@girba
moosetechnology.org humane-assessm
ent.com
pharo.org
gt.moose
technolo
gy.org
demodriven.com
@girba
moosetechnology.org humane-assessm
ent.com
pharo.org
gt.moose
technolo
gy.org
demodriven.com
feenk.com
@girba
I help teams to not read code
@girba
I help teams to not read code
@girba
... Description description;
Value
...Boolean actualValue
BooleanValue
...
......Value
... Description description;
Value
...Boolean actualValue
BooleanValue
...
......Value
Value value;...if (value == null) { ... }
accept(Visitor)Description description
Value
accept(Visitor)Boolean actualValue
BooleanValue
accept(Visitor)...
...Value
Value value;...if (value == null) { ... }
accept(Visitor)Description description
Value
accept(Visitor)Boolean actualValue
BooleanValue
accept(Visitor)...
...Value
accept(Visitor)
UndefinedValue
Value value;...if (value == null) { ... }
accept(Visitor)boolean isUndefined()
Description descriptionValue
accept(Visitor)Boolean actualValue
BooleanValue
accept(Visitor)...
...Value
accept(Visitor)boolean isUndefined()
UndefinedValue
Value value;...if (value == null) { ... }
accept(Visitor)boolean isUndefined()
Description descriptionValue
accept(Visitor)Boolean actualValue
BooleanValue
accept(Visitor)...
...Value
accept(Visitor)boolean isUndefined()
UndefinedValue
Value value;...if (value.isUndefined()) { ... }
Value value;...if (value == null) { ... }
valueClass := self allModelTypes entityNamed: #'Value'.valueVariables := valueClass withSubclassHierarchy flatCollectAsSet: #structuresWithDeclaredType.valueVariables select: [ :each | (('*', each name , ' != null*') match: each belongsTo sourceText) or: [ ('*', each name , ' == null*') match: each belongsTo sourceText ] ]
Value value;...if (value == null) { ... }
/** * The method can return null */
Value doSomething() { ... return value;}
valueMethods := valueClass withSubclassHierarchy flatCollectAsSet: #behavioursWithDeclaredType.valueMethods select: [:each | each comments anySatisfy: [:c | '*null*' match: c sourceText ] ]
/** * The method can return null */
Value doSomething() { ... return value;}
development
development
decision
development
mcluhan / culkin
mcluhan / culkin
have the right to build upon recyclable systems
have the right to build upon recyclable systems
have the responsibility to produce recyclable systems
have the right to build upon assessable systems
have the responsibility to produce assessable systems
mcluhan / culkin
apply analysis
interpretconfident?
hypothesize
existing analysis?
apply analysis
interpretconfident?
hypothesize
existing analysis?
apply analysis
interpretconfident?
craft analysis
hypothesize
decision
development
have the right to build upon assessable systems
have the responsibility to produce assessable systems
beyond software evolution: software environmentalism
@girba
@girba
