4.2 Doing Software Incorrectly

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

This chapter explains the architecture-centered development process in some detail, but first it examines 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 architect's ability to accommodate change will determine whether the software 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 changes. In effect, the world is complex and 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.

The changes in technology 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 make their own products obsolete 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 are ongoing problems that every enterprise software organization must resolve for itself.

An Example: Doing Software Incorrectly

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

The enterprise needs a new software system. The target system is a replacement or consolidation of existing systems that do not support necessary changes to business processes. To correct this problem, a project manager is appointed, and a development team is 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 another 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 canceled. Five out of six projects are considered unsuccessful and unable to deliver the desired features. Even average projects have schedule and budget overruns nearly double that of 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 4.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. In an industry known for its dissatisfied and burned-out employees, developer turnover can quickly make an undocumented, heroically programmed system obsolete, turning it into an unmanageable stovepipe system.

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, by working smarter, not harder, to do software right.