Software Architecture links

Ben Morris: What role do architects have in agile development?

Enter the “master developer”

In this case, some kind of design authority is generally required to work across the teams to ensure the integrity of the overall system and spot issues before they become obstacles. This role shouldn’t be confused with governance, where design edicts are sent down to teams from the “ivory towers” and architecture boards. It can only be effective with the consent of the teams.

The Poppendiecks referred to this role as the master developer in “Lean Software Development“. This idea is based on a study led by Bill Curtis where they found that for most large systems a single or small team of exceptional designers tend to emerge that take responsibility for the system design. The implication is that this authority emerges naturally through superior knowledge rather than being asserted by hierarchy.
This suggests a very different role for agile architects based more on influence rather than structured governance. Sometimes teams will need guidance and help, but architects will have to earn their respect before they can make a meaningful contribution.
Agile Modelling identifies a similar role of the “architecture owner” who facilitates the creation of architecture rather than taking sole responsibility for it. This describes a “hands-on” technical leadership role where mentoring and skills transfer is also an important focus.
This model also offers an approach for scaling up development, where architecture owners collaborate with enterprise architecture efforts to ensure that appropriate strategies are being adopted. In this model architects remain part of the team even at scale rather than forming a separate governance organisation.

Messaging shouldn’t be used for queries

In most cases where you would want to expose a query interface then the increased complexity and latency that messaging brings is often not worth the effort. Queries are based on a synchronous communication pattern it makes more sense to use a synchronous communication framework such as REST, HTTP or SOAP. These come with an implicit understanding that the exchange will be relatively fast, synchronous and prone to the occasional failure.

Why REST is not a silver bullet for service integration

The microservice community advocates a service collaboration approach based around “smart end-points and dumb pipes”. This is in part a reaction to the enterprise service bus (ESB) approach where the communication mechanism provides a bunch of sophisticated features such as routing, orchestration and business logic. The problem with the ESB is that it often winds up becoming a vast well of complexity and repository for business logic that should belong in services.

There is a place for REST in a service-based architecture, particularly when you need an immediate response. It’s just a little too much of a “dumb pipe” to provide the only collaboration fabric for a large and complex set of decoupled, autonomous and collaborating services.

Ben Morris: The problem with tiered or layered architecture

How do you break out of layers? Part of this is about mind-set. Considering a system in terms of layers and tiers as this encourages the development of generic components with vague ownership. A more service-based approach can help to provide greater flexibility where the system is broken down into self-contained, collaborating services with clear responsibilities.

Agile Architecture: Reversibility, Communication and Collaboration

At the inaugural O’Reilly Software Architecture conference, Molly Dishman and Martin Fowler discussed the role of architecture within agile software development. Key takeaways included; architects must remain ‘hands on’; architecture should focus on reducing irreversibility; adaptable documentation is essential in order to ensure clear communication of the architecture; exemplars of related good code and architecture should be shared when defining stories; and architecture is a collaborative effort across the business, and throughout the entire technical team.

ishman suggested that architects should not be removed from the actual process of coding software. Architecture should be about identifying things that are hard to change, for example, things will be expensive to change in the future in terms of money or effort. Fowler clarified that architecture is essentially the ‘important stuff’ within a software system, whatever that happens to be, but there is often a strong correlation between importance and things that are hard to change.

Fowler stated that the core driver of complexity within software is often irreversibility. As a metaphor to software development, traditional manufacturing focuses on managing complexity by reducing the number of possible states within system, whereas lean manufacturing attempts to reduce complexity by removing irreversibility. Software architects should embrace this core concept of lean.

People are adopting change and making that the norm, such as environment provisioning and infrastructure as a service. These are all things that 10 years ago or 15 years ago would have been on the list as hard to change.

Dishman discussed that during project inceptions, the key stakeholders gather, but often there is no architectural representation. This may be because business stakeholders don’t perceive the value of architecture. However, Dishman suggested that we need to be talking about things that are hard to change early in the project, when we know the least. An agile team should be focused on how can things can be made irreversible, up until the ‘last responsible moment’.

[Architects should identify] where are the things that are

Dishman highlighted the benefits of showcases, both from a functionality and technical perspective. It is important to communicate to stakeholders that architectural and technical thinking is evident, and to demonstrate that how the team is implementing the code is just as important as to how the business problems are being solved.

Fowler strongly recommended that an architect spends time working with the application codebase. One example of this is to ensure time is booked into the architect’s schedule for examining code commits. Some level of triage should be applied to this process, for example, if a developer is working on an area of the codebase that they don’t know well, or is implementing an architecturally challenging part of the application. If the architect is not fully happy with the implementation, they can spend time working alongside and pair programming with the developer.

One of the things that always amused me about the traditional waterfall style, is that when the architect or designer came up with a grand design, no one ever asked them if the code written actually matched the design.

Dishman began summarising the keynote by stating that architecture is a two-way street, between business and development. Business analysts and project managers should always be talking to the development team about changes, and exploring what the impact will be. Development teams must become comfortable with reporting the architectural status, and asking for permission and time for changing the architecture to remove technical debt or support future enhancement.

Dishman and Fowler concluded the talk by stating that much progress has been made at reducing the irreversibility of technical decisions, but this does not remove the need to communicate the architecture and architectural drivers. The most important resource for the development team is often time, and time must be given to the architects and technical leads to think, communicate and implement a good architecture throughout the team.

Like so many things in software, getting a good architecture for your system is primarily a people problem.

Additional details of Molly Dishman and Martin Fowler’s “Agile Architecture” keynote at the inaugural O’Reilly Software Architecture Conference can be found at the conference website, and the video recording for the talk can be found on Youtube.


some free books for learning about software architecture http://t.co/MdTiODjLwf
— Anton Arhipov (@antonarhipov) April 24, 2014