In-house application development is a dwindling phenomenon, thanks in part to the growing supply of packaged software. To survive, IT groups must undergo a transformation.
In this story, you'll learn
* How packaged software and tightening budgets are changing the face of application development * What innovative IT groups are doing to survive * Ways to reorganise for better productivity and efficiency * How to make packaged applications your IT group's friend If there were an application development lonely hearts club, Jeff Meyer would be a charter member. His last heartbreak was the worst. Called Group Paperless, it was an online application that would have allowed institutional customers of Meyer's company, Blue Cross and Blue Shield of Rhode Island (BCBS), to make changes to their employees' information (such as the number of dependants) via a Web browser. The company's systems department won the development project several years ago in open bidding against external software development contractors. But about six months into the effort, times got tough for BCBS and the project was scuttled. "That kind of thing happens all the time," laments Meyer, who is director of strategic development for the Providence-based insurance company. "Group Paperless was considered a strategic effort that didn't have a clear dollar payback. We had customers actively asking us for Internet access to their accounts, but we couldn't say it would save X amount on the bottom line, so the plug was pulled." Money isn't the only factor hindering corporate application development these days. Tom Beegle, assistant general manager for the MIS/Applications Systems Group at Matsushita Electric Corp. of America in Secaucus, N.J., finds himself competing for his company's development attention with a German stranger named SAP, a powerful enterprise application that automates business processes - long the exclusive job of in-house developers - and boasts the backing of hundreds of software developers who add new functions and capabilities to the program every few months. Matsushita is in the middle of installing SAP's R/3, an all-encompassing client/server enterprise application that automates a company's core business processes. When R/3's Financials module becomes fully operational at Matsushita's headquarters division later this year, and as the general rollout continues over the next several years, much of the application development work that Beegle and his group used to do will become unnecessary. He has to refocus his group's efforts from building standalone applications to doing other things, or his people will run out of work to do. Although he has a number of possibilities in mind, he candidly admits that he's not yet sure what those other things will be.
Many other in-house corporate application groups are wondering the same thing. Though reports announcing the death of in-house application development have been around for 40 years and have always been premature, there is clear evidence that the depth and breadth of options for in-house development groups are shrinking. For example, a 1998 survey found that spending on new application development as a percentage of the overall corporate IT budget had dropped by approximately 34 per cent from 1997, while spending on software package installation doubled, according to Cutter Information Corp., an IT research company based in Arlington, Mass. As software packages proliferate, in-house developers have lost the ability to keep on top of the latest technologies and programming languages. Vendors, outsourcers and consultants have stepped into the void with deep, specific technology expertise and have chipped away at in-house development groups' ability to act as application providers to their companies. Today in-house application development groups must know their strengths and weaknesses - and, most important, their ability to deliver what they promise - because the competition from outside forces is fierce and internal resources are stretched further than ever. Worse, in-house groups are at an inherent disadvantage. Software vendors and consulting firms live and die by the applications they build and install, and they'll always be faster and cheaper and have a larger group of customers to learn from and build for than the in-house groups do. In-house groups that attempt to compete with these outsiders head-on will be driven to extinction.
To survive, in-house application groups have to go where the others aren't.
In-house developers are shifting their emphasis toward project management, such as keeping an eye on the integrators and the software packages they install.
They are also becoming software fix-it shops that fill the gaps in packaged software applications and integrate different software packages to fit the specific needs of the company. "[Corporate] application developers will no longer be called upon to develop an application in a traditional monolithic sense. They will create systems of applications that work together," predicts Rob Veitch, director of business development, application servers and tools for the Internet applications division of Emeryville, Calif.-based Sybase Inc., owner of PowerBuilder, a popular application development tool.
As the need for application "glue" begins to outstrip the need for new applications, successful corporate application development groups are turning opportunism into an art. "You have to find the place where the business is broken and can't be fixed by a vendor or an integrator," says Mike Gurevich, chief technology officer and vice president of development for Concorde Solutions Inc. (CSI), a subsidiary of Bank of America, the bank created by the merger of BankAmerica Corp. (BA) and NationsBank Corp. last October. Spun off from BA's in-house application development group in 1995, CSI was created to solve one very large problem: linking new applications to old information. BA's IT department wasted countless hours building and maintaining individual links between new applications and old ones, new databases and old databases, new computer languages and old computer languages. There was neither time nor the requisite expertise to develop the complex technology that could make the integration process repeatable and fast. So BA decided to create its own version of a Silicon Valley start-up - a small group of smart people willing to work long hours in return for an ownership stake in the company and the product.
"CSI started for two reasons: to obtain and retain people," says Gurevich.
People who knew the latest, hottest technologies and would kill to be able to work with them, basically. That kind of knowledge and passion didn't exist within BA, and retraining company developers to work in the new technologies would not have cut it, he adds. "It is risky to believe that existing staff will be able to create a breakthrough that way. People who are comfortable and getting well paid - why would they work 16-hour days? Why kill themselves? There must be creative tension, a goal to strive for and a reward for reaching it." The start-up strategy seems to have paid off: Gurevich claims that in three years, CSI has not lost a single programmer to defection as the development staff has grown from 4 to 50.
The group has built a variety of object-oriented applications designed to hunt down data among the multitude of application systems in BA and deliver it to the desktops of bankers. Reducing application integration time and complexity offers a competitive advantage to BA developers: namely, speed and efficiency. "We are working on an application that we plan to connect to 14 different legacy systems," says Sukan Makmuri, vice president of Internet banking technology at Bank of America. "If I were doing this from scratch, I would have to dedicate 14 programmers to connect each of those systems together." Instead, Makmuri's programmers can use CSI's applications to get the data they need from those systems.
Creating a focused, passionate CSI-style group within the corporate IT department would have been very difficult, says Gurevich. "You have to create an environment where your developers are motivated all the time and they always have a technology challenge to work on," he says. "If there is a slow period where the company isn't working on new things, you could easily lose those people." And don't be surprised if relations become a little tense between the new group and the rest of the IT department. "There are IT departments working in the usual way and here is this very aggressive department that is always looking for the newest, most interesting work-it might be a dangerous proposition if not done right," warns Gurevich. "You can have creative tension between these groups or you can just have tension. The challenge is to create a good and friendly environment between the IT units in the organisation where the separate group is not viewed as elitist and internal people have a way to join the group if they have the required expertise." But the most dangerous aspect of a hard-core development group within a company is the tendency for the experimental, R&D focus to lapse into irrelevance. This constant stress between current needs and experimentation is what precipitates abrupt endings for applications like Group Paperless at BCBS.
"Technology has become a problem rather than an enabler for us," says Bill Boffi, the company's vice president of information technology and CIO. "In application development, the techniques and tools change so quickly that my organisation just can't keep up." Boffi and Meyer are trying to make strategic development less vulnerable by reducing expectations, both in terms of costs and application functionality. Under their new plan, strategic development efforts will be vetted through a grant process administered by the company's new Strategic Development Center (which right now is staffed solely by Meyer).
Each project will have a strict spending cap, a defined time frame and a list of basic functionality to be delivered. This should discourage overspending and a lack of focus when times are good and prevent abrupt endings when budgets tighten. Like the fixed-fee consulting contracts that are all the rage in systems integration projects these days, the grants will emphasise speed and delivery over fancy functionality.
By reducing expenditures and expectations for strategic development, Boffi believes he can finally crawl out of the "black hole of bureaucracy" that has plagued strategic development efforts at BCBS in the past. "We spent a lot of money doing the first iterations, and the applications were either successful by accident or failed miserably," says Boffi. The new grant process requires that development efforts focus on a particular business issue without trying to solve all the problems. "The good news is, I won't have to worry about whether the screen will be blue or red-I just have to get it working," says Meyer. If a group of business testers like what they see in a fully functional production prototype, Boffi and Meyer will turn the application over to BCBS's approximately 90-person systems group for full development. Now, the latest word is that Group Paperless will likely be retrieved, dusted off and put back on the schedule. Another effort that was cancelled for lack of clear focus and payback, a prototype Web-based provider directory, may also be revived.
BCBS's plan raises the flag that most in-house developers and the analyst community like to hold high these days: No outside consultant or vendor knows better than your IT staff the business processes that differentiate you from your competitors. Consultants and software vendors aren't around long enough to gain that knowledge, and they have to generalise their products for sale to a broad audience. "I would argue that those core functions should never be outsourced or purchased in a canned package," says Meyer. "As soon as you do that, you have lost your unique identity and what distinguishes you from your competitors." That's what manufacturers like Matsushita used to say about processes like inventory control, materials management and supply chain management - that is, until ambitious software vendors like SAP started to incorporate them into prefab software packages. It has forced Matsushita Vice President and General Manager of MIS Bob Schwartz to re-evaluate the role of in-house application developers. "The need for speed has been pushing our company," he says. Top management at Matsushita want information about all the different facets of the business to be integrated and delivered in near real-time. That pretty much spelled doom for most of the company's old mainframe systems that communicated with each other (and with the business) in overnight batch deliveries of information. Schwartz wasn't about to try to solve that problem with his in-house developers because the vendors already had done it. But even as SAP is being installed at Matsushita America's headquarters, the next generation of differentiating processes - communicating with outside customers and suppliers, controlling the flow of materials in the manufacturing process - are being tied up with nice, neat bows by a host of smaller software vendors, all of which are making their packages compatible with the large ERP software packages like SAP.
"Over the next few years, we are going to become almost a 100-per cent package shop," says Beegle. "Even our logistics will be run by a package. We are going to be faced with the question, What do we become?" So far, it's only clear what they won't become. "The traditional role of the programmer goes by the wayside when you look at any packaged application, particularly from the integration standpoint," says Schwartz. You don't build the application anymore - you tune it, he says. "The way you configure the package determines how a particular function, like finance, will be performed.
So the IT person needs to understand the business function or flow that's being automated to get the desired result." The business flows smoothest if the different software packages supporting it are tuned to run well together.
"Their skill won't just be to understand a particular package," he says, "it will be how to implement packaged solutions in the future." Some of Matsushita's programmers will support the mainframe systems that remain or take courses to learn how to service the new packages. Others will be retrained to help with the company's burgeoning Web development efforts. Still others will make a much more dramatic shift, from programming to project management. This will be the hardest transition for IT people and may not be open to those who have not had prior experience or who demonstrate less than a strong interest. "That's not something you can just learn from a course," Schwartz says. "Strong project managers have gone through the effort and cut their teeth on learning the steps - both positive and negative - of the project management process." These new project managers will be more dependent on outsiders for help, adds Beegle. "We need to go from managing software development and technology people to managing business people and outside vendors and consultants," he says. "Contractual issues will become much more important in project management because we will be dealing with more outsiders." Project managers will need to become skilled negotiators and cajolers of the big software and hardware producers.
They'll also need to suck information and expertise out of those outsiders for use in their own groups. The half-life of advice and education remaining in a company after a project ends and the vendors and consultants leave is not long-like steam on a sunny day in most companies. Myles Trachtenberg, vice president and CIO at the Prudential HealthCare division of The Prudential Insurance Co. of America in Newark, N.J., is trying to extend that half-life while also getting the particular software expertise that he can't afford to build within the ranks of his staff. Consultants are a part of his operation, full-time. They mix with his staff every day, on every project team - not just on particular application development projects. The goal is to improve the process of software development at Prudential, from initial concept to final installation, and build those improvements into the permanent ways of doing things. "You can build and train your organisation by working with another one," he says. "It's knowledge through assimilation." External pressures from all sides-from vendors, consultants, customers and, oh yes, the business - will not make things any easier for in-house application development departments that want to make a go of it alone. Especially if we're talking a department of one, as is the case at BCBS. But Meyer thinks his grant plan will make him lonely no longer. "By making a clear dollar commitment upfront based on certain defined deliverables, it's less likely that the customer will can the project halfway through," he says. But he is aware that fancy uses of technology won't be enough to keep his projects out of the proverbial can. "The value of my strategy effort is going to hinge on how much these applications will be used," he says. By sticking to a bare-bones prototype, Meyer believes a new version of Group Paperless would be less likely to disappear than the first version. "I'd like to think so, anyway," he says.
"In part I'm gambling my career on it."
The Standish Group International Inc., a research consultancy based in Dennis, Mass., studied 23,000 application projects at companies of all sizes between 1994 and 1998 to assess their rates of success. According to its data, the news is good: Success rates have increased. The company defined success as completed on time, on budget and with all features and functions originally specified; challenged means the project was operational but over budget and time estimates, with fewer features and functions than originally planned, and failure means it was cancelled before completion.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.