Back to VSLive! San Francisco Show Daily Home

email article printer friendly

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

ADVERTISEMENT

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.