Saturday, May 31, 2008
Is Technology Change Management an Oxymoron?
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.
Sunday, May 18, 2008
National Innovation Review
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.
Saturday, October 27, 2007
ICT WA 2007
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.
Wednesday, September 05, 2007
Document Format Wars
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 |
1 | 2 | (3) | 4 | 5 | (6) | (7) |
MB1 | Clause No./ | Paragraph/ | Type of com-ment2 | Comment (justification for change) | Proposed change | Observations |
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.
Tuesday, August 07, 2007
Strategic Engineering Management
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
Saturday, June 23, 2007
Software Engineering For Plant Control
Thomas Fox from WA Water Corporation spoke about SCADA System Management after me. Following a break for morning tea Greg Belcher from Honeywell Australia spoke about Securing your Control Systems in a Windows World; followed by Bob Erickson of Matrikon Australia talking about Practical OPC Applications for your plant. After lunch, Vincent Tsang of Dimension Data gave in introductory talk called Networking 101 and Jeff Alexander gave a general talk about Microsoft's Perspective for your Critical System. We had a stimulating Panel Discussion and afternoon tea before the symposium closed.
Having never before given a talk on this subject matter to this kind of audience I worked quite hard beforehand with the conference organisers to hone my presentation so that it would be of interest to the target audience. To my delight I received some great feedback about the relevance of the systematic approach taken in software and systems engineering to the practice of control systems engineering, the design and implementation of plant controls. My original background is in electronic engineering, control systems and communications so I felt an immediate affinity with my audience and was already familiar with the problem domain.
This talk allowed me to explore more deeply some of the processes that contribute to quality outcomes in systems design in the context of plant control and how some of the usual work practices can be improved. My approach resonated with at least a portion of the audience because I received immediate feedback in direct questions and afterwards in discussion including potentially several invitations to consult with attending organisations. One question pointedly asked about security issues and I confessed to skirting issues related to HMI(*), SCADA(*), security and DR(*) in deference to other speakers who, as it turned out, covered relevant aspects of these topics very competently.
The scale of the Water Corporation's network across the state of Western Australia is breathtaking; over 200 towns serviced, several major and many secondary water and waste water treatment plants. The plan to extend the current SCADA network to the entire service area and all plant is an enormously complex exercise. Of the budgetted capital spend to average $1B per annum over the next 20 years some $40M+ per annum will be spent on control and IT systems. The innovative control centres being built to supervise the network and work with major SCADA suppliers ABB and Serck on these upgrades is impressive, as reported by Thomas Fox. I will avoid going into details about security except to pass comment that Water Corp is a world leader and as a result was invited to represent Australia at the Idaho conference organised by the US Department of Homeland Security. The talk by Greg Belcher about Honeywell's integrated security and plant control systems offered quite a few insights into the complexity of the planning process and the richness of the integrated solution provided by vendors such as Honeywell.
The talk about OPC(*), was interesting insofar as a standard is emerging to replace the mutiplicity of FieldBus-type communications protocols that are prevalent in current plant deployment of DCS(*) and PLC(*) systems. There are several problems with OPC: 1) It is based on OLE(*), that is based on COM(*) and DCOM(*); 2) Complex set of open connectivity standards that are slowly emerging from the shadow of Microsoft; 3) uses many ports, like DCOM; 4) security issues; 5) performance issues; 6) not comprehensive; 7) not unified standard but it is getting there with OPC Unified Architecture. The networking talk and the evangelical presentation from Microsoft may have filled in a few gaps in knowledge for the less-IT aware members of the audience, primarily of control systems engineers and others involved in plant control.
Some of the most interesting discussion of the day centred around issues and breaking down barriers between plant control engineers and IT practitioners. While the high-level objectives of the organisation may be common to both groups their own distinct subgoals often seem to lead a lack of cohesion and alignment in achieving those shared objectives. The willingness of members of both groups to cooperate and to communicate efectively is sometimes uncertain however with management support the reality is that engineers can crossover from one discipline to the other. As with any change process it is possible to make progress but only if senior management buys in and is supportive; often plant control lacks a seat or even a voice at the executive table.
(*) Glossary of Terms:
COM = Common Object Model; Microsoft's component model based on DCS-RPC
DCOM = Distributed COM; Microsoft's distributed component model based on DCS-RPC
DCS = Distributed Control System; for networking PLCs
DCS-RPC = Distributed Computer Systems-Remote Procedure Call (not to be confused with control DCS)
DR = Disaster Recovery; practices for recovering from system failures
HMI = Human Machine Interface; the front end for SCADA and DCS.
OLE = Object Linking and Embedding; Microsoft's document embedding model
PID = Proportional-Integral-Differential loop controller
PLC = Programmable Logic Controller; often includes PID regulator
SCADA = Supervisory Control and Data Acquisition; step up in abstraction from DCS.
Monday, May 21, 2007
Board or Committee?
It is always a good idea for a prospective director to do proper due diligence on the organisation, its other directors and management. The new appointee should expect a letter of appointment setting out their duties, responsibilities and obligations as well as rights as a director and member of the board, in addition to undertaking an adequate form of induction as to how to carry out their new function as a board member. Remember that the organisation has systems and process, delegations to the general manager or a chief executive, retained board rights, perhaps subcommittees and be bound by relevant laws in addition to those relevant for all boards. The acts concerning occupation health and safety, the Trade Practices Act and the Corporations Act are relevant to directors in virtually any sphere. How about directors of nonprofit organisations?
There is in fact very little difference insofar as directors are bound to act in good faith and with due diligence, for a proper purpose and in the interests of the members, without personal gain from inside information and while avoiding real, and declaring perceived, conflicts of interest. That seems a lot of responsibilities; how about rights? Directors have the right to view minutes of board meetings for which they were directors, whether present or not; and each director is entitled to seek independent legal advice. The scale and access to such rights should usually be clearly set out in the letter of appointment. Directors usually cannot be dismissed except by a general meeting; they can of course resign. What about when the directors are acting in a volunteer capacity as appointees of other member organisations?
As before, nothing really changes. Directors are bound to act in the best interest of all members and not just the organisations that appointed them to the board. Usually the only directors that can be dismissed other than by an AGM are executive directors who are usually dismissed from the board when they contract if employment is terminated. For appointees from member organisations the appointment and replacement of directors should be clearly spelled out. What if an individual director chooses to act in the best interests of the organisation that appointed him instead of in the best interests of all of the member organisations?
The entity that appointed the person as director can be taken to be a shadow director that is directing the organisation of which it is a member. The director can personally be liable to civil sanctions for not acting in good faith for all the members. The appointed director and the shadow director, being the organisation that appointed him, may be liable for obligations entered into by the organisation for which they are acting as directors. For example, if the organisation becomes insolvent at a time when it can no longer reasonably meet its debt obligations because one or other of the members withdrew guarantees to meet those debts then the shadow directors can find themselves obligated if their actions, seeking to benefit the organisation that appointed them rather than the members as a whole, brought about this situation.
The question of who is the party to take the action against the directors is generally answered as the company itself being the proper plaintiff. The sands continue to drift towards more traditional civil action as if a tort against the responsible directors for failing in their duty of care, essentially being negligent as opposed to being diligent, rather than the gnashing of teeth needed to direct the company to take, in practice to fund, action against its own directors.