About architecture and agile

This article was first published by IEEE Software Magazine and reprinted by Infoq & IEEE Computer Society.

Agile development can not be separated from architecture? Architecture without agile development? Is it possible that the answers to these questions must be based on a satirical caricature of a confrontational view based on deep-rooted values, rather than on a clear definition of the two, an open, speculative dialogue? Perhaps a more general description of the problem is a good start to answering it: in addition to focusing on the agile approach, we need to consider a wide range of development processes. And, rather than proposing hypothetical questions, we should think about more open and neutral issues--what is the relationship between architecture and process?

Architecture and procedures

The term architecture is often defined as "the structural splitting of the system, including module partitioning, inter-block correlation, interaction mechanisms, and the guiding principles of System Design"¹

Although it is not technically correct, this definition can support a wide range of interpretations. It can be referred to the technology, code, the actual system set up ² near-unrelated high-level abstract design, under the generation and many classes, code-level details closely related to the large and rigid design. However, the reality is that these two kinds of reference are not enough to guide the actual project development process, but not enough to make the necessary contributions to the "good" architecture. The former is so abstract that it is difficult to deal with specific details, and the latter has not yet learned the relevant facts. It is therefore not surprising that some people in the agile community do not regard architecture as a core element of real project development.

By contrast, Grady Booch³ and Martin Fowler⁴ have proposed a value-oriented software architecture definition. They define the architecture as an expensive and difficult decision to change. Paul Dyson and Andy Longshaw the structural definition of architecture as a complement to the argument for design decisions. These definitions help us to see the architecture as a solution to the needs of functional requirements, operational characteristics, and developer suitability.

In fact, from a hand draft to the key details, describe the software architecture without a variety of decisions: some decisions are appropriate and clear, some decisions need to assume conditions, and some decisions do not inadvertently, but later found important.

In this way, architecture is the guiding service for developing software systems capable of achieving a range of business and technical goal ⁶ , presented in a form most suitable for communication and sharing; it is not a technical creation in itself, it is a purely formal description.

A process can be seen as an answer to a series of questions: Who is doing what? What time? Why do you do it? For Who? Each software development project corresponds to a process, even if it is not obvious: whether loosely or formally, the process is responding to these questions regardless of whether the team actively controls development.

However, as you can see, the decisions we make in terms of project membership, budget and planning will greatly affect the choice and viability of the architecture. This conclusion applies to a wide range of issues, ranging from the powerful impact of system zoning, which ignores the initial version of Conway's Law ⁷ , to technical choices and skills, expected scope, release patterns, and even actual system design.

The interdependence of these impacts, coupled with the trend over time, requires the process to establish clear decision chains and direct and meaningful feedback loops for the related facets of the architecture, so that the latest information can be integrated into the decision making in order to cope with the impact of the inevitable inventions or discoveries. The process is to support the project team, not to reverse it, and the project team is to deliver the running software rather than follow the process. This is the goal of the agile process.

What does an architecture mean for agile development?

Compared to some of the discussions in the software community, agile development is not a requirement for scrum or other processes, tools, and methodologies like ship worship, although we do see this phenomenon and consider it a problem. The elements of agility are responsiveness, continuous learning and sufficiency. Agile is characterized by the sustainability and high quality of software and its development processes, and the unsustainable development of low quality runs counter to agility. The Agile Manifesto, "a sustained focus on excellence and good design is useful for agility", which identifies the role of agile development in the architecture-without a lot of up-front design.

Our friends and colleagues, Jens Coldewey, have made the assessment that the architecture can lead to rapid action. Even from any agile standpoint, if an architecture prevents you from making changes because it is not well analyzed and achieved, the result will be neither a good process nor a good structure. Such a framework will not work with the development team to continuously improve understanding of the goals and implementation of the system, instead of opposing the team and the constant demand.

When it comes to agile, a pragmatic architect needs to focus on a simple question: which architectural issues can hinder team agility. The problem is simple, but the answer is neither simple nor easy, because technical gurus and design experts need to negotiate several points of concern. The conflicts between modularity and application domain models, unnecessary coupling, and frequent interaction between components all hinder the understanding of programmers (architecture), drive up the time required for build and delivery, and are not conducive to programmer testing, small changes, and attempts. Unnecessary irreversibility, recklessness, and unstructured technical debt in any design ⁴ can lead to higher costs, lower livability, and hurt agility.

What does the architecture need to get from the process?

This column more highlights: http://www.bianceng.cn/Programming/project/

Where does the architecture come from? Driving a crane? Post with mail? Born from the mind of an omniscient architect? Or magically appear like magic?

Stop and think, architecture is just a way of expressing knowledge. As a knowledge-based work, software development needs to learn technology, learning customer needs, learning and presenting product needs of people to communicate, learn from the design practice to choose the best solution, learning cooperation and so on. In a word, knowledge comes from learning, learning takes time, and time is the constituent element of process.

Whether the whole product development or simple release, the beginning of knowledge at least, but also the most ignorant. Keep in mind that it is neither sensible nor responsible to finish all the major decisions in advance. On the other hand, knowledge accumulates at the end of the project, but there are few opportunities to practise it. In a nutshell, the architecture wants to learn from the process of space and time, which requires that the beginning should not be as closed as the end of the coffin. It can also be said that it is an empirical activity, in which each decision should be viewed as a hypothesis, validated and influenced by the next decision.

The project team is responsible for delivering the executable software, rather than strictly following the process.

This approach, based on response and learning, can accommodate a steady stream of needs. It is important that, even when it appears to be clear, demand will change as a result of a series of stable or unstable changes brought about by understanding, markets, and policies.

In life, we tend to understand things by classification and reasoning, in software development, this is also not a problem; in life, we often realize that the wrong category setting, the distinct division and the two-dollar theory will affect our understanding of things, and in software architecture and agile is not so.

Creative techniques influence and constrain creative ability, and the important design features of things influence and constrain creative methods. The strong connection between architecture and process means that architects need to be based on structure and technology, thinking about how the system development can be carried out on time. For the software itself, the developer, and the organization, the overall plan design is not necessarily the most appropriate solution. Agile processes are sensitive to continuous discovery and change in the environment. A pragmatic architect clearly recognizes the obstacles to the process, eliminates their frustration with programmers and related stakeholders, and makes them closely surround the architecture rather than simply working with the architecture.