Published on April 8, 2018
Let’s imagine an IT architect with more than 10 years of experience at project, programme and enterprise level. This person starts working on each new task with two questions: “what is it?” and “why is this needed/important?”. The architect appreciates new technologies when they deliver what they promise and are there real potentials for business values and benefits observed. What this architect dislike is when people forget already gained experience and lessons and construct a “bicycle” under a different name and step on the same rake again, but blame technology for this instead their own illiteracy.
When learning the Scale Agile Framework (SAFe), the first that jumps into the eyes is a misleading use of the term ‘enterprise’. The SAFe makes a strong impression that it is applicable to the entire enterprise while the business part of the enterprise really does not care about how IT delivers its tasks if they are delivered on time and on SLA. Since SAFe has a potential to deliver the technological outcome faster, it is good. However, the enterprise has much more in its business part than an IT can see looking on the business bottom-up, i.e. onto the business implementation via processes and cases.
Our architect has grown up from a tester to an enterprise level and was lucky to work directly with the COO and CEO. He knows how many architectural things should happen in the business even before IT is called. The SAFe would make much more sense if it were addressed from within IT development point of view.
Another term that suffers the most is ‘architecture’ itself. Interesting, how many developers ever asked themselves why we have this term? What is it for? Without answering this question, a well-known statement “the best architectures, requirements, and designs emerge from self-organizing teams” [Manifesto for Agile Software Development] simply does not make sense. So, minimising details, the root of an architecture in the business organisation situates in the context of the corporate management and in the conditions of uncertainty that this management has to work with. Particularly, in order to manage an enterprise (in contrast to IT) many things should be abstracted and only the most important factors (the most influential factors) should be considered first; the details appear later, on the go. An architecture is a model and method of working with abstractions. This contradicts not only the “letter”, but also to the “spirit” of a particular mentality of IT.
Has any developer or the authors of the SAFe seen the construction of a building without an overall architectural solution (known as a blueprint) or where a team of builders decided whether a house needs a basement and how big or deep it should be? When a corporate business approaches a task that the enterprise has to resolve, it operates with entities and categories that developers, even those who write super-elegant code, might never heard about. In any case, the team in IT simply is not educated and trained in dealing with such tasks. If it would be trained, it will need to choose between researching this matter and writing code because there are only 24 hours in a day. Thus, the quoted statement from the Agile Manifest is a developer’s dream, which will never materialise because it is not sufficient.
An architecture changes mostly because of to two factors: 1) changes in the outside environment/market; 2) implementation forces cannot implement architectural solutions as defined. The art of architecture is in abstraction; this is why a statement such as “Architecture itself is fragile and needs to be continuously evolved – Technologies change rapidly and becomes outdated” is simply incorrect. It is only a bad, unprofessional architecture is fragile. A good architecture is the one that is more stable than the technologies used for its implementation. Technologies can become outdated or appear under new names, while business models and architectures (do not mistake them with operational models) usually survive over a few technology generations.
So, how this has happened that IT claims it has architects and SAFe specifies an “architectural runway”? First of all, IT has only Technology architects, regardless of “titles” they have because they are not exposed to the business and an architecture of the business organisation’s system. The SAFe explains, “The Architectural Runway consists of the existing code, components, and technical infrastructure needed to implement near-term features without excessive redesign and delay.“ Why this runway is architectural and how much abstraction you can find in the code, components and technical infrastructure? It seems that the term ‘architecture’ is applied here inappropriately (e.g. because it is a modern ‘buzz’ and ‘cool’). The much more suitable term here would be ‘implementation design’.
The major secret in the misuse of the term ‘architecture’ is in misunderstanding of the architectural abstraction. Yes, a recognition of differences between the architecture and its implementation is the key to understanding what really developers in SAFe/Agile/Lean/Scrum do. The same architecture can have multiple different implementations and each of which can have its own design. For simplicity, developers and uneducated managers in IT call technology implementation an architecture; in the SAFe, we have seen an expression “technical infrastructure” in the “Architectural Runway”. In reality, SAFe addresses a design that has to specialise the next or a few next implementation steps (also known as Low-Level Design and Specification for Implementation).
It is almost obvious that if many teams work on the programme/project and/or there are more than one ‘Agile Release Trains’, all designs for all Sprints and Trains must be set or put in line with the general plan or an overall architecture of the project. This architectural solution becomes the source of PI and milestones. The development team is the best for the implementation design within the boundaries of its competency, but not outside of it where the architecture resides.
The same logic is applicable to “Planning Iterations” (PI). In order to have an iteration, you have to have a clear understanding of the whole. This is the lesson learnt for a decade of iterative-incremental development in IT. A Product Owner or a Scrum Master can come up with a story if the topic is known, plus, all dependencies of this topic on other topics are known as well. For a small project, this knowledge can sit within the team. If the scope is bigger than for one team, there is a need on the cross-team architectural practice, which defines what tasks each team has to resolve while the team chooses the reasonable way of how to resolve these tasks.
A practice of re-defining terms, which were used for many years in technology and now understood by business, do not seem a good practice. For example, “Each Value Stream produces one or more Solutions, which are products, services, or systems delivered to the Customer“. A solution in architecture and its implementation is commonly understood as a way, means, decided activities that resolve the task. The customer is interested in the values, first of all. A stream of activities or values is what the solution defines, not the other way around. It is a solution produces value streams that are implemented (again) via “products, services, or systems”. In any case, products, services and systems are outcomes of the development activities, they are not solutions. Upon delivery, the customers decide whether the outcome solves the problem or not. “…development teams continuously deliver solutions“ means in reality that the teams implement the solutions and deliver the work outcomes; but why one needs to translate from a “technology English” to a plain English?
Similar misconception happens to “solution capabilities” – this expression puts the things upside-down. In English business terminology, a term ‘capability’ stands for ability to create/deliver a predefined outcome in the given execution context. In general, a corporate business work in this way: architects in the business (sometimes high-level managers) defines what the company should do in a particular situation and/or in order to realise the corporate strategy. Business functionality (defined for these “what”) combined with resources for its implementation and this combination constitutes the capability. Compositions of capabilities represent solutions. That is, a solution is an expression of capabilities that in different combinations form different solutions. This is the basis of the concept of orientation on service and modern responsiveness of enterprises to the changing market. If SAFe does not grasp this, it decreases its usefulness.
A possible confusion also comes from “customers are part of the value stream. They participate in defining solution intent and solution context, and they help validate assumptions and fitness for use.” This statement is true only for outdated application development practice where the outcome and all intermediary steps of the development stream had a particular internal customer who defined requirements. With the global shift to services, microservices, APIs, there are no particular customers who are involved in the value streams and define the solution intent; now, there are categories of customers with assumed (marketed) needs. The solution intent is defined by internal architects in the business. They have access to sale, marketing, analytic and compliance sources of information, not dozens or hundreds development teams. One of the reasons for this separation of labour is the dynamics of the market – the architectural work nowadays is a full-time job and one of the major tasks of it is to monitor, understand and react to the market changes on a daily basis when the developers in the teams are occupied with the processes of implementation of architected solutions. It seems that SAFE does not consider this aspect of changed reality and still busy with winning the game from ‘pure Agile’. Also, since the solutions are now compositions of services, the execution context is a must have, but it is now much wider than the technology used to deal with. For example, the context includes local laws, industry regulations, corporate policies and social customer, customs – just to list a few.
Those who worked with services for many years, it is difficult to pass silently the following nonsense: “Shared Services represents the specialty roles, people, and services that are necessary for the success of an Agile Release Train (ART) or Solution Train but that cannot be dedicated full-time. Because these resources are specialized—often single-sourced and typically quite busy—each ART and Solution Train must plan to engage in the shared services personnel it needs, when it needs them.” If SAFe needs a term for “roles, people, and services” that are specialised and in high demand, it should create a new term instead of obfuscating the old, stable and understood by all one. Shared Service represents only one thing – the service which is shared. Such service is usually engaged by architectural solutions in multiple service compositions (this is why it is shared) while roles, people, ART and Solution Trains that develop it are all immaterial for the service consumers. Developers of Shared Services focus on the category of consumers’ needs and work on shared services with the same workload as for any other services. Developers of shared services are not more specialised and busier than anyone else because whether the service is shared or not fully depends on the use of the service. Also, if other business services are developed by less specialised teams, it is almost guaranteed that they will be not good services after all, especially in our highly dynamic market. Before constructing development methods, it is always useful to learn the subject of what you construct for.
The architect can continue this analysis for long (unfortunately), but s/he wants to stop and finish the observation with a few questions. It seems that the fundamental requirement of the SAFe operational pattern is that the development runs in increments managed via “Program Increments” and “Planning Iterations”. It is not clear who defines the increments and iterations – the team or the architect working above and across teams, i.e. in the scope of a Train and even across Trains. The concern here is about the applicability of the entire SAFe – what if a particular business task requires delivery of its parts in full – end-to-end, one feature after another, or even a few features together? How sufficient the iterative-incremental model in such case? What drives the development – a process or a business need?
HOW to ARCHITECT for DEVELOPERS 