National Broadband Network

Lots of nonsense continues to be written and said about the Australian government tender process for the National Broadband Network (NBN) and the supposed merits of excluding Telstra from the bidding process, allegedly having submitted a non-conforming bid.

Be that as it may, let the government exclude Telstra and instead fund a separate, capital-city only network to be built by one of the other bidders. At the same time, allow Telstra to build their own national network, presumably coast-to-coast including major regional areas.

For all its problems, the current network coverage of Telstra is far superior to any of its competitors outside of the capital cities. It is impossible for anyone to build a network with broadband access to 98% of the population without subsidies. Either cross-subsidies inside the network provider, where city dwellers pay more to subsidise our country cousins, or government subsidies to maintain equalisation of prices.

The idea has been raised by several commentators, the socialist commentariat in particular, that Telstra should be prevented from building a competitive network to compete with whom ever is the winner of the current bid. Notwithstanding the fact that such a ludicrous, anti-competitive suggestion could be made on the grounds of consumer benefit is the silliness of begrudging the success of the shareholders who own the mostly-privatised entity.

Does this behaviour evince some kind of juvenile spite towards the management and shareholders of Telstra? The current management team is, by definition, subject to change. The shareholders, on the other hand, see the value of their investment further diminished (not to mention the diminution in value of shares held by the Future Fund, the largest shareholder in Telstra) by government intervention in what should be a free market for communications services.

Let the new network providers charge their fair price, presumably undercutting Telstra in areas of high population since their "national network" will be limited to those areas where they (or anyone else) can deploy at low cost and still earn a high marginal return on their investment. It is to be expected that Telstra will meet this price point in some centres, providing strong competition, and will also offer the benefits of a truly-integrated national network for premium customers, including business and government.

Completely putting aside what applications(*) and economic benefits,(**) if any, will flow from the 100+ megabit per second bandwidth that will be usable for homes and small businesses to connect to the Internet, let them build their NBNs and allow the market to decide which way customers will run.

It is another story altogether to consider how much the national capability in telecommunications has been diminished by the relegation of Australia's Telecom, a formidable research and development organisation, to just another utility company known as Telstra.

The growth of directory and media services does not make up for the national loss of innovation and competency in the telecommunications space formerly held by Telstra Research Laboratories, now only partially filled by exceptional organisations like WATRI.

(*) Yes, I know about eHealth application and I am aware of the nebulous future expectations to be delivered by the digital economy. Please define for me what you expect to to be the majority of uses.
(**) Please explain how an increase in network bandwidth improves productivity by: 1) increasing production per person; 2) improving return on capital or investment; or 3) by minimising input costs per unit production.

Innovation in Marine Technology

Nigel Gee, Innovator-in-Residence at the Centre for Marine Science and Technology (CMST) , Curtin University gave a very interesting talk about marine innovation focusing on his specialty of naval architecture which stimulated a vigorous discussion about innovation in general.

He spoke about the original Norwegian innovation in producing the modern catamaran, with 1000 of similar type worldwide, followed by more-recent Australian innovation in wave piercing multi-hull by Incat in Tasmania, having created a whole new market with at least 150 vessels, mostly from Australia. The West Australian company, Austal, has continued the winning trend with the first advanced trimarans to enter the car-carrying ferry market and is on its way towards a major US defence contract for the new littoral combat ship, described as an all-aluminum, new generation, high speed warship.

Nigel emphasised that aesthetics and the nexus between science and the arts have a major part to play in vessel design and by way of example showed a fairly traditional ferry design designed by his firm in comparison to another design of a sleek, modern-looking type with similar performance and capacity, asking which one would we prefer. Form follows function is the typical refrain of engineers (including yours truly) but Nigel decries this approach for one that encompasses both aspects and may benefit the marine industry and the wider community.

The differences between the approaches of industry and acadame towards innovation were represented in a table with the usual points, profit, control and intellectual property on the industry side; research, sharing and publication on the other. The questions of regulation, government intervention and funding were raised along with the telling point that studies point towards a deficit of collaboration (citing an ECU PhD) . I assert that WA has not developed the industry clusters one would expect where on one hand, a number of companies dominate their global industry (eg. mining software) and others have potential opportunities to do so (eg. subsea acoustics, telemetry and control systems).

Nigel made the point that while the US has fallen by the wayside in respect of innovation in naval architecture, whereby it lacks a domestic capability for designing and building high-speed catamarans for commercial and defence applications, they are leaders in scientific innovation. For example, he cites the example of a physicist who says they can improve performance by x% will find themselves showered with funds. There are lessons to be learned from this experience with regard to industry innovation on one side of the ledger (witness the decline of the US automobile industry, for example) and on the other side, industrial sustainability led by scientific innovation spurred on by a high concentration of well-funded, world-leading research institutions (Scripps, San Diego being one among many).

I said that we recognise the innovation success of marine, offshore oil and gas, structural engineering and asked about the relevance of system engineering in the context of of algorithm development and signal processing for acoustics applications, as applied to submarine detection and tracking, mapping and survey for the oil and gas industry. Nigel deferred this question to Dr Jim Klaker, the Director of the Centre, who spoke about their ongoing work in acoustics in the context of defense and our marine environment.

Questions and discussion raised several nefarious issues of government intervention where many seem to agree - with me being a vocal dissenter. For instance, government regulation, legislation and targets for emissions, carbon sequestration, auto and other industries. I see no place for governments to try and pick winners, throwing money at arbitrary areas of interest. Competition and motivation within an industry context are part of the solution whereby companies and individuals take responsibility for funding and risk sharing.

It was suggested by someone in small or medium enterprise, and supported by another, both in technology development companies, that universities tend to saddle commercial arrangements with bureaucracy and seek to capture a share of intellectual property. I suggest that a client can pay for a service if they wish to retain the intellectual property and to accept that research leading to publication is a reasonable outcome of publically-funded research. It is unreasonable to expect something for nothing and a contractual arrangement can guarantee exclusivity if required; however this is inappropriate for an open-ended research question.

Yours truly suggested that industry clusters are rare and this fact reflects poorly on outcomes from industry collaborations in general and cooperative research centres (CRCs) in particular. The review of CRCs is timely and complements the Cutler Report that grew from the National Innovation Review. The question here is one of scale whereby large-scale research and innovative development cannot occur in a piecemeal fashion through individuals and organisations acting alone.

Another issue related to scale is specialist training provided by universities and industry. The expected shortage in naval architects and engineers for Austal and defence projects, including the next-generation submarine, is a continuing concern which parallels the endemic shortage of systems and software engineers, especially those with solid backgrounds in acoustic signal processing.

Informal discussion afterwards over drinks and nibbles provided an enjoyable networking opportunity with a wide cross-section of workers primarily involved in naval architecture and marine engineering. Certainly it is of great benefit to us to have Nigel spend time in Perth to inject some enthusiasm and global perspective into our local environment. Dynamic it might be, with greater participation in science and engineering than elsewhere, but much more can be done to foster innovation in science and engineering applications.

ACOSP Seminar at UWA

SEMINAR:

PROPOSAL FOR AN AUSTRALIAN CENTRE FOR OCEANIC SIGNAL PROCESSING (ACOSP)

By

Dr Daniel BERINSON BE PhD MIEAust MIEEE AFAIM GAICD

And

Mr Christopher SKINNER BSc(Eng) MEngSc MIET MIEAust MACS CPEng, Captain RAN (rtd)

Where:

UWA Business School, Social Sciences South Building room 2233

When:

Friday 17 October at 10am

Summary:

Propagation of acoustic and other signals in the oceanic water body is subject to significant absorption and non-uniform transmission with directional and dispersive effects.

Nevertheless the selective employment of acoustic and electromagnetic signals for communications and measurement has been developed to a high degree in many application domains.

What has now become possible is the aggregation of many signal sources and channels to form arrays, grids and networks to achieve system outcomes that were not previously possible.

This talk will describe the genesis of a proposal to explore these new opportunities for signal processing in the oceanic environment for scientific, industrial and national security purposes.

The talk will also provide a modest insight into the processes being considered for the start of the centre and offers a case study of how such a start-up body can proceed.

Biographical information:

Dr Berinson is Managing Director of Systec Engineering Pty Ltd and consults in software and systems architecture. He earned his degree in Electronic Engineering and PhD in Physics from UWA, and has broad experience in software engineering, defence and enterprise systems.

Captain Skinner served 30 years in the RAN as a weapon and electrical engineer and subsequently in industry in project engineering and general management roles. In 2006 he received the inaugural Maritime Advancement Australia award for work relating to submarine science, engineering and industry.

Contact:

Dr Daniel Berinson +61 4 0888 0278 daniel at systec.com.au

Defence White Paper 2008 Public Consultation

The Community Consultation Panel was convened in the Gallipoli Room, Anzac House, Perth earlier this evening by the Chair Mr Stephen Loosley and Deputy Chair Mr Arthur Sinodinos AO, the complement of the Panel having as its members Rear Admiral Simon Harrington AM RAN (Rtd); The Hon. Peter Collins AM QC and Professor Tanya Monro.

After the Panels introduction and video, including the prologue by the Defence Minister Joel Fitzgibbon, the Panel members were rewarded with a variety of interesting verbal submissions on topics ranging from the value of the Caribou light tactical aircraft, fuel and transport security; importance of the contribution of the Reserves; civil-military cooperation (special interest of Parliamentary Secretary for Defence Support, Dr Mike Kelly); clarification of the Aegis system as a 360 degree radar system (sans delay due to rotation) in answer to a question about anti-satellite missile systems and Australia's planned capability; recognition that adhoc platform-centric approach to the networked battlefield should change to a holistic, networked process for bringing capability to the ADF; suggestion to purchase of STOL F35 jump jet for increased capability (reprising a retired chief of air force).

The meeting was not all beer and skittles with several people eloquently and passionately voicing their dissent at the very premise of spending on an armed military, including Senator Jo Valentine who made the eminently supportable suggestion to create an 'Earth Defence Force.' Also raised was the importance of training for people on peace-keeping missions in conflict resolution, mediation and restorative justice; we were reminded by another than the Reserve brings civilian skills that regular army may not have, including commanders on Operation Anode who are also teachers.

In spite of the relatively sparse, local turnout (maybe 30 people attended, I didn't count) there was a heartening presence of concerned public who voiced views that ranged from strongly antiwar to concern for civilian casualties and returning veterans. In unambiguous terms, we were told of the pointlessness of war and heartbreaking loss of life, against the benefits of greater participation in peace-keeping and humanitarian missions, with a greater focus on the human element in contrast to the increasing expenditure on high technology weapons systems. People for nuclear disarmament WA were represented, suggesting a halt to foreign uranium sales.

There is so much to agree with that I did so publicly, against my intuition to speak in support of those clearly opposed to the status quo in the defence establishment. The debate reinforced in my mind the value of our democracy and the ability to be heard by those in positions of influence, even if the conversation was between such a small group that could hardly be representative of the wider community.

Let's relate the comments of a certain engineer and physics PhD who advocated for the extraordinary capability of WA defence industry, academic and research organisations. He spoke in the context of defence core business and science, remarking on the erosion of Australia's strategic leadership in submarine warfare due to the increasing number of submarines in the region.

He recommended the exploitation of WA capability in acoustics and systems to develop networked anti-submarine warfare capability, in the absence of the old Navy Research Lab, and to fund in Western Australia a Centre of Excellence in Oceanic Signal Processing to further this aim, with wider goals the surveying and exploitation of natural resources - the focus on acoustics signal processing, scientific and algorithm research and development.(*)

With the Collins class fleet base and longest state coast line, WA has a central role in the design and development of the next generation submarine. Also mentioned the Australian Marine Complex and Common user Facility, whereby refits, eg. Collins class by ASC in their modern facility, and visiting foreign vessels, contribute to followup work involving high technology and stimulating local R&D.

I followed up with my familiar refrain (to those who know me at all) of the need to encourage the creation of appropriate tertiary education and training in software and systems engineering, and software and systems architecture; relevant to a wide range of industries aside from defence, eg. utilities, rail and aerospace where high reliability, high integrity systems are required.

(*) Keep your eye on the website for progress or please email me directly to comment, make suggestions or be involved.

Innovation and Complex IT Projects

The recent troubles in DPI with the TRELIS system are symptomatic of the approach that is usually taken to the development of complex IT projects. However we should not be too quick to blame the key stakeholders who led the development of this project on behalf of the customer proxy, the government, who represented the true customer being ourselves, the people of Western Australia.

I want to try and shed some light on the real-life complexities, problems, conundrums and deficiencies that tend to lead large, complex, costly and highly-politicised projects off track almost from the very start and offer some solutions provided by experts in this field. More importantly and in a broader context, I want to explore how the development of complex IT projects and associated software relates the state of our cultural, intellectual and creative capital in our state of Western Australia.

The problems that have been experienced on TRELIS and other large, complex IT software systems development in government are very similar to those often experienced in commercial organisations. This point leads us to conclude that such challenges are not due to government department culture but are due to more-general causes.

I say challenges rather than failures deliberately because these kinds of projects are seldom failures and are often unsung, large-scale successes. TRELIS may indeed be one of these because the system does work, generally speaking, in spite of the Auditor General finding, "Poor specification of business requirements and software development problems resulted in TRELIS being two years behind schedule when it went ‘live’ on 6 July 2004, " (*ag).

Granted there are problems but any "first" is going to experience these - such is the nature of new development of any kind. The fact that, "An approved business case for TRELIS could not be located" is irrelevant because the system upgrade was necessary and the fact that, "Funding for TRELIS was provided on an incremental basis rather than total funding to match the requirements of the project and the level of project management, oversight and quality control were inadequate for a project of this size" is heavily misleading.

The requirements were incomplete because it is not possible to know them prior to the project undertaking requirements analysis, a first cut of which is produced at the start of the project but the process of requirements discovery and elaboration of hidden and misunderstood requirements is ongoing throughout the lifetime of the project, declining as the project reaches completion.

Without complete requirements (as noted, impossible to produce for most systems) estimation and hence budgeting and funding cannot be perfectly accurate. For projects of this scale of magnitude and complexity to go over budget and over time is not only defensible it is to be expected. But we can do better.

The book Waltzing with Bears by DeMarco and Lister is about managing risk on software projects and is one of several easy-to-read management guides about project management and estimation that go beyond the meaningless practice of tabulating fixed estimates for each task in the work breakdown structure at the start of the project and then pretending these reflect delivery expectations when in reality they are merely guesses and nothing more.

The title of Death March by Ed Yourdon says much in itself and talks about the symptoms of pathological management that is reasonably prevalent in the software industry, at the same time presenting practical solutions to dealing with these circumstances. The Guide to the Software Engineering Body of Knowledge, or SWEBOK, is not well known to many practitioners. Both traditional and contemporary approaches to software project management, from Rational Unified Process to Agile approaches that include Scrum, Extreme Programming and Feature Driven Development, are often ignored or misunderstood in their application.

The report entitled Challenges of Complex IT Projects jointly authored by the British Computer Society and The Royal Society of Engineering goes straight to the point of the many problems that beset complex IT projects. As I note in a submission to the National Innovation Review, "there is a broad reluctance to accept that complex IT projects have many similarities with major engineering projects and would benefit from greater application of well established engineering and project management procedures. For example, the importance of risk management is poorly understood and the significance of systems architecture is not appreciated."

The report goes on to point the general direction that needs to be taken in order to remedy the situation facing organisations which undertake complex IT projects. Two key recommendations are: 1) There is an urgent need to promote the adoption of best practice amongst IT practitioners and their customers; and 2) Basic research into complexity and associated issues is required to enable the effective development of complex, globally distributed systems.

In Perth, perhaps a reflection of the pioneering approach taken by the explorers of Western Australia, and reflected in many wonderful technology success stories that are little known but should be much celebrated, cultural change towards openness to innovation and willingness to change is rare. Companies such as FormSys, Maptek, QPSX, ERG, Asgard, Sanford Securities, JDV, L3-Nautronix and many others have each had their measure of success in their respective application areas.

There is so much opportunity in mining and resources, communications, defence, utilities, government and enterprise IT systems development where Perth companies can carve out an outstanding niche for themselves or join the list of national and global leaders. For example, strong and capable leadership is needed for us to to take advantage of benefits that could accrue to our state due to all six of the Collins class submarine fleet being based here, the incredible development of industry at Australian Marine Complex and Technology Park, to support research and development work in subsea engineering, communications, other marine, acoustic and defence technologies.

The current and future benefits of the iVec supercomputing centre, the global radio astronomy project known as the Square Kilometre Array or SKA that is looking more likely to be based in our state, continuing massive investments in the mining and resources, associated infrastructure, knowledge base and information technologies are potentially enormous and could leave an unparalleled legacy as a benefit of the extended boom we have experienced in mining and resources.

Beyond the boom, the development of advanced Information and Communications Technologies, known collectively as ICT, will underwrite the future growth and well-being of Western Australia where Rabbitnomics dictates that mining alone will not. Earlier this year, I was privileged to be a part of the Australian Software Engineering Conference that was held for the first time in Perth in the 20 year history of the conference. Having finally started to build the bridges, it is vital that business development extend to the commercial exploitation of the creative capital we have in abundance in the fields of ICT in our state.

As part of a much-needed debate about the cultural face of Perth, the abundance of creative capital and deficit of innovation, FORM brought Charles Landry to our city, who wrote that, "A great city must be much more than wealthy. It must have a culture rich in passion, compassion, art and innovation."(*cl) FORM and the debate over creative capital, culture and ideas was naturally dominated by architects, psychologists, artists and politicians, with little input from scientists, engineers and other technologists.

It is quite natural that social scientists and others focused on cultural and social issues should frame and dominate the debate about the composition and geography of Perth, its relationship to our beautiful surrounds, and our place in the environment as members of a community. However those across the Maginot Line that fortifies the supposed partition of social from physical sciences have a role to play. The physical sciences, engineering and technological arts have a closer relationship with their artistic and literary brethren in commerce, law and design than many realise.

Creativity is rife throughout scientific endeavours of discovery and complements the rigours of design. It is just so that structural engineers and software engineers share the terminology of requirements engineering, specification, design and concreting or concretion, in the former case the pouring of concrete foundations and more elaborate vertical structures in order to satisfy the architectural blueprints, and in the latter case of software the artifact written by a coder to implement the software design.

In both cases, the term architect is used appropriately to describe the role of the designer who conceptualises what is to be built. The term software architect was borrowed into the field of software engineering by a body of workers who constructed software design patterns based on the work of Christopher Alexander, a famous architect known for his theories of design and in particular his seminal book on planning called A Pattern Language: Towns, Buildings, Construction.

In the software engineering community, the seminal book on design patterns is Design Patterns: Elements of Reusable Object-Oriented Software which follows the same pattern templates or scripts as laid down by Alexander. The parallels are obvious and I use this as one example of the close, even symbiotic, relationship between concepts and their practical realisation in fields as diverse as architecture and software development.

Likewise, similar arguments can be applied across the full spectrum of creative undertakings by physicists, biologists, mathematicians and engineers of all stripes who mix the spark of creativity with their foundational sciences and practical technologies in order that an innovative outcome shall emerge.

It has been suggested at various times that our state and our universities should specialise narrowly in fields that are central to or that support the mining and resources industry, in order to leverage our competitive advantage in this area due to the ample resources gifted by nature. However I contend that such a view is short-sighted and counter productive because the wider society would suffer as a consequence.

Besides, we need to embrace a strategy that takes us beyond the boom and we know that knowledge industries including ICT, biotech, subsea, marine and defence present some of the best opportunities for succeeding in a crowded, global marketplace for products and ideas.

(*ag) http://www.audit.wa.gov.au/reports/report2006_01.html
(*cl) http://www.thewest.com.au/default.aspx?MenuID=77&ContentID=23433

The Collins Class Submarine Story

The authors Peter Yule and Derek Woolner do a great job overall of conveying the wonderful engineering achievement that is the Collins class submarine project. Their exposition provides an exquisite history and overview of various aspects of the history of the Australian submarine force and at the same time a sometimes frustrating overview of various aspects the development of the Collins class submarine project.

In the Introduction, the University of Melbourne historian Peter Yule sets out his own terms of reference, stating that the aim of the book is simply to tell the story, using the methods of a historian, leaving the lessons to be discovered by the readers for themselves, avoiding military jargon and using material from interviews and documents, that is, primary sources. Peter's co-author, Derek Woolner is a military analyst at Australian National University who carried out the documentary research and wrote several chapters of the book himself.

I very much enjoyed reading the history of Australian submarines from 1925 when orders were placed for the British-built O-class submarines, Oxley and Otway through the lengthy period of time when the Oberon-class submarines proved to be excellent after their delivery in the 1970s through to sublimely successful upgrades of their weapons systems. The Submarine Warfare Systems Centre upgraded and modernised the combat systems to integrate firing of torpedoes and missiles and unlike American submarines, the Oberons could fire multiple Harpoon missiles towards a target via different tracks. An amazing technical achievement due to the centre's success stemming from "the combination of engineers, programmers and submariners in an environment that challenged and drew the best from each."

The chapters about the project definition, tenders and contract negotiations whet the appetite for the sorts of project issues that will arise later on. Recognise the years of preparatory studies required for any project of such enormous complexity that is difficult for most people to comprehend. Personally, I found quite interesting some of the comments about grudging acceptance of the contract monitoring and control system over the American cost and schedule system and would have liked to know more. Anyone involved in defence projects would appreciate the importance of requirements engineering, preliminary design reviews and prototyping and would also realise these techniques fail to mitigate all risks that later emerged, especially in the failed combat system development and the unexpected noise signature that later took the project by surprise.

The greater intrigue and interest in the book was around the formation of bid teams and the unexpected win by the Australian Submarine Corporation comprising the Kockums design over the German rival and the over-ambitious requirements and timetable for the combat system as contracted to Rockwell. We discover that Rockwell never had any hope of delivering on the requirements for a distributed system with stringent data and information processing constraints using the technology of the day. Without access to the systems architecture, the detailed design and rationale for the decisions that were made by the development team and the conclusions of the review team I can only wonder if this were actually so or whether tantalising success for Rockwell and the Australian integrator Computer Sciences Corporation could have been achieved.

The great unsung successes were in the development of world-leading steel alloy with better performance (eg. explosion bulge testing) and welding techniques that led to a rework rate one-tenth that of comparable submarine projects. Complementing the exemplary construction of the hull and superstructure of the submarine is the unique and world-leading integrated ship control and monitoring system that was developed by Wormald in Australia, in concert with Saab, before its demise as a leading systems engineering and software development firm at the hands of corporate predators. The fly-by-wire system allows a small crew to control the entire submarine and its operation from several automated workstations.

During trials the dive performance was exactly as predicted and the autopilot known as Sven could control the vessel more precisely than a human operator. After some vacillating, the political decision was made to replace the functional but limited combat system on Collins and Farncomb, and later the basis of the augmentation program that was installed on Dechaineux and Sheean, with an off-the-shelf product from Raytheon. The noise problems were improved by altering the shape of the bow sonar dome to the extent that at low running speeds these are the quietest submarines in the world.

I was employed at Nautronix and was working as a signal processing analyst for the Synthetic Aperture Processing System that was deployed by Thistle Island in the Spencer Gulf offshore Port Lincoln in South Australia. Nautronix, now owned by L3, is a world leader in underwater acoustics for positioning, communications and ranging applications. It was my privilege to take the initial theoretical work and to develop the signal processing algorithms and much of the software that was used for acquiring and processing the noise signature of the Collins during its initial ranging; then to undertake the laborious task of processing the data acquired during ranging and personally writing much of the report that was presented in sextuplicate to the Navy.

The politics are naturally relevant for a huge defence project but I do not hold in high regard the remarks made by the authors around the politics of decisions made by the newly-installed Minister for Industry in the first Howard government, John Moore, and Minister for Defence Ian McLachlan. On the one hand, after an independent review a new leadership team was appointed expressly to finish the project but the authors note that without strong support the project could easily have been abandoned. Most of the issues raised in the report were already known but the most important first step was "to get people out of the trenches and back working together" after the breakdown in relationships between ASC, Kockums, the project office and the Navy.

On the other hand, the authors state that the change of government in 1996 led to the abandonment of any industry policy, returning to focus on the bilateral relationship on America, the "enthusiastic adoption of the role as America's 'deputy Sheriff'" and shift towards "enthusiastic participation in American foreign policy adventures." This material, absent footnotes, fails to cite any sources and presumably reflects the political and strategic defence biases of the authors. Clearly deviating from the stated aim to tell the history of the Collins class, these few sentences detract little from an otherwise excellently-written exposition of an amazing story.

For anybody with an interest in the Australian defence forces and in particular for those involved in the defence industry, especially in complex systems and software development, The Collins Class Submarine Story is a must-read and a valuable addition to your book shelf. For others, the lessons for project governance and ownership by its sponsors, the social and historical divisions between the surface fleet and submarine fleet arms of the navy, make a fascinating rendition of issues faced by members of development teams undertaking software and systems integration projects across a wide variety of industries.

Is Technology Change Management an Oxymoron?

Is there such a thing as technology change management that contrasts with change management in any other area? Yes, I believe there is partly because the risks and opportunities of technology are often misunderstood, undersold or oversold (or both).

Also, the discomfort that managers feel about science, technology, engineering and mathematics (STEM) in general adds to their discomfort in supporting and encouraging technology change. (Psychological projection of the manager with limited technical literacy or currency to their staff that they feel uncomfortable with the mooted change.)

By change I mean positive improvements in the technology space, for example, adoption of web interfaces in place of 3270 terminals, today de rigueur in most organisations but a great leap of faith just a few years ago. Perhaps SOA is in the same position today with some caveats I will return to shortly.

The problem of reinvention in the fields of technology and IT is a continuing cause for concern because we all know that the same story can only be spun so many times. He who cries wolf, in this context, will have trouble funding the same kind of project the n-th time around.

For anyone who has been involved in championing the adoption of new technology you will already appreciate that socialisation and process issues are of far greater importance and impact on the organisation and members of the organisation than the technology itself.

While a smaller or greater proportion of stakeholders might embrace the adoption of new technology it is uncertain that such success will follow unless a concommitant effort is made to update business processes to support the new technology.

To the title of this post, is technology change management an oxymoron? More often than not I have observed managers and technical leaders paying lip-service to change over an extraordinarily long period of time, say 3-5 years, when the experience of those who have been successful informs us that change can and should be on shorter time frames.

For example, we will change the way we build applications, with user stories the foundation of agile development, we may be told. But no unit testing or continuous integration is needed at this stage because we don't want to make too many changes at once. Project management has enough problems coping with the new time-keeping system so they don't have to write requirements any more.

We will write our own user stories (or use cases or functional requirements, take your pick) because the customer or end user is unavailable. Have you seen the Dilbert cartoon where the developer asks the business rep what the software is supposed to do? The developer is told to design the software and then to describe what is does.

There is a lot of common sense in agile development that is matched by almost as much whining about the purported failings of earlier approaches. In another post I will examine how agile approaches match up with the seminal Waterfall method from its original publication in 1970, including iterative development, customer involvement, and early testing.

The big difference is that when we are talking about agile development we are usually referring to toy systems compared to those in defence and space that Royce was working on. Modern project management practice, including software, should have evolved from such successes as the space program, defence missile, telecoms and various other successes.

Dare we be so conceited as to pretend a few rules of thumb are adequate? Parnas gives a solid argument for pretending to have a process game even if real-life pragmatism rules out a perfect score.

National Innovation Review

The background and my reasons for making a submission to the National Innovation Review go back quite some time and are informed by a number of personal experiences.

The most important factor is the vacuum of skills in software and systems engineering where one is unlikely to find practitioners who are confident outside of a narrow field of expertise. Over-specialisation and, ironically, dual degrees have played into this scenario because in both cases graduates are limited in their breadth of technical exposure at university.

The general absence or inadequacy of postgraduate mentoring and coaching means that professional development is stymied compared with other professions. Finally, my continuing frustration with endless repetition of bland and unimaginative solutions, like rote answers to a test, at conferences and meetings.

Innovation and Practise in Software and Systems Engineering

Summary

The purpose of this submission is to focus attention on software and systems engineering as it relates to defence, telecommunications, utilities and other industries that rely on safety, integrity and reliable systems; however similar issues arise in enterprise computing that I mention in an addendum. The poor understanding among many engineers, computer scientists and specialists in software and systems engineering makes for many difficulties in building a case for innovation and improving the state of practise in these closely-related fields.

The first step needed to remedy the situation involves redefining software engineering as a subclass or speciality of systems engineering which is itself reasonably well understood by most engineering practitioners and poorly understood by others not working intimately in the field; or at the very least clarifying the relationship between these two disciplines. The second step is to construct an integrated, elite software and systems engineering programme to address the critical shortage of practitioners in these fields, including requirements engineering, test, verification and validation, software and systems architecture, detailed design, and issues of construction, configuration, packaging, deployment and maintenance throughout the whole software and systems development life-cycle.

I also draw attention to the need to focus on fundamental programming, technologies and practices that are essential to software engineering, especially safety-critical and reliable systems, in addition to those aspects that characterise the field as systems engineering.

Barriers to innovation in software and systems engineering

The primary reason to emphasise the barriers to innovation is that the same issues affect the daily and evolutionary practise in the field of software and systems engineering. The reasons for poor on-time delivery, poorly-met requirements and unmet customer expectations for software projects involve the same factors that detract from proper performance during project execution. Project, programme and strategic management are relevant but are on the periphery of the issues that I am highlighting in this submission: Aside from management issues per se, the relevant issues are those in commercial practise and academic presentation of the subject matter.

Issues in defence, industry and academia

The critical shortage of experienced software and systems engineers is in defence where the worsening shortage of specialist skills in requirements and test specification, system design and construction will continue to have an increasingly negative impact on project delivery. The general absence of undergraduate and postgraduate engineering courses that specialise in defence systems is perhaps understandable because the sector, while influential, is small relative to the pool of potential employers for university graduates.

The objectives of defence, industry in general and the academic community are intertwined when we consider the need to reasonably match the supply of graduates to the demand for qualified personnel in industry. The demand for graduates in the defence sector is fed by government and procurement policy while the demand by industry in general is cyclical with the economy. Notably the resources boom has skewed talent entering and leaving university towards the mining and resources industry arguably to the detriment of other industries.

An obvious part of the solution is an upwards adjustment in wages to encourage school leavers to enter the relevant university courses and for graduates to join defence and other industries where there is a shortage of graduates to fill the places. Over time, the bigger problem is the combination of the decline in experienced personnel in these industries as well as the tendency for short-term goals to steer many school leavers towards vocational training and employment when they are well suited towards a university education.

The flow-on effect of experienced practitioners leaving the field is that the level and quality of postgraduate mentoring and coaching in the workplace will decline. Anecdotally, there is evidence to suggest that computing and engineering graduates already have fewer career pathways and mentoring opportunities than their peers in other professions, for example, lawyers serving as articled clerks expect their work to be closely reviewed and marked with red ink by senior associates and partners; and doctors serving their internship and residency are supervised and driven by registrars to improve their clinical knowledge and to excel in its application.

One aspect of these professions currently lacking and that is being developed in software engineering is that of licensing beyond the automatic membership of professional societies granted by virtue of graduating from an accredited institution. Beyond licensing and registration of professionals, a shift in mindset and approach is needed to elevate the level of on-the-job postgraduate professional development of graduates in software and systems engineering.

Supporting R&D and commercial innovation

Among the wide variety of research and innovation undertaken by research institutions and other companies, much of it intellectually or commercially valuable, there is significant R&D undertaken by industry that tends towards being conservative, mundane and uninformed; matched by university-based research that is irrelevant, derivative and uninformed. In itself this claim is irrefutable and we should accept that a few gems of research outcomes are the valuable result of a large amount of money, time and effort invested in research and associated infrastructure.

However we must make greater effort to redirect some resources towards research programmes that are relevant and industrial R&D that addresses known and real problems. In either case, the opportunity for academic research to be informed by outstanding problems in industry and commercial realms is a challenge to take up because of the strict demarcation lines between industry practitioners and academics. It is equally true that many academics will not be welcomed with open arms into the world of commerce just as industry practitioners (with or without a PhD) are looked upon with suspicion when trying to access research funding channels.

As General co-Chair of ASWEC 2008 (Australian Software Engineering Conference), held recently in Perth for the first time in its twenty year history, the relevance and importance of communication between academia and industry was highlighted by the intense participation of both sectors. ASWEC is very rare conference insofar as it encourages mixing between academics, policy makers, teachers and researchers, and practicing engineers, programmers, managers and others in industry. Software engineering is a practice-based discipline and as such it is difficult to imagine software engineering as an academic discipline divorced from its commercial application. This sort of communication, other such forums and cooperative research and development centres need to be encouraged, nourished and supported in order for this field to flourish.

The way software engineering is taught

The various computer science and software engineering degrees taught at our Australian universities appear to be solidly based and founded on a sound scientific and engineering basis. However, some of the content and manner in which these courses are taught, particularly at the postgraduate level where I have heard several disturbing anecdotes of extremely poor course structure and content, needs to be addressed immediately in order to arrest the anecdotal decline in quality of graduates and the very real long-term decline in the number of school leavers entering computer science, engineering and science courses in general.

Part of the attraction of professions such as accounting, law and medicine are the high standards of quality expected of their members, for example, the respect attributed to holders of Chartered Accounting and Certified Practising Accountant qualifications. In many undergraduate, and more so at postgraduate, schools the restricted intake of elite students entering into a period of high-quality education matched by personal challenges to meet the high standards that are expected increases the real and perceived value of the qualification, for example, MBA. I recommend the creation of elite schools that can meet the expectations of quality and guarantees of employment and career development expected of the best schools in the other professions and some engineering disciplines.

State of practise in software and systems engineering

Systems engineering as a discipline

The discipline of systems engineering includes requirements engineering, architecture development and evolution, systems decomposition, modelling and synthesis of the problem domain and selecting one of many viable solutions as a pragmatic approach to solving the problem and meeting the customer's requirements. Verification of the build and construction process, including traceability of design and implementation artifacts (eg. software modules, packages and applications) to the requirements specification, is a precursor to validation of the solution against the customer's need.

Sometimes a solution is constructed from scratch however in general a number of existing, reusable components and third-party, commercial off-the-shelf (COTS) components need to be integrated into cohesive system as part of the solution. The process of decomposing and assigning requirements to subsystems and later integrating each of those subsystems is the essence of systems engineering. Essentially the same description applies to the software engineering processes involving the analysis and design of a software solution for nontrivial systems. The distinguishing feature of nontrivial systems (colloquially known as "complex systems") is that the project team is necessarily composed of people with skills in various disciplines, design and construction takes a significant amount of time, and the delivered system needs to be supported for a significant period of time, often measured in decades for defence and some commercial systems.

The general absence of specialist undergraduate and postgraduate engineering courses that specialise in safety and reliable systems continues to surprise however courses tend to be specialised by discipline or industry. Focused delivery of material as elective units to a core degree in engineering or computing would seem suitable at an undergraduate level, or postgraduate courses that build on the generalist and formative knowledge base that is the foundation of an undergraduate degree. In academia and industry it is rare to find individuals with sufficient knowledge in control systems, digital signal processing or systems analysis as well as a strong enough foundation in computer science or software engineering that they can competently and confidently deliver systems that require this sort of mix of skill sets.

Platforms, frameworks and languages are important

A firm grasp of language-based implementation idioms by software engineers is crucial for the development of high-quality software systems in the sense of the -ilities, for example, portability, maintainability, understandability and reuseability. In addition to these qualities the non-functional requirements to be met often include performance and reliability that require an intimacy between the implementation language and the deployment platform.

For the development of distributed, real-time, mission-critical software and computing infrastructure it is essential that the underlying platform and programming language are considerations during analysis and design phases through to in-service deployment. Less-demanding problem domains have weaker constraints where the business requirements can probably be realised by any number of possible implementations however this is not the case with the subset of critical applications we are referring to here.

Importance of C++, STL, Corba/IIOP, ACE, Boost for teaching and systems development

Well beyond C with classes, C++ is the quintessential system-programming language, offering a rich toolkit of implementation idioms that can be exploited by experienced programmers in addition to a simple programming model that can be used by novices. The facilities of object-oriented programming, generic programming and functional programming enable C++ to be a first-class language for building Domain-Specific Languages (DSLs) and in unsurpassed in this role by any other language. The C++ features of extension by derivation coupled with operator overloading enables new types to be defined that operate in the same way as built-in types.

The Standard Template Library (STL) is a rich, contract-based set of iterators, containers and algorithms that enables well-defined behaviour on template (generic) types and through extension achieved via traits (template specifications) without adhoc language extensions for run-time type introspection. As powerful and general-purpose as are languages like Ada, Java and C# they cannot replace C++ in defence, telecoms and control systems, on scales from embedded systems to supercomputing.

While C++ has a solid standard-based definition since 1998 and has facilities provided by ACE and Boost libraries, for example, other languages that are its competitors (and some allege its superior) have required numerous language extensions in order to add basic facilities that mirror C++ features, usually weakly, which are part of the core language. For example, generics and templates in Ada, Java and C# are less powerful than C++ templates; and containers provided by STL have poor cousins in Ada generics, Java and C#.NET container libraries.

C++ and Corba/IIOP (Internet Inter-ORB Protocol) are the premier software and integration standards in use across the majority of systems today even though EJB/IIOP (Enterprise Java Beans) and various .NET Channel bindings to Corba/IIOP are not so well known. The increasingly popular, though limited, Java and C# programming languages, while they are eminently suitable for business programming, are unsuitable for many application domains in embedded, real-time, control, safety-critical and reliable systems.

Importance of Spark and Ada in teaching and developing reliable systems

Ada in widely used in defence, NASA and avionics where mission-critical systems are deployed, for example, embedded systems in the Boeing 777 and 787 run Ada code because the systems require highly-reliable, mission-critical software. Ada allows developers to prove security properties about programs, for instance, the ability to prove that a variable is not altered while it is being used through the program; and Ada supports comprehensive static analysis for dissecting the program flow to ensure correct behaviour.

SPARK is a high-level programming language and toolset designed by Praxis High Integrity Systems for writing software for high integrity applications. In their words, "SPARK gives confidence in the correctness of code – it is verifiable. Early detection and prevention of defects reduces the cost of verification and validation. SPARK is a very portable language and has minimal run-time system requirements. SPARK is used on safety-critical systems, primarily in the Aerospace, Defence, Rail and Security industries. It is suitable for use wherever there is a desire to produce high-quality software which behaves in a predictable manner."

As a teaching aid in software engineering, a research tool in universities and other institutions, and as an implementation language for many applications in the Australian context, Ada and SPARK are suitable languages for safety and high reliability and their use should be encouraged where appropriate.

Research and teaching recommendation

I strongly recommend the continued teaching of C++ and the allied technologies of STL, ACE, Boost and Corba at our universities. The Adaptive Communication Environment (ACE) is a highly-regarded object-oriented network programming toolkit used for writing sophisticated concurrent, parallel, and distributed applications. Systems built upon ACE are widely deployed across many problem domains and industries including telecommunications, defence, aerospace and finance. In addition, I recommend that we create specific programmes for research and teaching of Spark and Ada.

We should have programmes of research supporting the development of advanced systems built on these technologies otherwise we continue to run the risk of falling further behind, both technologically and economically, as a nation in this area. A concerted effort is desperately needed to create and fund one or more centres of expertise to develop the required skills and drive the research programme in addition to the broad-scale evolution in the content and structure of teaching and practice.

Recognising that Java and C# are already in widespread use and it is likely their continued growth will lead them to dominate wide-scale software development in the future it is important to study these languages. However, C++ in particular must continue to be taught to undergraduates so it can be satisfactorily deployed in industry.

Enterprise Systems Development

There are many reasons to extend good practise to Java/J2EE, EJB/IIOP, C#.NET and SOA systems in the enterprise systems space. The same lessons that apply to good software and systems engineering in general naturally apply also to enterprise systems development however there is much less attention paid to rigour this field by academics and industry participants. Most enterprise software development involves integration of COTS systems using various integration technologies, including EJB/IIOP and service-oriented architecture (SOA), with custom applications written in a range of technologies including Java 2 Enterprise Edition (J2EE) and C# on the .NET platform.

Prof. Ian Sommerville, one of the worlds eminent leaders in software engineering (author of the leading text book and himself known as the "Father of Software Engineering") emphasised in his keynote talk at ASWEC 2008 that enterprise software includes health and medical systems, defence and logistics systems, aerospace systems and airspace management, in addition to the mission-critical applications for corporations including enterprise resource planning (ERP) and many other systems. He said that the direction in which enterprises are heading includes construction by configuration and integration of COTS components so it is important for research programmes to be created in these areas.

One problem is that the time frames of enterprise systems development span many months or years for a strategic programme of work and these time frame do not fit the normal academic time frame for publication. As already pointed out, it is essential that such efforts include experienced industry practitioners however their involvement depends upon commercial and R&D funding that is very difficult to access, in addition to the need to break down the notional barriers between academia and industry.

The report entitled The Challenges of Complex IT Projects by the Royal Academy of Engineering and the British Computer Society states, "there is a broad reluctance to accept that complex IT projects have many similarities with major engineering projects and would benefit from greater application of well established engineering and project management procedures. For example, the importance of risk management is poorly understood and the significance of systems architecture is not appreciated."

The report goes on to paint the general direction that needs to be taken in order to remedy the situation facing organisations which undertake complex IT projects. Two key recommendations are: 1) There is an urgent need to promote the adoption of best practice amongst IT practitioners and their customers; and 2) Basic research into complexity and associated issues is required to enable the effective development of complex, globally distributed systems. The discussion and recommendations in this report are strongly relevant and applicable in the Australian context.