Tags Change, Data management, Bottom Line

Help is at hand

When the time comes where you have to bring in a major tech change – and that time always comes – how do you keep your big projects up and running across the company in the meantime? As Intel's Robert Petrella explains to Paul Gander, the answers are there if you know where to look.

“Globalisation” conjures up images of an undifferentiated world where international companies move resources and products around in a virtually frictionless environment. The real world, of course, is very different. If a manager has responsibilities spanning two sites in the same country, let alone several around the world, he or she will know they will face considerable cultural differences. In a fast growing company, those differences can escalate quickly between employees and departments. Even if the company’s growth isn’t the result of mergers and acquisitions, local customs and processes will usually be the rule of the day.

In a perfect world, different locations and teams would work together as efficiently and harmoniously as possible. They would speak same language, both literally and technologically. They would understand where all of the pieces fit in the corporate puzzle and would work towards the big picture.

In this imperfect world, sorting out internal relationships when things don’t run smoothly is, to some extent, a question for human resources and internal marketing. But in a technology-based company like Intel, technology itself plays a key role in keeping everyone on the right track.

All the right moves

As software configuration management (SCM) administration manager for Intel’s Infrastructure Processor Division, Robert Petrella continues to be challenged by the potential headaches involved in a global, growing business. By using the technology that multi-site configuration management tools offer. He and his team work with eight different international sites, co-ordinating software development programmes across them all. The division creates new software for network processors and relies on creative input from its development team worldwide. That’s a lot of room for error.

“The front end requirements and planning, as well as back end design, test and packaging of new software must be co-ordinated and tracked when participants are in the same geo, across multiple locations,” he explains. “Making the same processes work across multiple geos is a complex and challenging task.”

And what do you do when the various “geos” use different tools to do the job? Imagine a car manufacturer where the parts are developed at various global sites, but each uses different tools and processes to get the job done. When it comes to starting the car, what guarantee is there that it will even hold together, much less run?

“Synchronising software development using tools from a variety of vendors is possible, but difficult,” Petrella says. Interfaces and processes can be inherently different, so while extensive scripting and process integration/standardisation was possible, it would be manpower intensive and a maintenance challenge.

“We decided to standardise source code, and defect and change management around a single system. In terms of efficiency and support, it makes sense.”

Over-arching change such as this is never easy. Getting past the legacy systems being used across a business can be a nightmare in itself. And no growing business wants to stop everything and replace an entire system when there’s existing – and paid for – materials to hand. Petrella was also faced with specific challenges, above and beyond legacy systems: the standardised process being introduced had to work on a global scale and data had to be shared effortlessly.

At the same time, there had to be minimal dependencies between locations. It was particularly important for the various sites to work independently, potentially on the same file. While no site will ever be completely autonomous, Petrella says, a lot of weight was attached to interdependence being reduced and kept under control: “The tool we were looking for had to be flexible and configurable enough to allow that to happen,” he says. IBM Rational ClearCase fit the bill, but the question was how to implement the change.

Know thyself

Just because a company specialises in technology with their own development capability, doesn’t mean that it can develop all the control and management systems it needs in-house. And even if it could, technically, take on the challenge, there may be good reasons to avoid doing so.

“We could have bought the tools from Rational and undertaken the migration of in-house data from existing systems to the Rational set of tools. This would have required in-house resources to quickly come up to speed. These same resources were targeted to support our existing tools and software deliverables. We needed an expert to come in and validate our SCM architecture based on their knowledge of the Rational tool set,” Petrella adds.

Working with IT specialists CM-Logic provided Intel with a link to improvements, new features in the Rational tool set and a path for future enhancements. Steve Toop, managing director of CM-Logic, agrees that having a technology consultant bringing in a training programme can make the difference between a tool being used effectively over time. Toop is clear: in a software development environment like this, customers should aim to use the tool properly from the first, and not relying on trial and error, speeding their return on investment. Petrella agrees: “This bridged a knowledge gap and saved us time.”

Software businesses large and small have tried to bring together their diverse teams under a single product development policy tool – and most failed because of internal issues, says Toop.

Uncertain backing from management, differences of opinion between departments, lack of experience with standardisation processes – they all influence a company’s inability to predict problems. Petrella and Toop agree that bringing in outside help with implementation, data migration and training seems to sidestep many of these potential hitches. Of course, this presupposes that all parties, staff as well as management, also agree on the need for a system at all, to determine policy in software development. There’s no such thing as “bullet-proof processing”, as Petrella calls it: “Software development is a daunting task if completed manually,” he says, “and because it’s become so complex, you need a tool that will automatically check that certain points in the process have been completed.”

Ultimately, this is all about quality control implemented on a global scale. As such, it’s an area where even the largest players may prefer to trust the objectivity of an external expert rather than their own internal resources, however extensive they might be.

Printer Friendly Email This Article