Agile and Structural modularity (i) exploring the relationship between structural modularity and agility

1 Introduction

Agile development methodologies are becoming increasingly popular, while most "agile" experts and analysts are discussing agile in isolation, which means ignoring the system "architecture" (Kirk Knoernschild is an exception, he wrote a book called "Java Application Architecture" Books to illustrate this idea). This omission is surprising considering that "agile" is an important attribute or attribute of the underlying entity. An entity has an "agile" feature that must have a highly structured modular (structural modularity) feature (see Diversity & Complexity of Scott Page).

Perhaps because of this negligence, many organizations are investing in the agile development process but ignoring the structure of the application. In addition to "how to implement an agile system?" "Beyond this question, one would surely ask," How do you build a system that is highly modular in structure? ”

This series of articles will begin by exploring the relationship between structural modularity and agility.

2 structure, modularity and agility

Business executives and application developers often face the same challenges. It must be built and maintained within cost range, whether it is a business or a business-service software. If you want to keep the entity running, you must be able to respond quickly to unpredictable changes in a low-cost way.

If we want to manage a system efficiently, we must first understand the system. Only by understanding the system can controllable changes and directed upgrades become possible.

Of course, we do not need to understand the details and characteristics of each component of the system, only to understand the relevant parameters of the system in charge and the corresponding hierarchy of behavior.

Hide Service Implementation

From an external standpoint, we only care about the behavior of the system, the types of services provided, and the properties of the service. For example, is the service reliable? Are they competitive compared to alternative solutions?

Figure 1: Consumer of the service

As a consumer of the service, we do not care how the features of the service are implemented, and we only care about whether the functionality provided (Capability) meets our needs (requirement).

Understand the structure to manage

Unlike the user, the way in which the service is implemented is extremely important to the service provider. To better understand, we set up a conceptual model for the system responsible for providing services by decomposing the system into a smaller set of interconnected units. If the entity is a company, this component diagram represents the organization chart (organization Chart '); If the entity is a software application, then this diagram is a map of dependencies between modules.

The first step in trying to understand an abstract system is shown in the following illustration.

Figure 2: Service Providers and System maintainers