Designing Applications For Constant Change

Here’s a radical thought: Enterprise software applications in the 21st century are headed for the same kind of upheaval that affected enterprise hardware in the 20th century. Think about it: in the glass house, there was a neat boundary around the mainframe, and the MIS department guarded the border carefully. Then, with the advent of minicomputers and networked PCs, the boundaries of the enterprise began to expand just a little bit. Today, with Blackberries, laptops, and PDAs, the boundaries around hardware are almost completely amorphous.

The same thing is happening to enterprise applications. Instead of existing as completely discrete entities, those on the cutting edge draw information from any number of databases and systems, whether within your organization or in those of your partners, outsourcing firms, or suppliers. So where are the boundaries? Shouldn’t they be designed to accommodate changing business processes, so that they can be updated quickly and easily, as competitive and regulatory demands dictate?

Experts have dubbed this new breed “composite applications,” incorporating everything from Web services to middleware to APIs. In this Q&A, Forrester Research analyst John Rymer talks about how IT departments can focus on creating these highly flexible applications.

Q: How are you defining composite applications, and what would you use to build them?

A: Composite applications focus on process, rather than automation. They encompass multiple functions—sometimes mediated by humans—and systems. They span multiple business areas, pulling data from multiple systems, and they tend to be owned by different groups.
You could use Web services to create composite applications. If you’re going to build composite applications that incorporate existing applications, you need to have some interfaces to those applications, and Web services can provide the technology to do that. It actually has some very attractive characteristics compared to some of the other techniques because with Web services, you’re encouraged to describe interfaces in business terms. But there are lots of other options: EAI tools, Corba, APIs, and other middleware.

Q: You can mix and match?

A: You can. In fact, we encourage people not to think of a service-oriented architecture (SOA) as incorporating only Web services, because we’ve seen people using more than Web services.

Q: How is the application-development process different for a composite application than for a traditional application?

A: The traditional approach to application development gives the developer total control. The development team has a budget and an objective, and they design the application as a monolithic whole. They control the data definitions, the data sources, the business rules, the information flows, and the user interface. All those elements are part of their world.
With composite applications, you don’t have control over all those elements. If your data will be drawing from existing systems, you may not control those systems, so you have to abide by the rules of the owner, understand the constraints of that system, and know your ability to interact with that system. If you’re handing off a transaction in the middle of a process flow to another system, then you have to deal with the parameters of that system. It is what it is; you can’t change it. People have found this out with salesforce.com’s Web services. Salesforce.com requires a certain model for interaction, very much like Corba, and anyone who wants to incorporate Salesforce.com into their application has to understand its interaction model. That’s a constraint on your development process, because the model has already been built a certain way.

The same is true for user interfaces. You may build a user interface (UI) for your application and then find that you need to provide a second or third alternative—perhaps a UI for a mobile device, or even a non-visual interface. There’s a need for a lot of more diversity, shared control, and collaboration than in a traditional development project.

Q: Is this a good thing or a bad thing?

A: We’re trading off control for the economics of reuse. If a developer says, “I can build that functionality better myself,” it’s probably true, but at what cost? If the code already exists, it’s cheaper to use it than to build it or maintain it. You’re making a tradeoff. These days, when projects have to be so responsive, when you have to deliver functions quickly and be able to change them just as quickly, building everything from scratch is just not tenable. You have to reuse and share.

Q: It’s like, I could bake my own bread if I wanted to, but it’s not a good use of my time when I can get it at the store.
A: Right. Just observe the character of the business environment—speed and adaptability are at a premium. If the old practices don’t work—and they don’t—you have to change. There are some cases where a team will make a legitimate judgment [in favor of writing it themselves], but that has to work economically. I can understand both sides of the argument, but I see the requirements they’re up against.

Q: What are the “gotchas” of developing composite applications?

A: Governance is a big one. There are companies where the development organizations are broken into functional areas. That’s a good sign, because those people are responsible for the transaction back-end, for their part of the process. When you have specialists working together, then you’ve got a fighting chance of making the collaboration work. The big issue is the tension in the way we govern custom application development. With composite applications, you have to share and reuse code. But the level of shared resources is going to be quite low. There’s some guy who’s an architect and he’s responsible for the SOA initiative, and he has a big enough budget for his own salary. When he talks to project teams about shared resources, they say, why should I do that? If I share resources, it will take resources away from my own project. That’s a conflict that has to be resolved.

I spoke to a guy at Sony Pictures Entertainment about this tension. Everyone has more projects than they can build. If you want to take funding away from specific projects and put it to shared resources, something has to give. Sony is working on it by making a commitment to reduce applications-maintenance costs. They’re taking funding from the maintenance budget and redirecting it to the creation of shared services. If they’re wrong, they’ve got a problem. But he’s confident he’ll be able to do it. They didn’t raise new funding; they just shifted it. That’s probably a good model.

Q: How do you measure whether you’re doing it well?
A: You measure success based on the number of shared resources going into applications. You look at time to delivery, which hopefully would go down, and look at quality. If you’re reusing code rather than rebuilding, your quality should go up. You’d measure on your ability to accommodate change, to roll out the release with a diminishing turnaround time.

Q: Do people really think this way?

A: They don’t. We did a small survey to get a sense of whether people thought composite applications were real, using a generic description, and 53% said no. We asked them what they’re called, and only one person called them composite applications.

We’re in a period of transition. The number of applications that use integration is going up. But people haven’t yet recognized that this is a new model. And until we do, we can’t agree on the name, the best architecture, or skills and practices. This is like the learning process we went through in 1993 when the Web was emerging. That’s where we are now—we just need to take the leap into the mainstream.

Companies really don’t have a choice about this. Business requirements are evolving, but the payoff for this pain is a very strong alignment between IT and business. When you get to composite applications, the alignment is very close, because you’re working with business processes, and reusing code that corresponds to business entities. The payoff is a dramatic forward leap in alignment, and that’s a very good state of affairs.
Feedback question: Tell us your thoughts on whether you would tackle composite applications differently from the way you would tackle other applications-development projects.