The Agile Executive

Making Agile Work

Posts Tagged ‘Embedded Software

Are We at a Point of Saturation?

leave a comment »

In a post entitled Enterprise Software Sale as Corporate Pathology: The World’s Greatest Dog and Pony Show, colleague James Governor recommends the following practices for coping with aggressive enterprise software sales tactics:

In order to better fight their corner enterprises need to be smarter and more aggressive themselves. They should:

1. Pay more attention to the people that actually do the work. Don’t buy software that your developers have no intention of using. Make sure architects are listening to developers.

2. Consider offload options:

  • application server – if you’re running a Java workload does it really require the quality of service that a WebLogic offers? If not why not look at Glassfish, say, or Apache Tomcat.
  • database- not all data are equal. That being the case put data in the most appropriate place. If it just needs to be thrown in a bucket of bits then consider MySQL or a file system rather than your “enterprise standard relational database”
  • cloud- its other [over? IG] there. take advantage of it, especially for non transactional workloads.

Use open source and cloud as personal trainers for proprietary software. Use alternatives to snap back if the salespeople try and bullshit you.

Examining the issue James brings up from an industry perspective, the question of possible saturation jumps to mind. At this point in time, do enterprise software vendors develop more software than the demand profile warrants? Such a situation, for example, manifested itself in telecommunications during the late 1990’s and early 2000’s when only 1-2% of fibre cable capacity in the US and EMEA has been turned on. The resultant losses have been catastrophic.

 If we are indeed at a saturation point for enterprise software, a strategy question and a policy questions present themselves:

  1. For enterprise software vendors: What is the strategic course to turn around technological maturation and market saturation?  Is “pedal to the metal” strategy still appropriate for enterprise software vendors?
  2. For policy makers: Is enterprise software an industry whose growth should be stimulated? Or, would another sector of software prove superior as a target for stimulation? For example, embedded software has the potential to be used in more and more products. Moreover, it has the potential to become larger component of the products in which it is embedded.

The two questions are related. Investment choices made by enterprise software vendors will determine how dynamic the industry becomes. A possible public policy decision to stimulate growth in enterprise software makes sense only if  the industry demonstrates strong generative potential: it should be able to create new businesses around enterprise software; and,  it must trigger growth in the various industries where enterprise software is used. Absent such effects, why stimulate growth in enterprise software?

As pointed out by Perez, the public policy decision needs to take income distribution into account:

If you want to sell basic foods, your potential market grows with number of low-income families; if you sell luxury cars… you look to the upper end of the spectrum. So the rhythm of potential growth is modulated by the qualitative dynamics of effective demand. Therefore, even if the quantity of money out there equals the value of production, if it is not in the right hands, it will not guarantee that markets will clear.

It was pointed out in Enterprise Software Innovator’s Dilemma that “good enough” Open Source Software is inevitably becoming good enough. If you accept this premise, an attractive policy decision could be to allocate public funds to making Open Source Software enterprise ready. Once it is (enterprise ready), the stimulative effect of low cost enterprise software could be huge. For example, it might enable SMBs to offer services that currently can only be afforded (and provided) by Fortune 500 companies.

Why Agile Matters

with 9 comments

Agile matters because it is a critical factor in the techno-economic process. In fact, it fits nicely in both the classical theory of techno-economic cycles, and the latest revisions to the theory. Whichever school of thought you might follow with respect to what the nature of the current macro-economic crisis is and what the implications for your company might be, Agile will serve you well.

Technological revolutions

In Technological Revolutions and Financial Capital, author Carlota Perez views technological revolutions as part of techno-economic cycles. According to Perez, techno-economic cycles are composed of a sequence of events that proceeds in the following way:

  1. A major technological innovation introduces a new infrastructure
  2. The new infrastructure disrupts both industry and commerce (and very possibly society)
  3. Overtime, the new technology gets to be understood; it then gets harnessed
  4. As the new technology gets harnessed, confidence in it grows and it gets used broadly. Consequently, in good time, the new infrastructure itself becomes a stabilizing force
  5. A new technological innovation disrupts the prevailing order and gives rise to start a new techno-economic cycle

Perez identifies five successive technological revolutions between the 1770s and the 2000s:

slide1

To summarize, Perez perceives that technological revolutions are subject to laws of cyclicality. The cardinal law in the cyclicality is that intertia eventually becomes the legacy of successfule innovation.

Has the techno-economic paradigm been disrupted?

In a recent Harvard Business Review article, authors Hagel, Brown and Davison suggest that we are witnessing a profound shift:

The historical pattern – disruption followed by stabilization – has itself been disrupted.

Hagel, Brown and Davison perceive an exponential pace in information and telecommunication. The exponential pace creates a new reality and a new order:

Because the underlying technologies are developing continuously and rapidly, there is no prospect for stabilization. Businesses and social institutions constantly find themselves racing to catch up with and learn the steadily improving foundational technologies…  The core technology infrastructures that once formed the bedrock have turned into plasma.

Choosing between the two theories

The debate about which techno-economic paradigm – the Carlota Perez paradigm or the Hagel, Brown and Davison paradigm – is better suited for the current circumstances is beyond the scope of this blog. Be it as it might, Agile fits well with either paradigm, though in a different manner.

Agile as a low cost input

If you believe the classical techno-economic paradigm a la Perez continues to prevail, you need to think of software produced by hyperproductive Agile team as a low-cost input in the techno-economic system.  If Agile is massively adopted, it will satisfy the four conditions stipulated by Perez for an input to be a key factor in the technological revolution:

  1. Clearly perceived low – and descending – relative cost
  2. Unlimited supply for all practical purposes
  3. Potential all-pervasiveness
  4. Capacity to reduce the cost of capital, labour and products as well as to change them

The potential  implications of Agile software getting to satisfy these four conditions are far reaching. According to Perez, the current technological cycle started in 1971 with the introduction of the microprocessor by Intel. Hence, one might think of Agile software as a “mid-life kicker” to the current techno-economic cycle.

At the micro-economic level, the implications of Agile as a low-cost input for traditional enterprise software vendors are dire. As pointed out in the post Enterprise Software Innovator’s Dilemma, some low-cost input effects are already manifesting themselves through Open Source Software.

 Agile as agile

If you subscribe to the “bedrock into plasma” paradigm advocated by Hagel, Brown and Davison, you need to view Agile from the point of view of, well, agility. Irrespective of whether your business strategy calls for adapting to the market or shaping it, speeding up the business, not “just” R&D, is absolutely of the essence. You need to apply the Agile principles to the way you develop your business and your customers.

The point in nicely illustrated in The Lean Startup presentation by Steve Blank and Eric Ries. The authors are emphatic in their recipe for success:

Winners are those that can move faster than their competition.

To move faster than the competition, Blank and Ries recommend applying Agile principles to customer development. In so doing, they extend Agile beyond the traditional starting point when the (customer) problem is supposed to be known but the (software) solution is unknown. They elevate the paying fields to the level in which customer development is done in  parallel to product development. This kind of uninterrupted flow in the feedback loop between developer and end-user makes Agile extraordinarily powerful. 

For further research

I encouraged you to consider the ramifications of the ideas presented above and to comment on them in this blog and elsewhere. Of the numerous avenues that we can explore in pursuing the boundaries of Agile, the following topics are particularly intriguing:

  • Alan Fusfeld introduced the Technological Progress Function as a tool to quantify technological progress as function of time and scale. The opportunity exists to combine software metrices, the technological progress function, and the techno-economic paradigm in a unified model.
  • As pointed out above, inertia eventually becomes the legacy of successful innovation. Conversely, one needs to overcome inertia in order to introduce successful innovation. Jim Highsmith‘s recommendation to innovate through experimentation a la Agile is very powerful at the project level. It is not fully clear how a similar approach could be facilitated at the policy level.