The need to build complex systems - smarter
In today's world, innovation is increasingly being delivered through software. Robotic surgery has today resulted in a six fold reduction in mortality rate of bypass surgeries when compared to the days when an individual practioner in the operation theatre reigned supreme. The number lines of software code in today's automobiles compared easily with that in a fighter jet. It is not surprising today, that complications of a fighter jet are being brought into software written for consumer goods. Software is indeed invisible thread that runs through thousands of enabled, interconnected systems that communicate to achieve ends. Despite the growing influence of software in driving systems-of-systems in heterogeneous ecosystems, the disciple of software development and delivery today seem to be just adequate to the task. There is a need for a better approach towards software and system delivery which needed to evolve beyond the pure engineering measures of cost, quality and risk to a more econometric approach of being able to manage uncertainty by regular and accurate measurement of value.
An example of the complexity of software and an example of what constitutes a "system of systems" is General Motor's Chevrolet Volt. General Motors used IBM's suite of Rational software products to develop some of the Chevrolet Volt's critical electronic controls for the vehicle's innovative battery system, electric drive unit, and cabin electronics. IBM's work to help streamline General Motors' design process resulted in the electronic backbone of the car from concept to finish, being completed in a record 29 months. The Chevrolet Volt contains more than 10 million lines of code with over a 100 electronic controllers communicating with each other - a system of systems. Cars in today's market have indeed been software heavy, with electronic control units (with complex software embedded) communicating with each other regularly over serial bus networks like CAN, GMLAN etc. However, GM has stretched the use of software systems by using software for tasks such as thermal management of the lithium battery (to make it last longer?) etc. Additionally, there are applications in the in-car devices for example, that can download a party invitation from Facebook etc to the vehicle's navigation system, and have the car provide the directions to the party ...automatically. In fact, each car has an associated IP address - making it a potential data center on wheels!! Software is indeed the heart and soul of this car. (Apparently, though IBM Rational Software tools were used heavily as part of the development process, there is no IBM software in the car.)
Applications and systems today are inevitably multi-platform and complex. What add to the inherent complexity are the pressures of increased regulatory compliance requirements in products, cost reduction, changing requirements, globally distributed software and product supply chains etc. There is a need for innovative tools to support real time planning (improving time to delivery), life-cycle traceability maintenance (improve quality), collaborative development support etc
Predictability of software delivery had to be improved using honest measurements. Recollecting what Walker Royce, (Chief Software Economist at IBM) had mentioned in his talk at the same conference last year, software is all about dealing with uncertainty - which seemed to make it more an economics-based disciple than an engineering one. The biggest challenge is to reduce uncertainty -and regular and honest measurement helps reduce that uncertainty. The point is not just to focus on delivering to the plan, but rather to remove the uncertainties early enough by modeling, developing POCs, questioning etc. Rather than measuring progress by a sequence of documents and artifacts (activity based, document baselines), it is important to demand a sequence of demonstrable results which are result based (code, test baselines). Artifacts such as static design models, API documentation etc. fuel dishonest early optimism, when the need is to demonstrate capability and measure quality by developing dynamic models (modeling, simulation etc). Only relying on static artifacts often result in false precision (unmeasured) which affects predictability down the line. It is important to avoid postponing analysis of architecturally significant risks to reduce variance in the estimated cost to completion. The IBM Rational Suite used in the development of the Volt, enabled engineers to quickly make changes in the system and predict the results on-the-fly as development progressed, thus enabling course corrections early enough in case of issues.
A lot of what is discussed is obviously known. However, considering that software systems today have fiscal and societal impacts and that the outcome of development of complex heterogeneous eco-systems are becoming increasingly difficult to trace, understand and predict, Application Lifecycle Management methodologies and tools have to adapt and innovate accordingly. IBM's Rational Team Concert (based on the Jazz platform), Microsoft's VSTS (Team Foundation Server) are some of the popular tools in this space. (As part of its interest in seeing tool adoption being incorporated as a part of engineering curricula, IBM has opened up a limited beta of the Team Concert hosted on the cloud -called JazzHub- for the open development of academic research and classroom projects in universities.)