Complementarity and conflict between SOA and agility: Friends? Or the enemy?

From: infoq Qiao Liang

Is methodology and architecture mutually exclusive?

Some people think that software development practices and architecture are not repeated. This may be true in other environments, but it is not true in this topic. On the one hand, agile methods (such as XP) directly focus on design, rather than specifically agreeing to the idea of doing a lot of design (bduf) in advance. On the other hand, most SOA teams primarily focus on functional teams that build a series of services. In essence, SOA encourages characteristic team structures and communication methods between teams, both of which fall within the scope of methodology.

Agile and SOA are friends

SOA is an architecture that emphasizes that the business must meet market requirements. By constructing various services, it can eliminate duplicates and achieve the "reuse" objective. The team balances internal and external work by building "services" rather than "Applications.

Agility is a methodology that emphasizes that things are changing. Software development teams must embrace changes and respond to changes. By introducing technical and non-technical practices, the team can make the business agile.

Architectures and methodologies can be used together. They are complementary in nature. Furthermore, SOA and agility share the same goals, and both acknowledge that (1) changes are inevitable (2) organizations need to effectively respond to changes. Therefore, we expect to be able to select Agile Methodology when building SOA, and vice versa. Right?

Agility and SOA are enemies

You may think that since the goals are the same, the two technologies must be the same and there is no conflict, which means that the practice and architecture overlap. But at this point, SOACommunityDifferent from agile communities. Why?

One of the main reasons is that their starting points are different and their initial direction is also different. Despite the rapid development of agility in recent years, the Community has gained a lot of experience, summed up the "agile Declaration", and applied it to large projects. However, from the perspective of development history, agility is still "Grassroots ", from small projects. SOA is emerging and has a top-down nature. It uses the "divide and conquer" Method for software development. This method, especially the "division method", can easily lead to poor communication between teams, such as documents and specifications.

SOA conflicts with agility in the following three aspects:

• SOA encourages architecture design first, while agile holds the opposite view of this "bduf" approach.
• SOA encourages teams to be divided by functional clues, while agility tends to build teams in a cross-functional manner.
• In SOA, once a service is established, SOA no longer provides relevant feedback on service changes, while agility emphasizes timely feedback, either at the technical or human level.