SAFe “Agile Architecture”: Agile Developer’s Hallucination

I do like the development approach taken by SAFe (Scaled Agile Framework) that combines an agile development and architectural practice. This is why I usually recommend SAFe as the right method for development. However, decades of IT practice have established a cornerstone principle of separation of concerns. The people wisdom also says – everyone has to do what s/he does the best. Unfortunately, the authors of SAFe have made the common mistake and tried to re-define an architectural practice in the development terms. The result is already known… Let me elaborate on it for those who never looked outside of coding or coding management (BTW, there is a whole world out there).

To make it clear from the beginning, an Architecture is a conceptual model embodied simultaneously in the fundamental self-sufficient and cohesive elements; their relationships to each other, and to the environment, and the principles guiding its design and evolution. Architectural practice is the first step of Architecture realisation; it deals with capabilities, which are still somehow abstract. Please, note, capabilities are not what we do, but an ability to deliver concrete outcomes at a certain time within a particular execution context. In essence, both business and technology deals with the results of Architectural Practice – the Architectural Solutions – based on the architectural elements, which are expressed via capabilities. A Corporate Strategy may require changing the Architecture, i.e. architectural elements, or not, and this is reflected in the capabilities. The Architectural Practice/Solutions generate requirements to the Architectural Solution Implementation in business and technology. This leads to clear segregation of Architecture and Architectural Solutions form their implementation in Development.

Development realises the requirements and design represented in the corporate Target Operating Model (TOM). This model includes both enhancing of BAU including related technology systems and new development. If any demand for development does not fit with TOM, it should not be accepted as a requirement. Thus, agile development is am advances method for implementation of TOM and its operational design. Development deals with the most detailed level of design and has to have continuous feedback and interactions with Architectural Solutions. This is why it is very important to consider them together while each “activity” should mind its business.

Even such short observation (much more information on the topics of architecture, capabilities and TOM is available atorganicbusinessdesign.com) shows there are no needs to re-define Architecture. One Architecture can differ from others by either architectural elements or principles, but not how it is used. If one uses a keyboard to type while another use it to crack nuts, it is still the keyboard; otherwise, it would be an absurdist taxonomy. Seemingly, such thing as “Agile Architecture” either does not exist or it is not about Architecture. Indeed, to be an Architecture, we should be able to identify architectural elements – can SAFe tell us what are they? Or, what are the architectural principles that unknown elements share?

For the last 20 years, IT has created a habit of using marketing inaccurate terms to name its methods and technologies just to catch people’s attention. It is a matter of fact that Developers do not possess a skill of ambiguity typical to marketing and frequently follow the inadequate names literally. I guess some people confuse others deliberately just to please their own ego regardless if others get a misleading message and start to generate mistakes. This happened before when Developers understood a Principle of Statelessness as a model that does not have a state while the text of this Principle never required eliminating the state. It happens now when architectural (arbitrary) practice is called “Architecture”. The most outstanding example of this that I know was a technology named Web Services, which was not about services and not necessarily about the Web.

I ‘ve decided to review principles of “Agile Architecture” provided by SAFe[1] and tried to understand what architectural elements could follow them. So, the table below sums my discovery.

? SAFe: “Agile Architecture is a set of values and practices that support the active evolution of the design and architecture of a system while implementing new system capabilities.” [provided definition of Agile Architecture]

o M. Poulin: This is a misinterpretation of the term “Architecture”. Any architecture must have elements rather than values. An evolution of the system depends on the evolution of its architectural elements. Neither a system nor its Architecture evolves by itself. New capabilities are the reaction to the demand/tasks/motivations applied to the system. A change in them results in different evolution and different capabilities. The latter are “bricks” of Architecture implementation, not elements of Architecture. Provided statement points on that SAFe actually talks about an Implementation, not bout Architecture, repeating the common mistake.

? SAFe: “With Agile architecture, the system always runs, supporting a more continuous flow of value” [provided statement].

o  M. Poulin: Any existing system when operates runs continuous flow of values regardless of “Agile architecture” or any other Architecture. It is unclear what might mean “a more continuous flow” (this may be a bad English) as well as what are the architectural elements of “Agile architecture”. Particularly, which values and practices are fundamental to the system (i.e. cannot be removed without the system ruined), self-sufficient (i.e. independent from external and other architectural and non-architectural elements) and cohesive (i.e. oriented toward the same goal). I believe that no one practice of development and provided values match described criteria. But this means that "Agile Architecture" is not an architecture at all. 

? SAFe: “The Agile architecture principles support Lean-Agile development through collaboration, emergent design, intentional architecture, design simplicity, as well as designing for testability, deployability and releasability. It is further supported by rapid prototyping, domain modeling, and decentralized innovation” [provided statement].

o  M. Poulin: As any Architecture Principles of a system must relate to the architectural elements and be independent of any form of their implementation including "Lean-Agile development”; saying otherwise is illiterate.

o  M. Poulin: Architecture implementation is arbitrary and depends on those who and how to perform this implementation. An Architecture itself does not care if Developers collaborate or cooperate and if the design is emergent or not. An intentional architecture depends on the desires of people and, therefore, can get in the conflict with the intrinsic architecture of the system. Ignorance of the interdependencies of intrinsic architectural elements drives the system to the destruction. The implementation design may be simple or not – this does not impact the system’s architecture. Rapid or not prototyping, domain modelling, centralised or decentralised innovation are all implementation means and immaterial for the system’s architecture.

o  M. Poulin: Does SAFe try to say that ‘architecture’ is a development instrument? If so, they are simply do not understand the first thing about architecture (abstraction), its role and purpose.

? SAFe:“#1 – Design Emerges. Architecture is a Collaboration” [architecture principle]. “… some intentional architecture is needed to enhance solution design, performance, and usability and to provide guidance for cross-team design and implementation synchronization.“

o  M. Poulin: First of all, architecture is a static model of a system. The system can change with or with no architecture changes; the latter takes place if only the non-architectural system's elements change.

o  M. Poulin: An intentional architecture, known as Target Architecture in the industry for many years, may have may include enhancement, change in performance and definitely cross all related implementation teams. However, it is not a feature of the Architecture, but a feature of capability-based Architectural Solutions that depend on motivations.

o  M. Poulin: It is a seldom situation when a part of a system has its own architecture. In such cases, people usually create sub-systems. Thus, the requirements for implementation (Step 2) of architectural capabilities (Step 1) are usually wider and deeper than a solution for individual project design. These capabilities may require phased enhancement, performance tuning and usability adjustments, which are not apparent at the project level. But aimed at making the overall solution integral.

o  M. Poulin: Collaboration is a special form of activities applied to the system. No architectural changes depend on whether they are made in a collaborative or cooperative manner. Applied activities are outside of architecture, but they are very much inside the implementation of the architecture. Developers who implement architecture do not "do" architecture; they just deliver the architected values.

o  M. Poulin: An Architecture cannot have a principle that may or may not be used in its implementation. Such a case indicates that there are two Architectures that can be distinguished by their architectural principles.

? SAFe: “#2 – The Bigger the System, the Longer the Runway” [architecture principle]. “In the Lean enterprise, architectural initiatives are incrementally developed and committed to the main code base. Doing so means that architectural initiatives must be split into Enabler Features, which build the runway needed to host the new business features”

o  M. Poulin: This is true, but it seems that SAFe has somehow extended incremental development and system runway on the architectural initiative, which is not necessarily true. One of the major benefits of the right architectural designs (capability compositions) is that a large architectural solution can be split into the smaller segments, which can be implemented in parallel against pre-defined interfaces and information transformations. As a result, an increase of the architectural solution in size does not necessarily mean the longer runway of the architecture practice. Moreover, the SAFe statement cannot be an architectural principle because it is about an architecture implementation.

? SAFe: “#3 – Build the Simplest Architecture That Can Possibly Work” [architecture principle]

o  M. Poulin: Architects, especially in IT, are not free in their choices. They are under constraints of business architectural solutions expressed via compositions of business capabilities. If such composition requires, e.g., 20 functions/features to be built, the technology must build or buy these 20 functions/features, not 19 or 12 ones. It is the implementation of functions/features may be more or less complex. However, if you want the business/technical solution to be flexible[2] (considering the demand of the modern dynamic market), it will be always more complex than the “Can Possibly Work”. In any case, the Architecture does not follow this principle because it is, again, about implementation.

o  M. Poulin: It is a fundamental requirement for Architects to design flexible solutions. The flexibility requirement dictates implementation to be as such that the change of implemented things would be as quick, cheap and simple as possible. If development oversimplifies implementation making it almost immutable, this is a bad development in our days.

o  M. Poulin: It is a fundamental requirement for Architects to design flexible solutions. The flexibility requirement dictates implementation to be as such that the change of implemented things would be as quick, cheap and simple as possible. If development oversimplifies implementation making it almost immutable, this is a bad development in our days.

? SAFe: “#4 – When in Doubt, Code or Model It Out” [architecture principle].

o  M. Poulin: I never agree with a quick and inaccurate code caused by doubts in the development team. In the situation of doubts, I recommend requesting Architects for explanations as for the first step. "Nobody is perfect" and architects can make mistakes as well. Thus, the roots of doubts should be identified before writing a first character of the code.

o  M. Poulin: In too many cases, a development team does not understand why architectural requirements demand certain things while they can be implemented in a simpler way. The usual reasons for this are that Architects have considered the impacts and requirements that are invisible and unknown in development. "Simplified implementation" can ‘kill' the business value designed by Architects. For example, implementation of business services using Spring Framework with injected database connections for persistence (known as “coupling by implementation”) should be prohibited because this violates the Principles of Service Orientation and eliminates business adaptability via service re-composing.

o  M. Poulin: We have to recall that SAFe includes Architects above and across Agile Release Train and Trains. Doubt-based coding is a characteristic of an isolated Agile Team mentality where Architects are unavailable. When we talk about coding, we get away from Architecture. When we model design, we are in the architectural solutions, not in the Architecture any more.

? SAFe: “#5 – They Build It. They Test It” [architecture principle]. “The responsibility for knowing whether a design actually works rests with those who collaborate on designing the architecture. Testing system architecture involves testing the system’s ability to meet its larger-scale functional and non-functional operational, performance, and reliability requirements.”

o  M. Poulin: My 25+ years of development practice has taught me that never ever allow Developers to test what they have built. I’ve had several examples where a company outsourced development of the system to one provider while testing of the builds to another provider. This leads to the maximum bugless system.

o  M. Poulin: Yes, we have to verify “whether a design actually works”, but it is not enough because the architectural solutions can also be erroneous.

o  M. Poulin: We cannot test Architecture in isolation of its Implementation. We need to establish a mechanism providing analysis of the implementation test results from the architectural viewpoint. Thus, we can state a principle the architectural solutions should testable as well as their implementation.

? SAFe: “#6 – There Is No Monopoly on Innovation” [architecture principle]

o M. Poulin: This principle has nothing to do with Architecture and even Architectural Solutions. The monopoly in technology development always belongs to the business that pays for it. Whether an innovation is good or not depends on whether it brings a business value (a new value or the value with less cost). For example, when Scala appeared, it claimed to be easier and faster in development than Java. When this claim was measured, many people found that the cost of Scala adoption was higher that than the saved cost of increased productivity. This means, that such adoption was not feasible from the business perspectives. As a result, Scala adoption in the industry is slow.

o  M. Poulin: Nowadays, more and more development is based on orientation on service. In the Service-Oriented Ecosystem (OASIS, 2012), there is a principle that no one has a monopoly on such Ecosystem ownership and management. That is, Service-Oriented Architecture preserves that every one of its architectural elements (services) are independent of others and may have different owners. This Principle is frequently violated in the agile development where one development team tries to adjust an existing service for the new development despite it is owned by another team.

? SAFe: “#7 – Implement Architectural Flow” [architecture principle]

o  M. Poulin: Explanations provided by SAFe for this ‘principle’ is muggy.

o  M. Poulin: Any Architecture can change as well as related architectural solutions. Mainly, they change if the environment of their implementation changes. We can name it an “architectural flow”, but this does not add any value or constraint to any snapshot of such flow. If one says that the next Target Architectural Solution may not contradict the current one, this would be silly because this depends on the execution context, first of all. For instance, if a business service has been developed in Europe and, according to the corporate Strategy, should be used in China next year, this service and, probably, its supplemental services should change dramatically. This will cause a sharp difference between the current Architecture of the system and its Target version.

Based on the provided review, I can conclude that there is no evidence provided by SAFe, which can constitute and prove the term "Agile Architecture" in technology. An attempt to make everything ‘agile' around development is a risky business at the edge of insolvency. Similarly to that not everything that Architects touch is an Architecture, not everything that an Agile Development touches become agile. Moreover, it is possible to use SAFe method with no additional re-definitions of Architecture. And this means that all exercises performed by SAFe with regard to “Agile Architecture” are simply excessive.

In contrast, there is a case where business architectural solutions are required to be agile – agile to the market changes or, at least, to the pace of those changes. This is a totally different story because it is about the world existing in the enterprise quite above the technical development agility.

HAPPY NEW YEAR TO ALL !

[1] All texts in this column are quoted to SAFe

[2] A business flexibility is a measurable value used for comparing business solutions via the efficiency of their implementation. The formula of flexibility operates with the cost of the adoption of a change, time to market of this adoption and the cost of modification of this adoption caused by another change.

I provide on- and off-line #consultations on #architectural #solutions and #design for individuals and groups, on #Skype, 5 days a week. Cheaper that to call a plumber. Send requests to [email protected] with “CONSULT” in subject.