SOFWARE ENGINEERING: E-BUSINESS CHALLENGES

21 August 2001

by Paul Allen

In one sense, component-based development (CBD) is a continuation of the tradition of software engineering. There are some fundamental differences, however. When visiting firms that are trying to apply software engineering to the challenges of e-business, I find myself repeating some key messages:

• Decomposition of the problem -- OO, structured, or otherwise -- based upon internal production-line models of business, has severe limitations. Today's software projects are overwhelmingly about integration rather than development, and about collaboration between partners rather than production-line coding. We need to move away from thinking in terms of developing systems, and toward thinking in terms of consuming and providing services.
• Change is an ongoing fact of life -- it's not simply something to be reviewed at the end of a project. We must abandon the assumption that requirements gathering is ever complete and that systems are at some point complete; instead, concentrate on much better mechanisms for managing continuous change.
• Good specification of components and interfaces is vital. That's not a call for more documentation. We must drastically reduce the amount of documentation that typically accompanies software engineering projects, but be much more rigorous about the documentation that is produced.
• We must move toward service-based architectures linked with service-based processes that integrate with changing business needs. In particular, we need techniques that encourage identification and reuse of interfaces that offer business capability in the context of collaborative and changing business.
• Software is no longer restricted to performing a support function, as in the 1970s era of mainframe systems. Software is integral to business. We must move toward organizational models that encourage collaboration between business and IT based around e-business improvement. Your role set should not be restricted to traditional software engineering roles -- there are lots of business roles, too!
• Process must not be divorced from cultural issues. It is here that light methodologies again have much to offer in promoting the collaborative work styles that are necessary for successful e-business projects.

Software engineering approaches, especially those wedded to process improvement initiatives, are just one class of process pattern. Characteristics of the applicability of this pattern are traditional, formalized cultures; orderly software systems; and a previous track record of Capability Maturity Model process improvement. But what about organizations that collaborate in virtual value chains that have rapidly changing software systems and little time for classic process improvement? One size clearly doesn't fit all! This is because, while religions are absolute, patterns have their limits.

-- Paul Allen
Editor, Component Development Strategies

[For more information on light and heavy methodologies and component-based development, see the April and May 2001 issues of Component Development Strategies, available from Cutter Information Corp. at +1 800 492 1650 or +1 781 641 9876, fax +1 800 888 1816 or +1 781 648 1950, or e-mail service@cutter.com.]