Infosys delivers concept-to-market software engineering services across the engineering value chain. Our blog will discuss the latest trends in software product engineering, outsourcing, technologies, and address business challenges.

« January 2010 | Main

February 18, 2010

True Integration with VSTS 2010

Microsoft (India) conducted the "VSTS 2010 Launch" session at the Infosys Bangalore campus this week to familiarize the software community with VSTS 2010 before the official launch (planned in April, 2010). The session included a keynote followed by an intensive hands-on demonstration of the various facilities that are on offer in the latest edition of Visual Studio Team System Suite. There were a number of features on demo, but what was of special importance was the support for the architect community in this release.

The Visual Studio environment, in all its various avatars over the years, has always been known to be an IDE (Integrated Development Environment) - but as a tool the focus has been more on its use as a 'Development Environment' used primarily by the developer community. The term 'Integrated' seemed to be a misfit with regard to how Visual Studio was generally used. However, with the VSTS 2005 suite Microsoft had signaled its intentions of developing Visual Studio into a complete Application Lifecycle Management solution providing tools for everyone involved in the lifecycle - be it the project manager, the architect, the developer or the tester. The Team Foundation Server along with its assorted client side solutions helped achieve this to a large extent. Microsoft’s new VSTS 2010 release builds on the same platform and provides a lot more.  A lot of what VSTS 2010 promises has to do with aligning to current technology trends (APIs for multicore programming, cloud computing etc.) and business needs (cutting costs by introducing more avenues for automation). Though you may argue that this has been true for the various Visual Studio releases over the decade, with VSTS 2010 this seem to have been a foremost thought considering that it was a ‘work under progress’ during the year of the 'Great IT Depression' - 2009.

There are a number of invaluable features built into VSTS 2010, but what is heartening is the importance that has been accorded to the architect community in this release. Microsoft has realized the need to support UML within VSTS acknowledging that UML is a hugely popular modeling language. As a result, one will no longer have to look at using other detached tools like Microsoft’s Visio or tools from Rational (Rational Software Architect for example) to model architecture and class diagrams - though the support for DSL (Domain Specific Language) is still retained in VSTS 2010.Significantly, VSTS 2010 also provides facilities to generate source code from UML diagrams and vice versa - a feature that has been considered an important USP of other like tools. VSTS 2010 allows a ‘work item’ or task (from the project management perspective) to be automatically generated from a use case diagram - for example, and assigned to a particular developer – an example of the integration of an ‘architect’ responsibility with a ‘project management’ responsibility.

With VSTS 2010, a lot of importance has been accorded to support maintenance/reverse engineering. Other than the ability to generate UML diagrams (sequence diagrams etc.) from code, VSTS2010 also provides a facility to generate dependency graphs based on assemblies, namespaces, classes etc. Dependency graphs help understand the dependencies between assemblies. In addition, it goes beyond to show details of the exact dependency in terms of the function call being made, the class object being instantiated across dependencies etc. This is of great importance today with a number of customers wanting to re-engineer legacy applications to modern technologies but having absolutely no relevant documentation in place to guide in the initial understanding. A recent project involved the need to re-engineer a native VB/C++ based application to .NET with nothing but the source code made available. In a world where time-to-market is all important, such projects do not involve a complete migration of the application. Rather, complex algorithmic engines are maintained ‘as-is’ in the native code base with the remaining parts of the application migrated to latest technologies to provide a more modern perspective to the end user. (Such native implementations are typically invoked using facilities available in the platform -JNI for Java, interop for .NET) The availability of dependency graphs helps understand the various components and the interfaces to those components without spending time on code reading.

Another neat feature provides the facility to allow the architect to monitor if the source code being developed is on the lines of the architectural decisions that had been written down.  For example, in a 3-tiered architecture, the normal rule is for the presentation layer to access the data layer only through the business layer APIs, but during development it is quite normal that such rules are ignored under pressure or as a result of bug fixes resulting in code which works but defies architectural decisions. Such deviations which break architectural rules will result in compile time violations in the VSTS 2010 Error List, thus allowing corrections early in the development life cycles without the reviewer having to point this out. According to Somasegar in his blog here - "The Layer designer enables you to define the logical layers and valid communication paths between layers of your project.  Once you have associated assemblies, namespaces, and classes with layers in the Layer diagram, you can validate existing or new code against the layering constraints."

While wholesome support for the Architect community is a novel addition, there are a number of features supporting configuration management and the build process. In addition, Microsoft has deeply focused on testing by providing a suite of facilities to bridge gaps between the developer and the tester. A bug "that manifests on the testers machine but is not reproducible on the developer's machine" is a common incident that repeats in projects across companies. Using VSTS 2010, a tester can now save the environment in which the bug had manifested as a virtual machine instance (using virtualization facilities provided on the OS platform) for the developer to reproduce and investigate better.

To a critic, the sheer number of features available might seem be overkill besides of course, the enormous demands on system RAM requirements when installing and using the complete suite. Microsoft has been making videos of various features available online, in addition to detailed documentation already being made available. It is necessary to install only those components of VSTS2010 that one would really be using to overcome system RAM demands.

VSTS 2010 is truly meant to be an "Integrated Development Environment”. So, go ahead – irrespective of what role you play in the project team - and get your hands dirty using VSTS 2010!

February 03, 2010

Globalization and the Japanese Software Industry

Japanese products in the manufacturing sector have most often than not withstood intense competition from competitors all around the world. Except for the recent glitch, Japanese cars have been the most sought after the world over for various engineering attributes like performance, reliability, design etc. But, unfortunately, the same cannot be said about the Japanese software industry – though there are efforts currently underway to change the structure of this industry.

Tatsuo Tanaka in his paper “The Competitiveness of Japan’s Software Industry” attempts to clearly bring out reasons why Japan has not been able to lead the pack in the manner it does in the manufacturing industry. Tanaka’s research indicates that Japan excels in producing custom and embedded software, but lags when dealing with packaged business and online software.
Japan’s area of strength has always been hardware and considering that embedded software is incorporated in hardware is an obvious reason for its quality to match the hardware. Japan’s focus on custom software can be attributed to the reason that most Japanese company’s handover software development to subsidiaries to develop software for in-house use, and that ends up being customized with specific extensions.  Besides, the tendency to form long term business partnerships with their customers result in software being developed customized to that particular customer. If there were indeed short term relationships, companies would try to generalize on the product that they developed so that the initial investment is not wasted and moulded for newer and newer customers, besides inculcating the use of standardized third-party software in the products that they develop. As the global market is more inclined towards business/general purpose software, companies in Japan which concentrate more on custom software are not in a position to compete in the software export market.

Software products offered by organizations in Japan are developed in bits and pieces (modules) by various subsidiaries who may in turn request the services of other first tier contractors who in turn may forward that to other contractors. Despite intense quality focus (as is the norm in Japan), the end product would contain software developed using varied technologies, processes and standards with pieces involving very less generalization.
The need is to develop a process model which is going to help make Japanese products viable globally – the technical aspect of which involves the strategies for internationalization and subsequent localization. To quote from a communication with an Infosys employee who has spent a major part of his career interfacing with Japanese customers – “The American and European markets have products which are widely used. The product companies in Japan too have their own products which are in the same space. However, they lack competiveness in terms of features. The problem is that most software products are mangled to meet Japan specific requirements like specific encoding types (SJIS, EUC etc), specific hardware platforms, specific cultural expectations etc. What is required is a methodology which can be used to guide these Japan specific products to compete globally with established products and at the same time maintain their very Japan characteristics- and this includes aspects like product positioning, differentiation etc in addition to internationalization and localization”

Considering the effort and investments that have already gone into making some of the products, and the fact that these products have done exceedingly well in the domestic market, Japanese customers typically would expect the effort to ‘globalize’ their software to be minute and there lies the challenge. Though such projects are often driven by a set of initial requirements, it is important to look beyond just what has been specified. The base requirement of "internationalization" would mean a lot of proactive contribution based on experience of how products work across continents, countries and cultures and there is a possibility that the current product would need a "re-architecting" to achieve this flexibility. With years of experience in developing customized software for the domestic market, it is important that a good case study is prepared in a way that could convince the customer of the need to adapt to the change. One related challenge is to get customers to adapt to new technology. In a product that we were expected to globalize a couple of years ago, it required a lot of effort to convince the customer of the need to use the latest technologies available with .NET. The customer insisted on using C++/MFC and Visual Basic simply because most of the company's resources worked on these technologies in supporting their other legacy customized products. Their C++ based products having been highly successful in the domestic market, it required a lot of convincing to explain the advantages of using .NET technologies in the context of this product and the global market.

There seems to be a wind of change blowing across the Japanese software industry and a realization that custom products for the domestic market will not provide a wide market share in the face of alternatives available with software from companies out of Japan, whose products have modern features. Such companies are able to access a wider market across geographies because I18N is an inherent characteristic of their software thus allowing them to build on their initial investment. In the face of the changing world it has become inevitable that the Japanese software industry is now retrospecting on how it has to position itself in the global market. We have often interacted with Japanese Fortune 500 companies who want us to contribute to help place their software in the global market and such requests are increasing ever year.  

Subscribe to this blog's feed

Infosys on Twitter