What is Component-Based Architecture?

Components as building blocks

What is component-based architecture? Think of a component as a Lego block. When building a structure out of Lego blocks, you can choose from a variety of shapes, sizes, and colors. There are also blocks that are purpose-built to be doors, windows, and other structural elements. Each block has all the features it needs to connect to others, and adding or subtracting blocks generally has minimal impact on the structure.

Software is much more complex than little pieces of plastic, of course, but the concept is similar. Each component is built to perform a task in a way that’s defined by the architecture. Components are stored in a library and assembled by developers. Components talk to each other through application program interfaces for simplicity.

Communication is facilitated by an object request broker, which is sometimes called a “software bus” because it provides a single communications plane that all components use. Communication can occur in a number of ways, such as asynchronously, through broadcast, through a message-driven system, or as part of an ongoing data stream.

The concept isn’t new, having been discussed in academic papers as early as the late 1960s. IBM’s System Object Model, which was introduced in the early 1990s, was the first commercial effort to define a way to build software from components. Microsoft’s Component Object Model and Object Linking & Embedding, which were introduced around the same time, provided the first frameworks for use in commercial deployment.

5 features of components

Software components have a number of common characteristics:

1. Reusability. They are designed to plug into a variety of applications without the need for modification or special accommodations.
2. Extensibility. A component can be combined with others to create new behaviors.
3. Replaceability. Components with similar functionality can be swapped.
4. Encapsulation. Components are self-contained and expose functionality through interfaces while hiding the details of internal processes.
5. Independence. Components have minimal dependencies on other components and can operate in different environments and contexts.

Examples of components

Components are the building blocks of service-oriented and microservices architectures, in which applications are assembled from loosely coupled and discrete services. Microservices is the dominant architecture used in DevOps and cloud-native development. It’s valued for its productivity benefits, since developers assemble most of the application rather than building it from scratch.

One example of a component is the spreadsheet functionality in Microsoft PowerPoint. When editing the data underlying a chart or graph, users are presented with a spreadsheet that looks and acts like Microsoft Excel. While it’s not a full version of Excel, the spreadsheet widget has enough functionality to support basic spreadsheet functions.

Other examples of components include a function that calculates tax in an eCommerce transaction, or one that challenges the user to answer questions upon login.

Tradeoffs with components

A component architecture can have some drawbacks, which means it isn’t appropriate for every scenario. For one thing, it requires the application to be broken down into modular and functionally separate pieces, which can be a challenge when applications are quite large. Also, the need for reusability of a component can limit its customization options.

Finding a component that exactly matches the requirements of an application can be difficult too, and because a great many components may need to be monitored in a given application, updates and maintenance of component libraries can be complex.

Alternatives to components

There are numerous alternatives to component-based architecture. These include:

• Microkernel architecture comprises a core processing component and independent plug-in modules with specific functions. Components don’t communicate with each other—only with the microkernel.
• Client-server architecture has just two components that exchange requests for data, services, and content: client and server. Otherwise, they operate mostly independently.
• Event-driven architecture consists of decoupled, purpose-built software modules that go into action in response to an event, such as a credit card being swiped or an alert being generated by a sensor.

Components have become a fundamental building block of modern software. While the term is less used today than it was 20 years ago, the concept is sound and has proved adaptable to a constantly changing technology landscape.