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.

ICT WA 2007

The conference on Friday 12 October at Technology Park Function Centre was a great success with excellent speakers complemented by worthwhile networking between the diverse, individual participants - much as a reflection of the diversity of the IT industry in WA. The formal opening by the Chair of ICTICC, Valerie Maxville was followed by the opening address by The Hon Francis M Logan MLA, The Minister for Resources, Industry and Enterprise.

In addition to Fran, we were joined by Dr Judy Edwards MLA, Member for Maylands, in a great demonstration of support from the government. I was privileged to be able to speak with Judy about several issues and was gratified to find that she was happy to talk to me about ICT and wider industry issues and has a solid understanding of the subject matter.

The keynote speakers were Vince Troth, GM of Optus in Western Australia who deferred to Dean Smith, GM of Government Affairs to elaborate on the OPEL Joint Venture under Broadband Connect; and Dr Nick Archibald, Executive Vice-Chairman and CEO of Geoinformatics Exploration, who spoke about the ICT challenges in mineral exploration.

The Chair, Valerie Maxville, first spoke of the whole ICT Week which sought to emphasis the ICT WA brand. The week kicked off with the eWaste Collection event 'bring out your dead' computers and other ICT equipment, that doubled expectations in an initiative on environmental commitment. The Women in ICT and Engineering luncheon that was playfully and meaningfully entitled, 'Lack of Women or an Excess of Men? Strategies for Cultural Change,' was a sell-out event, where Jaye Radisich, MLA spoke about similar challenges she has faced in the political arena.

The WA DIG 24-hour gaming event and expo held at the Perth Convention Exhibition Centre showed a range of diverse careers in ICT apart from programming. The ICT WA Portal is under development and will offer information on careers, education and career prospects. Valerie welcomed input into development of the portal, intended to sell ICT WA. She also raised the issue of career and training and strategies for combatting the skills shortage; combined approach of industry, government, education and community organisations.

Francis Logan told an anecdote from the time he was studying economics at Sydney Uni and spoke with Laurie Carmichael, famed union militant of the Amalgamated Engineering Union (AEU). He was a visionary, into model railway collecting, roses and classical music (we promise not to tell anyone), who was ahead of his time in foreseeing the use of computers for organisation and communication.

Fran (as he is known by all and sundry) welcomed the Hon Dr Judy Edwards, Member for Maylands, then spoke about the inquiry, ICT Industry Development Strategy and the earlier Enabling Future Prosperity (2004 by Clive Brown), where his government had implemented 34 of 42 recommendations by March 2006 at $60M cost. This included the creation of ICT ICC (convener of this conference), a great initiative, allowing the ICT industry in WA to speak as 'one group with one collective voice.'

The launch of Project Connect on 27 Sept 2006 supported by the WA Branch of ICN (Chamber of Commerce and Industry), to identify opportunities in government and industry and advising registered companies of those opportunities (www.ictwa.com.au). The WA ICT Capability Directory, currently with 153 companies registered, promotes the WA ICT industry. The ACS Foundation scholarships for under-privileged groups are a point of pride, supporting Aboriginal and Torres Strait Islanders, financially disadvantaged, regional and academically gifted. AIIA development of business skills for entrepreneurs programme; iVEC funding including the APAC conference (this week); 4 Oct Open Source Symposium.

The establishment of Interzone, the third-largest gaming and digital content developer in the USA, in WA. The SKA (Square Kilometre Array) will need massive computing power. The Statewide Broadband Network to link all of government. Tech Park (where this conference is hosted) is a critical part of growing ICT industry in WA. 'Beyond the Boom' - ICT, Marine, Biofuels and Renewables, Biotech expect infrastructure investment of $22B over the coming years. Australian Marine Complex (AMC) - $300M. WA Institute of Medical Research (Prof. Fiona Stanley).

AMC - modular shipbuilding, oil and gas, process facilities, crainage, dry dock to 13,000t ships. Plan to assume control of Department of Agriculture land ~20ha - expect master plan around xmas or early next year - to transform facilities, town centre, shops, apartments. To make Tech Park a dynamic place to work, live, entertain and to be entertained, to showcase WA ICT - the state's largest cluster.

Document Format Wars

Microsoft has proposed to fast track its Open Office XML (OOXML) definition for documents produced in Office 2007 as an ECMA and ISO standard. Their intention is to capture the XML schema that defines the structure of Office 2007 documents including backward-compatible binary components that provide support for documents produced by earlier versions of the office product. These binary component definitions are specific to Microsoft products and are not capable of being produced with or without the OOXML definition.

The Open Document Format (ODF) for Office Applications (OpenDocument) is supported and promulgated by the Organization for the Advancement of Structured Information Standards (OASIS) and is enthusiastically supported by a growing band of followers. The reason for the strong following and broad-based support is that ODF is a well-designed and open definition that can be implemented by any party without the need for any additional information apart from that in other open definitions and international standards, like Scalable Vector Graphics (SVG).

OOXML, on the other hand, replicates the equivalent behaviour of numerous open format definitions and existing international standards. Among many others individuals, I submitted technical objections to my national standards body (Standards Australia) of the proposed standard on the basis that OOXML is a long and overly complicated definition of a document format that can only be implemented in full by Microsoft.

To: michael standards.au
cc: daniel systec
Subject: DRAFT INTERNATIONAL STANDARD ISO/IEC 29500, Information technology ?
Office Open XML file formats.

Dear Michael,

I humbly submit a few comments about the proposed DRAFT INTERNATIONAL STANDARD ISO/IEC 29500, Information technology ? Office Open XML file formats.

Please contact me if I can be of any further assistance.

Regards,
Daniel
--
Daniel M. Berinson BE PhD MIEAust MIEEE AFAIM GAICD
Managing Director, Systems and Software Architect
Systec Engineering Pty Ltd and Systec IT
daniel@systec.com.au
040 888 0278 (m)

Template for comments and observations

Date: Due to Standards Australia by COB 21 Aug 2007

Document: DRAFT INTERNATIONAL STANDARD ISO/IEC 29500 Information technology — Office Open XML file formats

1	2	(3)	4	5	(6)	(7)
MB1	Clause No./ Subclause No./ Annex (e.g. 3.1)	Paragraph/ Figure/Table/Note (e.g. Table 1)	Type of com-ment2	Comment (justification for change)	Proposed change	Observations on each comment submitted

AU	1		ge	The document is overly long (over 6,000 pages) and complicated to be an effective specification for implementers.	Shorten the document for this standard by either: 1) partition the supporting material into several other standard proposals; or 2) amend with reference to appropriate standards.
AU	1		te	The document refers indirectly to binary implementation details that are not part of this proposed standard nor are they part of other existing or proposed standards.	Delete references to binary materials and delete references to other materials that are not part of an existing or proposed standard.
AU	2.15.1.28		te	Conflicts with ISO 10118-3 and W3C XML-ENC by defining nonstandard hashing and cryptographic algorithms (likely to be insecure).	Amend with reference to standards that specify hashing and cryptographic algorithms that are know to be secure.
AU	2.15.3.6		te	Example (one of many) of implementer being required to clone unspecified behaviour.	Specify explicitly the required behaviour; otherwise delete references to unspecified behaviour.
AU	2.18.52		te	Conflicts with ISO 639 by requiring the use of a fixed list of numeric language codes rather than the already existing set provided by ISO 639.	Amend with reference to appropriate standard.
AU	2.18.105		te	Refers to nonstandard twips.	Amend with reference to standard units.
AU	3.17.4.1		te	Conflicts with the Gregorian calendar in the calculation of dates by requiring spreadsheet implementations to incorrectly treat the year 1900 as a leap year.	Amend to conform with Gregorian calendar.
AU	4.4		te	Conflicts with W3C SMIL by defining nonstandard multimedia features.	Amend to conform with appropriate standard.
AU	5.1.10.45		te	Example (one of many) of inconsistent and poorly named XML elements.	Revise XML element names and type design (i.e. well-designed complex and simple types).
AU	5.1.12.42		te	Refers to nonstandard English Metric Units (EMU).	Amend with reference to standard units.
AU	6.2.3.17		te	Refers to Windows Metafiles or Enhanced Metafiles instead of using ISO/IEC 8632 or W3C SVG.	Amend with reference to appropriate standards; otherwise delete references to proprietary materials.
AU	6.2.3.23		te	Refers to Microsoft namespace (urn:schemas.microsoft.com:office:office).	Amend to appropriate open namespace.
AU	7.1		te	Conflicts with W3C MathML by defining nonstandard format for mathematical expressions.	Amend with reference to appropriate standard.
AU	8.6.2		te	Conflicts with W3C SVG by requiring support for VML drawing format (not a standard).	Amend with reference to appropriate standard.

1 MB = Member body (enter the ISO 3166 two-letter country code, e.g. CN for China; comments from the ISO/CS editing unit are identified by **)

2 Type of comment: ge = general te = technical ed = editorial

NOTE Columns 1, 2, 4, 5 are compulsory.

page 1 of 2

ISO electronic balloting commenting template/version 2001-10

Grokdoc has pages of contacts, objections and Microsoft's history of dirty tricks in opposing development that supports open standards to the detriment of proprietary standards. As it turned out, the fast-track proposal failed the vote so the final outcome has been deferred - however this state-of-affairs is a cop-out due to the late elevation of formerly uninterested national standards organisations from observer to participating (voting) member status. I regret to say that even Standards Australia abstained, as an unfortunate example of bureaucratic nonperformance.

Worse still is that the problem has not gone away since the fallout from the debacle is that standards work in the relevant working group has ground to a halt. The situation is an embarrassing debacle the blame for which we can lay at the feet of Microsoft and many other organisations that are either corrupt, naive or inept.

Strategic Engineering Management

It's about time I start serious planning for the course I have been privileged to be invited to lecture the Strategic Engineering Management component of a fourth year course in the Electrical, Energy and Process Engineering School at Murdoch University. The engineering course deliver a strong, cross-disciplinary foundation followed by instrumentation and control, industrial computer systems, renewable energy and electrical power specialisations.

There is a cluster of concepts and practices that form the core of strategic management as a transferable discipline and set of skills that can be applied across a wide range of enterprises. The material I wish to present and the way I present it is very much shaped by my personal experience as a contractor and consultant, practitioner and researcher, practicing, speaking and publishing in the technical side of software and systems engineering and engineering management, leadership and strategy.

I credit the Australian Institute of Management (AIM), the Australian Institute of Company Directors (AICD) and the Company Directors Course (CDC) that I have completed to diploma level for contributing to my understanding of management, leadership and strategy (encouraged by my father); in addition to my long-standing memberships of the Institution of Engineers Australia (IEAust), Institution of Electrical and Electronic Engineers (IEEE) and IEEE Computer Society that have added much to my foundation technical background of my undergraduate degree in Electrical and Electronic Engineering, and postgraduate studies in Physics and Mechanical Engineering at the University of Western Australia.

The AICD CDC was for me a master class with some of the top executives and directors in Perth attending and just a handful of independent and small-company directors like myself. For many of the senior attendees I am quite sure that much of the material was well known and perfectly well understood by them beforehand however I like to think they gained something from the interaction with the presenters, each and expert in the subject-matter they presented during the week of full-time, intensive tutorials, case studies and discussion.

The management structure of organisations is key to understanding the role played by managers in formulating and executing strategy. The board of directors (BOD) of an organisation are tasked in Australia by the Corporations Act to act with due diligence and in good faith for the best interest of the members, usually understood to be the shareholders. The BOD will often take a different approach in startup and some high technology companies however in most mature organisations they will appoint management and delegate certain authorities to that management. Usually this is done via a managing director (MD) or chief executive officer (CEO) who is formally appointed as a staff member who also sits on the BOD as an executive director by virtue of his employment contract (as distinct from other directors who are appointed by the members-shareholders).

The key roles of the MD or CEO include the appointment of other managers and staff, the formulation and execution of strategy, the institution of processes and systems to manage the organisation and organisational risks, the negotiation, authorisation and signoff of contractual and other agreements, the preparation of reports and oversight of the day-to-day running of the organisation. At the same time, the BOD may retain certain authorities including the right to approve the appointment or dismissal of certain senior managers, for example the chief financial officer (CFO) or chief information officer (CIO) among others, the right to contribute to, vary or accept the strategy put forward by the CEO, the right to speak with senior officers of the organisation, the right to approve or deny contracts or agreements above a certain monetary limit or other conditions, the right to receive and ask questions about reports on business operations, the management and mitigation of business risks including both financial and nonfinancial risks.

Which brings us to engineering management, human resources, technology and the management of innovation which define the focal point of our discussion on strategic engineering management. In most management text books and reference guides the management of innovation and technology gets a relatively cursory treatment whereas human resources is rightly regarded as a central facet of management and leadership. Our focus here should be on the management of engineering and technology, the people aspects of innovation in regard to strategic management while acknowledging and reflecting on the close and - relationship between strategic management and project management in this sphere.

It is useful to consider intellectual property, business secrets, patents, copyright, trademarks and design registrations over processes and documents that give a business the edge, so-called core competencies that distinguish one company that excels in its fields of excellence from its relatively mediocre competitors. The knowledge portfolio of an organisation and the management of that knowledge is paramount to the mature organisation retaining its competitive advantage. Knowledge management includes metadata descriptions and the capture of process definitions and guides, best practice quality systems (ISO 9000, six-sigma, CMMI, and so on) and extends to the development of an innovative culture where the best and brightest are attracted and retained by the employer of choice who provides a culture of excellence in an exceptional workplace environment.

Patents are legally-sanctioned, restricted monopolies over the innovative process characterised by the description and statement of claims in the patent application. More to be said here, including perhaps some of my own experiences in the preparation of patent documentation for third parties and considerations for high-technology, software and other engineering companies.

Steven Covey's Eighth Habit otherwise widely and long known, if misunderstood, as encouraging entrepreneurial employees, technical advocates and potential leaders to find their voice, to speak and and be heard by the organisation. The culture shift that is required by management to encourage and stimulate such an innovative culture can be a great challenge for traditional leaders to inculcate in their colleagues and for the forward-looking leader to persist in propagating through their organisation. As W. Edwards Dening, the doyen of Japanese post-war statistical quality control, has emphasised that, "The problem is at the top; management is the problem," insofar as aspirational leadership has to come from the top while recognising that business transformation is part of everybody's job.

HBR Spotlight, March 2007, Leading Clever People by Rob Goffee (london.edu) and Gareth Jones (london.edu) points out that clever people want to work without artificial impediments being put in the way of their way. Their perception of management is shaped by the efficacy with which they can acquire the resources they need to get the job done without undue process constraints or other rules getting in their way. While their focus is on getting the work done in their technical areas of expertise it is paramount that management listens to the concerns and learns from the though leaders in their organisations. Whether by instituting formal or informal forums, ensuring they are informed of various nontechnical issues of relevance, invited to key meetings, and so on, it is important to get input and buy-in from them.

There are a raft of other issues that may be peripherally considered part of strategic management or rightly outside the direct scope but certainly within the consideration of general management. Doubtless there is significant overlap between general, operational, strategic, project and change management. Change management - people, process, technology - applicable to all scales of business, enterprises, industries. The organisational objectives set out in the charter or constitution; default constitution or statement of specific objectives, esp. nonprofit organisation, clubs and associations that may have specific and often narrowly-focused objects.

Risk management is complementary to strategic and project management; whereby reputational risk may be considered at the top of the list of risks to be managed; including mandatory compliance with relevant legislation and regulation - exp. Companies Act, Trade Practices Act (TPA), Occupation Health and Safety (OH&S); ASIC and state consumer affairs, business registration and licensing; ASX Governance Principles for list public companies.

The culture of an organisation permeates every layer of management, divisional and work groups - safety culture in utilities and miners; corporate values and organisational culture from directors and executive, throughout all tiers, from the top-down. Risk management; processes, systems; education, monitoring and sanctions; business, financial and reputational risks; corporate social responsibility (CSR) and triple bottom line. Governance - corporate, financial and IT; annual agenda, audit plan for finance, IT and systems. Strategy assessment: integrity model (CASFA), horizons model.

Financial considerations: NPV and payback period, risk-free interest rate, cost of deferral 6 delays, opportunity cost and organisation potential.

http://en.wikipedia.org/wiki/EABOK

http://en.wikipedia.org/wiki/Porter%27s_cluster relevance to local tech parks, Aust Marine Complex, gaming/iVec and Uni courses. More to be said on this matter.

Case Studies:

• new and existing businesses - like business and marketting plan but not the same (subset or overlap?)
• new city; new winery; new product; new process; new plant
• infrastructure work (eg. Subiaco and East Perth redevelopment authorities; LandCorp); public/private partnerships (PPP) and risk sharing; new or shared mining infrustructure
• controversy over Fortesque access to BHP rail infrastructure
• issues and planning; energy-efficient bauxite/alumina, nickel and low/high grade iron processing (haematite/magnetite)
• ore crushing, fines, magnet separation, pelletising; copper and lead processing
• coal gassification, carbon sequestration, alternative energy, wind (leader), solar, geothermal
• nuclear, environment impact, policy risk, uranium mining and processing policies; government regulation, Environmental Protection Authority (EPA)
• Woodside Pluto on Burrup, Aboriginal art destruction and relocation
• Japanese LNG gas prices, Chinese contract, spot versus long-term contract; price of energy
• trading carbon credits, carbon caps and cost of capital, relocation of plant to lower regulated countries
• climate-change greenhouse warming science, IPCC and hockey stick controversy; CO2 capture
• SCADA/PLC upgrades; OPC and open-source == proprietary, sole source and multivendor; platform security and robustness
• evolving relationship of control systems and IT (eg. Western Power, Water Corp)
• BHP Billiton value proposition for mooted merger with Rio Tinto
• Western Power proposed Eneabba to Moonyoonooka 330 kV transmission line