Advertisment

“We have people in different roles, working on different technology projects from different locations, with standardized processes and tools; people can do their work in a consistent fashion” Naresh Choudhary, Infosys

author-image
PCQ Bureau
New Update


Advertisment

Advertisment

Infosys is known for executing large scale projects to perfection. This has become possible because the organization is able to capture knowledge worth millions of person hours from its developers and enact them using the right tools and processes. We spoke to the head of their Tools Group, Naresh Choudhary, to find out how they do it, the tools they use, and the benefits they gain.



Q. What are some of the development challenges that organizations like yours are facing?





One of the challenges organizations like ours face is to deliver value to clients in a heterogeneous environment, with multiple technologies, different offerings, platforms, services, and so on. The other challenge we face operationally is from a tooling perspective because of this mix of things you end up taking. As a result, you're required to look at a variety of tools that need to be brought into the eco-system, use them effectively in a short period of time, get the learnability, and deliver the end product with the right quality. With all this, integration and collaboration become a challenge because you have teams working out of different continents. In some ways, these have also been a driver for us to really look at solutions differently in terms of bringing in the right sort of tools, integrating them, and creating platforms that will solve some of these challenges. The kind of “multi-world” that our organization lives in, it's very important for us to simplify things for the people, to give a seamless experience for the job role of every individual.

Advertisment



Q. What is your vision in terms of providing an application development platform for developers to manage their project lifecycle?



If I think about our overall platform, it could have multiple instances due to the different technology/service offerings involved. Our platform is able to integrate a variety of tools and automate the software delivery processes end-to-end. Not only that, but it's able to provide integration between the engineering life cycle (requirements, design, coding, testing, etc.) and the management activities (project management, configuration management etc.) thereby strengthening governance, traceability and our overall MIS while providing a quantum jump in Quality and Productivity.



Another is to improve collaboration due to standardization, resulting in de-skilling. This becomes an important sort of a benefit out of the platform. If it takes a person certain number of years to do the job, with some of these tools, we're seeing this experience could drop significantly, so that lesser experienced people can do the same job with the same level of quality and speed.

Advertisment



Q. What sort of a solution are you using to manage ALM? What sort of benefits does it bring to the table?



One of our objectives is to deal with heterogeneity, by leveraging a standardized way of looking at the delivery environment. The other is collaboration in terms of sharing best practices, thereby bringing in better visibility from a governance perspective. So the ALM solution we've looked at was something we architected with the help of an Integration bus. Tools like Microsoft's TFS, which allows integration between different software delivery teams, are part of the overall platform. The example I give people is that you have this huge pipe, and the moment you connect something from one team to the pipe, some other team also gains visibility into it. That's the integration and the first step we took.



We took a couple of years to deploy TFS in a more federalized manner, and soon realized that it wasn't a very effective model. So we setup a centralized infrastructure, and made it operational 7-8 months back. It has given us tremendous benefits. The administration overheads have gone away from hundreds of project teams that were using it in a localized manner. Basic things like backups are taken up centrally. In terms of back-up, DR, etc. things have been simplified and are straight forward. Because it's all centralized, we're able to enact certain policies that every team member on a project has to follow. These sorts of things are now possible without a lot of effort.

Advertisment



From a storage space perspective, we've seen savings as well, and from a green perspective, in terms of infrastructure cost, rack space, etc. we've seen definite savings there.



Our developers have seen a jump in their productivity. They're able to do their work more effectively and collaborate better. Earlier we had issues going back and forth between developers and testers. Now, we're able to solve some of those problems and seeing productivity improvements. Given our scale, even small inefficiencies lead to big costs, which have now been eliminated.

Advertisment



Q. Apparently, you have one of the largest TFS deployments in the world. Can you elaborate a little more about its scale?



In terms of the technical setup, we decided to setup something that can scale up to 20k people, but as of now, 10,500 people are supported on it. These are people who're seeing a fair amount of benefit of being able to do away with a lot of the individual level work as part of the local setup they were using.

Advertisment



Q. You mentioned that managing a heterogeneous set of projects was one of the challenges you faced. Can you tell us about the variety of projects supported by TFS?



In terms of service offerings, we have development projects, maintenance scenarios (fixes), support projects, re-engg projects, testing projects, etc. In terms of technologies, the tilt is more toward MS tech, like .NET, etc. We have certain number of projects that we're now beginning to take from other technologies into TFS, which is going to grow in the coming days.



Q. Building software is a team process where developers, testers and other roles need collaboration. How does your solution help you out on this aspect?



One of the big advantages we're seeing with something like TFS is essentially the ability to bring visibility into absolutely micro-level data, e.g. as a project manager, people are able to see the churn, the kind of test related info that has passed/failed, who has checked in/out the code. Otherwise, in the past, somebody would have to go around looking at a spreadsheet, asking people, calling them up to check for status. That's a very valuable thing, because all this info is available in real time. Other benefit is a whole lot of analysis is available. Some of it you can run when you want or have automated reports.



The other thing is typically what has happened in the development world is that requirements are done by a business analyst who sits with the customer, documents it, and sends it back to design team, who then passes it to developers, who then pass it to testers, etc. In all this, even though it's same organization, customer, and objectives, because of these roles, there are silos that get created. With tools like TFS, those silos don't exist in a hard manner, and where they begin to form, it nips them in the bud and prevents walls from getting built. As a project manager, developer, or tester, everyone is looking at the same info. Wherever there's a chance of interpretation going wrong, somebody else can pitch in to help.



Q What sort of change management challenges did you face while deploying such a large scale ALM solution?



It wasn't much of a challenge actually, because at Infosys, we had the building blocks for all of this. We have been having fairly successful project & program management systems in place, which is a part of our internal IS systems. The second advantage we had was that we're largely a process oriented setup, so people understand and appreciate the importance of processes, standards and tools. That way, it wasn't much of a challenge. The larger issues we had were to convince people that they would get far more power than they currently have. That was a bit of an awareness thing we had to do. Once we were able to show that, people were willing to move onto the new platform. As we speak, we're trying to work with MS to further strengthen this. Looking at this data, we could bring a lot more intelligence out of the system. There are things you could prevent up front, based on the intelligence that can be drawn in from the defect patterns, builds etc. for thousands of people.



Q. How important has been Agile development for you? What are you using for agile development? What sort of expectations do you have from the platform you're using for agile development?



We're definitely not behind on agile front. We've looked at agile in different ways, looked at traditional Scrum, XP etc. and created an Infosys point of view around these. We look at the traditional, conventional agile, and we said we could bring in some amount of predictability here and, some amount of risk reduction, and we've created some additional backbones to make it happen. The tooling that we have from an engineering perspective remains the largely similar.



From a TFS standpoint, the process templates help in general, Agile or CMMI, primarily in terms of process enactment. Infosys has experience that can translate into millions of person-hours. So our processes marry the best of models like CMMI or any other with our own best practices. These are being designed in our Project Management systems and in projects enacted through process templates like say in TFS.



So if you're a part of the project, you follow the templates in that, which are 'enacted' by the various tools that you end up using as part of the standard stack. We have people in different roles, working on different technology projects from different locations, with standardized process templates and tools; people can do their work in a consistent fashion. The templates are customized as per each project's characteristics.

Advertisment