Defining 'Software Architect'
Discover why this all-important role in the enterprise continues to evolve.
by Nick Fuentes

VSLive! San Francisco, February 9, 2005

Watch the video of the keynote! (Running time: 1 hour, 14 minutes)

Steven P. Davis Vice President of IT Walt Disney Studios

In a field such as technology that frequently reinvents itself, the meaning of "software architect" will continue to change, says Steven P. Davis, Vice President of IT for Walt Disney Studios, during his keynote Tuesday at the Software Architecture Summit at VSLive! San Francisco.

"'Software architect' is a great expression," Davis says. "It means so many things to so many different people. I want to talk about the organizational changes that may impact you in software development, how it affects the lifecycle, and the cultural issues that go along with it."

According to Davis, software architecture fits between enterprise architecture and application architecture. He compares an enterprise project to a city planning endeavor. It involves the city government, which provides the infrastructure for the project; the main contractor, which designs the project; and the building contractor, which exploits the infrastructure's resources and ensures the design will work within the boundaries of the infrastructure.

Similarly, in an enterprise project, the enterprise architect provides the infrastructure, the application architect designs the project, and the software architect leverages the available resources for the common good of the project within the confines of the infrastructure. In addition, the software architect works as a liaison between the application architect and the project's business unit to ensure the goals of both are met.

For the Good of the Project
Part of protecting the common good, Davis says, is to decide whether the software needed for the project should be built in-house or purchased. But he says deciding on an in-house application vs. a commercial one isn't easy, and the wealth of options in each category further complicates the decision. "The lines are blurring between in-house and commercial development," Davis says.

Devoting the necessary resources to build an application from scratch, as well as supporting it, should pay off by somehow differentiating the project; the software must offer something exclusive that can't be found elsewhere. "Differentiation is something that will give you an advantage in the marketplace," Davis says. "It's what makes you different from your competitor, and usually [these projects] are the ones with the biggest payback."

Another option for building an application in-house is to deliver an industry-model application, which can be built for and marketed to a specific industry. Again, Davis says, the question is whether building such an application will pay off in the long term by offering a product that others in the industry would be willing to purchase. "The question to ask is, can we do better than what someone else can do?" Davis says. With either in-house model, the software architect must weigh whether building an application will serve the common good of the project.

If the software needed does not add distinctive value, the software architect can opt instead for a commercial product. In this respect, the architect can choose either a maintenance-fee model or a shrinkwrapped product. Davis says both have the advantage of being widely available in the marketplace—and also widely supported—but they won't offer as much distinction within the project as a custom-built application would.

Trust is the Key
Davis says convincing architects to develop software in-house rather than buy a commercial application is sometimes difficult because of trust issues that center around who in the organization gets blamed when an application fails. "Developers trust vendors but are skeptical of the guy sitting at the desk next to them," Davis says. But he says the attitude toward in-house development is changing. "Many trust issues involved integration hubs," he says. "Every time something went wrong, they would get the fingers pointed at them." Because there is more communication and openness among team members, however, Davis says it is easier to trace more accurately where stopgaps in the process might exist.

Besides this shift in how developers trust one another, Davis says in-house development should also move toward a more commercial feel and start making custom applications more universal. "There's leverage in software reuse, not in standard tools," Davis says. He adds that with external adoption of services and market aggregation, software architects can support the common good not only within their particular projects, but within the industry as well.

Explaining the Value Proposition
One other challenge software architects face, Davis says, is the problem of explaining to a project's business unit the value of upgrading a system developed in an older technology, such as Visual Basic 6.0, when suddenly a new technology such as .NET appears. "Explaining technological obsolescence is one way" to convince naysayers to upgrade, Davis says. "You can cruise along in a car for nine years and nothing will go wrong. But at one point, the transmission is going to drop out. And it takes six months to replace that transmission.

"You also can leverage the differentiating capability [of the new technology]. You can argue that you can get more revenue and do something you couldn't do with the [previous] platform."

As the role of the software architect continues to expand, Davis adds that the result will be governance of supporting the common good, better branding and marketing of services, and more rigorous project management as various units start working together.

About the Author
Nick Fuentes is editorial project manager for FTPOnline. Reach him at .