Engineering Services

Interestingly, there are actually more lines of COBOL being handled in enterprise applications in the world than Java - even today. It surely is difficult to imagine, considering that the latest TIOBE Programming Index for August 2011, still indicates Java to be safely ensconced right on top of the programming language list. (The TIOBE Programming Community index is an indicator of the popularity of programming languages based on certain parameters and is not about the best programming language or the language in which most lines of code have been written.). Regular maintenance/enhancement tweaks in billion lines of existing legacy COBOL code, actually turns out to be a lot of code being handled.

Despite what the TIOBE Index seems to indicate with regard to the ranking of COBOL among other programming languages, it does not mean that it is going to go out of favor for quite some time to come. Backend systems of large banks of the type of Bank of America, Citigroup etc. still rely primarily on their Mainframe infrastructure. In many countries, Mainframes are the backbone of systems that run railways, air traffic control systems, govermental systems etc. Infact, it is estimated that there are two hundred times more Cobol transactions, than Google searches in the world  - no wonder that, because mainframes is still what is running businesses all over the world even today. What that also means is that there are indeed a lot of 'legacy' systems that are still crucial to businesses today.

Businesses in the current economic climate need to innovate to remain competive and hence there is the urgent need to free up maintenance time, to enable innovation and remain relevant in competition. It is the volume and complexity in these systems that make CTOs pessimistic about taking the chance to modernize such systems so that there is less energy spent on maintaining them. Applications are not actively modernized or retired and thus increasing maintenance expenditure, resulting in reduced innovation. Forrester estimates that  70% of the IT budget is typically locked in maintenance and support.  Decades of investments on applications and infrastructure has resulted in reluctance towards adopting change to modernize, which in turn results in diminishing returns on those investments over the years. Infact, the joke is that people are retiring faster than applications are.

It is thus important for companies to think wholistic rather than adhoc to really maximize business value. Such companies need to take an inventory of applications, place them on an application portfolio map and then use dashboards to gain insights to allow deciding whether to retire, retain (consolidate, upgrade, rehost, convert) or replace(rewrite, purchase etc).

Interestingly, the existence of legacy and complex applications has spawned opportunities in developing application portfolio management applications and tools that analyze legacy systems. Even in a case where retiring or replacing is not an option, retaining existing applications also means the need to upgrade corresponding support tools - to new graphical user interfaces for developers, to initiatives to bring Cobol into the "cloud"etc, anything that could 'upgrade' the system to benefit without rewrite. COBOL may not seem to appeal to the current generation, but the fact is that there are even gaming companies (like this one in Brazil) that have in the recent past built systems around Mainframes.

The amount of code that has been written over the last decade is considered to have tripled, over what had been written earlier - you can imagine the amount of 'legacy' we are due to leave behind for the next generation to maintain - unless there are effective processes and tools in place to analyze and retire what is not worth maintaining, or modernize tools around existing systems.

Posted by Suraj Nair at 5:46 AM | Permalink | Comments (3)

Kristof Kloeckner (General Manager, IBM Software, and Rational) spoke at the IBM Software Innovate Conference at the Infosys campus last week - on the need to drive product/service innovation and ALM practices to be able to manage today's complex systems. Thought leaders in business, government and society are capturing the potential of smarter systems to achieve economic growth, sustainable development and societal progress. IBM's strategy as part of its Smarter Planet initiative is to enable many of the technology and process management capabilities - to help develop complex software systems that collaborate intelligently to solve the planet's pressing problems (water management, green revolution etc)

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.)

Posted by Suraj Nair at 11:24 AM | Permalink | Comments (0)