So, what is “architecture for agility”?
A didactical way to define a concept is starting by what it is not. Therefore, in Section 1, the focus is on what is not an “architecture for agility”. In Section 2, a case, inspired by a true story, is discussed to clarify what we would call an “architecture for anti-agility”. Section 3 defines the concept hopefully.
- What is not “architecture for agility”?
As always in the technology information, there are too many buzzwords around a given abstract concept, so “architecture for agility” is another case. Recall the concept “architecture for agility ” is related to the ability of a given organization to move itself in the problem space in such a way that different feasible product architectures (perhaps changing of how components of a product are linked together — its architecture — while leaving the core design concepts — and thus the basic knowledge underlying the components — untouched[2]) are evaluated for a given set of functional requirements [1], in other words, it is related to the flexibility and leanness of the organization. For this reason, it is not defined by a specific practice or knowledge in a program or a project of the organization, which may include: (1) the usage of an agile practice, e.g., Scaled Agile Framework (SAFE) in which an architectural runway may be under constant development; (2) some interpretation and application of the concept microservice; (3) the evaluation and the usage of some broker technology, the most well-known being Kafka; and, (4) the understanding and the usage of the domain-driven design (DDD).
2. A case or an “architecture for anti-agility”
Consider a medium/large organization in which a Chief Data Officer (CDO) worked as a partner of the Chief Information Officer (CIO), in doing so CDO decided that master data - including a subset of the master data called reference data, e.g., genders - must be handled in a centralized way. Moreover, CDO allocated part of its budget to provide a set of microservices using REST to allow the retrieving of the centralized reference data by any organization’s system.
Meanwhile, CIO was working on the renew of a major organization’s system called ABC, which was the most profitable transaction channel of the organization. Furthermore, ABC needed the gender reference data.
At this moment, it must be clear that the organization constrained the product architecture since there was a sole option to retrieve the gender reference data. Moreover, the organization architecture was stamped out in the ABC architecture since there were REST calls between the ABC and the CDO’s systems mirroring the partnership between CDO and CIO [1].
Furthermore, there was a dependency between the two systems characterized by the request-response calls (based on REST) and their data structure. In terms of coupling (how modules are interdependent), this is categorized as a loosely-coupled dependency since it shares the same data-structure, see Fig. 1. Consequently, the CDO’s teams and CIO’s teams should communicate with each other focusing on the data structure as well as timelines for major milestones. Complementarily, as the REST calls to CDO’s system had no contingency in ABC (as prescribed by the partnership CDO/CIO) the CDO’s systems became the most important system of the organization so their availability should be as close as possible to 100% (what dramatically increases their cost).
In this scenario, inspired in a real case, as we saw, the architecture of the organization was stamped out in the architecture of the product ABC (mirroring evidence [1]) resulting in what we would call “architecture for anti-agility”. Although, from the computer science viewpoint, the two systems were loosely-coupled (based on microservices using request/response REST calls sharing the same data-structure across different bounded contexts), from the engineering viewpoint, roughly, the different teams were coupled (the progress should be agreed step-by-step) and the executable environment of ABC was coupled to CDO’s executable environment since ABC was highly sensitive to perturbations in the CDO’s systems. Indeed, CDO’s systems were not the business core of the organization, quite the contrary.
3. What is “architecture for agility”?
Elaborating on the previous case, from the program and project viewpoint, the dependency of the CIO team working on ABC from the CDO team may decrease its productivity regarding the necessity of a subset of the master data, i.e., genders in business transactions. Therefore, it is perfectly legitimate to apply a “dependency decision criteria”, in which such a subset of the master data is defined in ABC independently. In this case, the two systems are uncoupled regarding the genders in business transactions, see Fig. 2.
This is an illustrative scenario in which the organization may move itself in the problem space [1], in a striving to assess different architectures that may result in better products. In particular, such architecture would enable improved agility in the sense that the ABC system could have its evolution defined by its own pace. Furthermore, from the executable environment viewpoint, only the availability of ABC would be relevant. Eventually, integrations with other systems, that would exist in the organization, would be evaluated in the proper time, not ahead (delaying decisions that would not be mandatory).
So, one can roughly conclude that “architecture for agility” is to apply a set of proper “dependency decision criteria” in the assessment of possible architectures for a given set of functional requirements, perhaps resulting in the challenge of the organization architecture and, even, its policies.
Once the ABC is in production bringing value to the organization, the partnership CIO/CDO decided to apply a set of proper “dependency decision criteria” in order to guarantee that the gender domain is in accordance with the master data stored by CDO. Such a set of proper “dependency decision criteria” pointed out to one of the two hats of an “event”, namely, “replication”. Recall events wear two hats: (1) a notification hat that triggers services into action, and (2) a replication hat that copies data from one service to another. In this case, the two systems are decoupled (from the computer science viewpoint, a less stringent type of loosely-coupling) regarding the genders in business transactions, see Fig. 3, since the events of genders are exchanged via a “topic” without the systems knowing each other, they must know sole the data structure replicated.
There are claims that events and the related tools, e.g., a high-available broker, can handle all the needs for inter-service communications, here, we are less general arguing that the “replication” hat of events is a cornerstone enabler for the “architecture for agility”. In the same real case, an anti-pattern of the “replication” hat was observed: the usage of different “topics” to exchange the same “event”, e.g., the CDO defined different data structures and “topics” for genders targeting specific systems. We call this anti-pattern as “point-to-point topic” and, clearly, it should be avoided.
4. Summary
In summary, “architecture for agility” is to apply a set of proper “dependency decision criteria” in the assessment of possible architectures for a given set of functional requirements, perhaps resulting in the challenge of the organization architecture and, even, its policies. What turned out to be a crucial factor for architectural innovation, i.e, the changing of how components of a product are linked together — its architecture — while leaving the core design concepts — and thus the basic knowledge underlying the components — untouched [2]. From the engineering perspective, the “replication” hat of events and the related decoupling technique have been shown a cornerstone enabler for the “architecture for agility”.
References
[1] Architecture for Agility or “Magic mirror on the wall, who is the fairest one of all?” — Alessandro Gerlinger Romero — Published on Medium
[2] Henderson, R., and K.B. Clark (1990) “Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms,” Administrative Sciences Quarterly, 35(1): 9–30.
