software environmentalism - tudor girba - codemotion amsterdam 2016

software environmentalism

@girba

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.

@girba

moosetechnology.org

@girba

moosetechnology.org humane-assessment.com

@girba


pharo.org

@girba


pharo.org

gtoolkit.

org

@girba


pharo.org

gtoolkit.

org

@girba

aito.org


pharo.org

gtoolkit.

org

@girba

aito.org

demodriven.com


pharo.org

gtoolkit.

org

@girba

aito.org

demodriven.com

feenk.com

I help teams to not read code

@girba

development

decision

development

development

decisionassessment

humane-assessment.com

http://humane-assessment.com

context matters

only constraining functionality is not enough

software systems have emergent structures

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

query

datanavigation

code

navigation

mcluhan / culkin

WidgetBWidgetA

Widget Theme

have the right to build upon assessable systems

have the responsibility to produce assessable systems

@girba

software environmentalism - tudor girba - codemotion amsterdam 2016

Technology