ESP – Product Engineering – Platform and Software Products

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) | TrackBacks (0)

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) | TrackBacks (0)

C++0x is going to be the next ISO C++ standard which will replace the existing C++ standard C++03. It was earlier scheduled to be released in 2009, but most likely will get released in 2011. We will probably see it rechristened to C++11 once released. This new standard will have several additions and improvements to the core language and will extend the C++ standard library. The last publicly available working draft of the new specification was submitted on 28th Feb, 2011 and is available for public access here. For the C++ developers all over the world working on Internationalization of software; the most awaited improvement to the C++ standard is going to be native Unicode support. Will C++0x meet all the Unicode requirements or will developers still have to depend on third party libraries like ICU, Rosette, Boost etc for their i18n development?

The basic requirement of any programming language to support Unicode is to provide support for string processing in the UTF-8, UTF-16/UCS-2 and UTF-32/UCS-4 encodings and be able to convert values between these encodings. UTF-8 is a multi-byte character encoding which uses one or more bytes to encode each character. UTF-32/UCS-2 is wide character encoding which uses fixed size 32-bits/16-bits respectively to represent each character. UTF-16 which is a 16-bit encoding is not a fixed width character encoding because of its support for surrogate pairs which are outside the Basic Multilingual Plane (BMP). UCS-2 is a 16-bit character encoding that matches the entries in the BMP of UTF-16. UCS-4 is a 32-bit encoding and is similar to UTF-32.

Traditionally C++ has been a programming language that did not have native support for Unicode. Since the standardization of C++98, Programmers only had two native character types at their disposal for string processing - char and wchar_t. The char data type is 8-bit in length while the wchar_t which is used for wide character representation is 16-bit on Windows and 32-bit on UNIX systems. The C++ language specification does not define the size of wchar_t. Since wchar_t has an implementation defined size, it makes it unsuitable for handling Unicode strings portably and reliably. The wchar_t data type has wide character support but it knows nothing about the semantic value of the data stored in it. Moreover UTF-16 and UTF-32 are not byte oriented, so developers have to be very careful while passing UTF-16 or UTF-32 string data between Windows and UNIX systems. Developers are faced with such challenges while working on client server applications in C++, where the client is on windows and the server is on a UNIX platform or vice-versa.

The char data type is typically used for single byte character encodings, such as ASCII or the ISO Latin family of encodings. It can also be used with multi-byte encodings such as UTF-8. While wchar_t is widely used for providing UTF-16 Unicode support in C++ programs, it is in fact not a complete solution. UTF-16 cannot be supported by the 16-bit wchar_t data type on Windows because it cannot handle surrogate pairs. In order to provide the perfect UTF-16 solution, developers have to use third party libraries like ICU, Rosette, Boost etc. This not only introduces dependencies on external libraries (maybe even proprietary libraries), but even increases the size of the program. Moreover the encoding used by the system is locale dependent and most string conversion library functions are locale dependent. For years C++ developers have lived with such inconsistencies and native Unicode support for the language was very much needed.

So what does C++0x offer in terms of Unicode support? Does it provide a solution to all the Unicode issues existing in C++03 or do developers still have to rely on third party libraries for Unicode support? C++0x will have support for 3 encodings - UTF-8, UTF-16 (Partially) and UTF-32. While the char data type will support UTF-8, C++0x adds the character types std::char16_t and std::char32_t (and corresponding string types std::u16string and std::u32string) for use with UTF-16 and UTF-32 encoded string values, respectively. These character types will enable developers to use Unicode portably. The syntax for creating string literals for these encodings will be as follows,

const char ch8 = u8"This is a UTF-8 encoded string";  // UTF-8 string
const char16_t ch16 = u"This is a UTF-16 encoded string"; // UTF-16/UCS-2 string
const char32_t ch32 = U"This is a UTF-32 encoded string"; // UTF-32/UCS-4 string

char16_t data types can represent only UCS-2, because it is not possible to fit a UTF-16 surrogate pair (i.e. two 16-bit values) in a single char16_t variable. However it will support UTF-16 provided it is within the BMP. This essentially means that the limitation of C++03 for supporting UTF-16 with surrogate characters is also there in C++0x. Developers have to rely on third party libraries if they want full support for UTF-16.

C++0x also offers conversions among encodings using additional codecvt facets. In addition to this it also adds the possibility to have I/O based encoding conversions without changing the stream locale and in-memory encoding conversions. This will definitely solve a lot of encoding conversion issues for which developers had to rely on third party libraries.

Seeing the pros and cons of C++0x, it does seem that it is going to solve a lot of problems for developers who want to add Unicode support to their C++ programs portably and easily. For applications which won't support surrogate pairs, C++0x will be able to take care of Unicode support, else third party libraries might still have to be used. Whatever is the case, this is definitely a positive development for the C++ world and the development community is eagerly awaiting its mainstream release. GCC 4.3 offers C++0x support on an experimental basis. If anyone has used it, they may share their experience with the Unicode support provided.

Posted by Aviraj Singh at 4:41 PM | Permalink | Comments (0) | TrackBacks (0)