Software Futures: Architecture

• By Stephen B. Morris
• Mar 25, 2005

From the author of
Network Management, MIBs and MPLS: Principles, Design and Implementation

The rapid adoption of service-driven computing is putting a strain on existing applications. Users want full integration of all services—Internet, office tools, entertainment, etc. Existing interfaces are insufficiently integrated, so one major driver for software will be the provision of increasingly smart features on a variety of what are becoming known as service delivery platforms (SDPs).

A decade ago, advances in GUI and network technology facilitated a boom in commercial software, and the same thing may be about to happen in integrated services. The key will be a combination of flexible architecture, clever integration, smart new features, and crystal-clear presentation technologies on a wide range of (often simple) access devices. The emerging service-delivery platforms will be delivered only if they're built on a solid foundation of architecture, integration, and coding expertise.

There's Something About Architecture

Back in the early 1990s, PC applications tended to be monolithic, with all code running on one machine. The advent of client/server and then multi-tier applications changed that situation, as we began to move into the multiplatform era. Interestingly, the monolithic days mandated what seems now to be called architecture-centric development. Back then, host resources were often so scarce that literally every byte of memory and disk counted. Technologies were employed for such arcane areas as disk-overlay management, expanded memory, terminate-and-stay-resident code, and so on. Programmers had an intimate relationship with the host platforms that executed their minutely handcrafted code. A change came with 32-bit PC operating systems such as Windows NT, which allowed programming models that obviated the need for a PhD in host system structure.

As machines became more powerful and the new languages of C++ and Java were created, to some extent the programming world turned its back on issues of architecture. In the salad days of the dot.com era, we could all look forward to a few years hence (such as 2005), when we would have infinite network bandwidth and infinitely sophisticated software running on infinitely powerful machines. It wasn't to be. Now everyone is talking about software architecture again and the merits of becoming architecture-centric. There are other reasons why architecture is so much on the radar; for example, web-based commerce, extended supply chains, and a slew of new technologies (application servers, grid computing, etc.) from the major vendors. It used to be that everyone wanted to be a consultant. Now it seems that the ultimate ambition is to become an architect! Let's take a look at this interesting trend.

A Simple Definition of Architecture

My favorite definition of architecture is this: all the code infrastructure and software products employed to create a generic execution environment for one or more applications.

This definition kind of harks back to the monolithic days, because it includes software for managing all the technologies required to produce a sound basis for applications. In addition to the basic definition, a good architecture should facilitate all the usual elements of software entities. It should be

• Manageable: easy to deploy, configure, use, and update
• Extensible: easy to modify and extend
• Usable: easy to operate
• Available: resistant to service-affecting problems such as disk/network failures
• Reliable: providing defined levels of safety
• Adequate in relation to performance

A good architecture should also allow for more than one application to be built on top of it. In effect, the architecture should be a separate and distinct entity from the applications built for it.

Many successful software vendors are aiming to define a single architecture for their applications. Ideally, the applications should consist of pure business logic that sits on top of the architecture.