The team was given some quick training in automation and given three tasks: develop the application quickly, figure out how to automate the infrastructure, and figure out how to automate more of the application deployment and testing in order to marry DevOps with continuous application delivery.
There were no rules — or roles. "We threw them together and said, 'You figure it out,'" Reed recalls. "We found some people knew a lot more than their roles indicated, and the lines began blurring between responsibilities." Some folks were strong in certain areas and shared their expertise with others. Traditional infrastructure professionals had some middleware and coding understanding. "They didn't have to be experts in everything, but they had a working knowledge," Reed says.
The biggest challenge was learning to be comfortable with making mistakes. "GE has built a reputation around execution," says Reed. "My boss [global CIO of GE Capital] and I had to figure out how to foster an environment were people take risks even though it might not work out."
The project not only proceeded quickly — the application was delivered within several months — it established some new IT processes. They increased the amount of automation possible not only at the infrastructure level, but within the application layer at well. They also aimed for 60 to 70 percent reusability in developing the application, creating "lego-like" building blocks that can be recycled for future projects.
Business customers welcomed the new approach. In the past, "they would shoehorn as many requirements into the initial spec as possible because they didn't know when they'd ever have the chance again," says Reed. "Now it's a more agile process." The team launches a minimum viable solution and delivers new features over time.
For IT, "it was a radical change in thinking," says Reed. "We've operated the same way literally for decades. There were moments of sheer terror." And it wasn't for everyone. Some opted out of the project and went back to their day jobs.
But Reed is eager to apply the process to future projects and rethink the way some legacy systems are built and managed. "We had talked about services-oriented architecture, and now we have something tangible that shows it can be done," Reed says. "On the legacy side, we have to decide if we want to automate more of that infrastructure and keep application development the old way or invest in this."
Some employees remained with the fleet management app team. Others started a new project. And a few went back to their original roles. "We're trying to make disciples so more people can learn about this process," Reed says.
Sign up for Computerworld eNewsletters.