3.2. Doing Software Wrong

After many years of brutal lessons learned, enterprise software development is moving out of the heroic programming dark ages and into an industrial-strength architecture revolution. The key is architecture-centered development, and most software experts agree that for complex systems nothing else works.

In this chapter we will explain the architecture-centered development process in some detail. But first, let's see why this software revolution is an inevitable necessity in enterprise development organizations.

This Old Software

To be successful, software must create an on-screen illusion that appears to meet end-user needs. But this illusion is temporary. In enterprise development, the internal structure of the software is also of great importance. In particular, the software architecture's ability to accommodate change will determine whether it provides ongoing value to the enterprise.

There are at least two unstoppable forces of change in enterprise software development: (1) requirements change and (2) technology change. In effect, our complex world is changing during system development and operational deployment.

Requirements change because the business environment changes, and because the end users' understanding of the requirements changes upon encountering realized system elements.

Technology changes are driven by relentless competition under the guise of innovation in the commercial software market. Vendor strategies are accelerating and enforcing change for software consumers. Currently, major vendors obsolete their own products every 6 to 18 months.

Because virtually every enterprise system relies on multiple commercial software suppliers, managing technology change is complex. Identifying, developing, and maintaining suites of integrated commercial products is an ongoing problem that every enterprise software organization must resolve for itself.

An Example: Doing Software Wrong

Here is a typical development scenario that is occurring in many enterprise software organizations today.

The enterprise needs a new software system. The target system is a replacement or consolidation of existing systems which do not support necessary changes to business processes. A project manager is appointed and a development team formed. The development team is a mixed group with some current and legacy skills (often with the balance toward legacy).

The project manager studies potential approaches and concludes that "object-oriented" (or other current buzzword) is the only paradigm that makes sense, given readily available, commercial technologies. In other words, the manager is led to believe that buzzword technology will make system success easy. Vendors encourage this illusion by claiming that their products can remake ordinary developers into programming stars. So the manager makes technology commitments and puts the development team through a product-specific programming course.

After that, nothing seems to happen. The team struggles to analyze, design, and program the system, without much measurable progress. The manager grows increasingly frustrated and worried, as the project schedule slips into political trouble with upper management and end users.

Statistically, the manager was doomed, almost from the start. According to reliable surveys, the brutal reality is that one-third of all corporate development projects are cancelled. Five out of six projects are considered unsuccessful and unable to deliver desired features. Even average projects have schedule and budget overruns nearly double the original project estimates.

Enter the Knight: Heroic Programmers

Heroic programmers can help a project to avoid short-term consequences, by delivering software that appears to meet end-user needs. Now that user interfaces are relatively easy to implement, the illusion of working software is increasingly easy to demonstrate. However, the complexities of developing a system that accommodates change is another matter. Heroic programmers are usually too close to the software problem to consider these longer-term consequences (Figure 3.1).

With today's complex programming notations (e.g., C++) and distributed system capabilities (e.g., intranet, N-tier), it is widely understood that software modules are unmaintainable, except by the original programmer. Averaging at 30% annually in the United States, developer turnover can quickly obsolesce an undocumented, heroically programmed system into an unmanageable stovepipe system.

We believe that good programmers are absolutely necessary, but not sufficient, to ensure system success. Even in the most qualified of hands, the available program design methods, software tools, and computing technologies are surprisingly inadequate, compared to today's enterprise system challenges. Managing change and complexity requires much more than raw programming talent in order to realize a successful and maintainable system. Solutions to today's enterprise development challenges are possible through architecture-centered development—in other words, through working smarter, not harder, by doing software right.