Martin Fowler's Blog, page 3

Scaling the Practice of Architecture, Conversationally

Like many modern software architects, Andrew Harmel-Law struggles with the need to scale architectural thinking to larger organizations while allowing teams to be as autonomous as possible. The approach he's currently using is the "Advice Process", that encourages and supports these teams to be engaged in broader architectural decision making. In this first installment, Andrew describes this advice process, later installments will dig into four supporting elements that help make it work.

more…

The strong and weak forces of architecture

Good technical design decisions are very dependent on context. Teams that regularly work together on common goals are able to communicate regularly and negotiate changes quickly. These teams exhibit a strong force of alignment, and can make technology and design decisions that harness that strong force. As we zoom out in a larger organisation an increasingly weak force exists between teams and divisions that work independently and have less frequent collaboration. Recognising the differences in these strong and weak forces allows us to make better decisions and give better guidance for each level, allowing for more empowered teams that can move faster.

more…

Bliki: DefaultTrialRetire

Within each normal-sized team, limit the choice of alternatives for any class of technology to three. These are: the current sensible default, the one we're experimenting with as a trial, and the one that we hate and want to retire.

The conversation goes like this: We want to introduce a new messaging technology. How many do we have already in place? Oh we have three in active use, including one that's considered legacy and we're partway through migrating off and one that we experimented with previously but didn't gain traction. Ok, so we're at our limit now. If we want to add another messaging tech then we have two choices. Either migrate all of our apps off the legacy tech, or properly rid ourselves of the failed experiment. This is quite closely related to the idea of capping the number of Innovation Tokens in use within your teams.

At a team level these kinds of limits are relatively easy to maintain and discuss and act upon, because we have common priorities and ways of working and high trust, high bandwidth communication. At the scope of the whole organisation the challenge is similar, but getting alignment takes a lot longer and doing actual migration and consolidation work can take a long time - so we sometimes have to allow for more variation in technology. We also use different techniques to discuss and communicate the status of our preferred technologies.

An approach we use at MYOB to engage our whole organisation in broader decisions about technology is by publishing our own MYOB Technology Radar, following the format of the Thoughtworks Technology Radar. This approach of building our own radar involves taking input from all of our verticals and teams, and making a clear statement on what technologies we encourage teams to adopt, trial, or more importantly which ones to keep clear of.

Compliance in a DevOps Culture

Integrating the necessary security controls and audit capabilities to satisfy compliance requirements within a DevOps culture can capitalize on CI/CD pipeline automation, but presents unique challenges as an organization scales. Understanding the second order implications and unintended consequences caused by the chosen implementation is key to building an effective, secure, and scalable solution. My colleague Carl Nygard describes how to think of these choices through a series of four patterns for handling compliance.

more…

Foreword to "The Art of Agile Development"

James Shore has revised his book "The Art of Agile Development". I'm pleased to write a foreword for this book as it is solid guide to learning how to get past faux-agile and develop the skills you need to get the benefits of the agile way of work.

more…

photostream 127

Bromley Mtn, VT (2021)

Responsible Tech Playbook

Those of us developing software don’t need to be told what a big impact it’s had on humanity this century. I’ve long maintained that this places a serious responsibility on our profession. Whether asked to or not, we have a duty to ensure our systems don’t degrade our society. But in the tumult of so many software projects, it can be difficult to step back and understand the implications of our work. In the last few months my colleagues at Thoughtworks have been putting together a catalog of techniques that we can use to address this problem, which they published as the Responsible Tech Playbook.

[image error]

The playbook is a free PDF download of about 50 slides, the bulk of which is a summary of a dozen tools and methods that teams can use to better understand their responsibilities. Each summary is a couple of slides outlining the basics of the technique: what is it, when we should use it, how it works, and our perspective on its place in our development efforts.

My colleagues highlighted three techniques that are particularly well-suited as first steps into this collection:

Ethical Explorer is a set of cards that use a metaphor of an explorer and risk zones to help a team discuss and understand potential dangers in their product plans. Consequence Scanning is some workshop activities and materials to uncover the unexpected consequences associated with a technology. It encourages teams to uncover these consequences and develop plans to mitigate any problems that they find. Tarot Cards of Tech are cards describing “provocations” such as: how a product could be used in unexpected ways, what users may be excluded, and what might happen if the product is over-used.

As these example suggest, these techniques are mostly ways to conduct structured workshops that help people explore different perspectives on their product. They also encourage engaging a wider range of stakeholders into the discussion and coming up with ways to monitor for bad outcomes and deal with them should they show up.

As professionals, we must take responsibility for the outcomes of our work - whether or not it matches our intention. We can’t avoid that responsibility by saying we are following our manager’s instructions, nor can we avoid the necessity of considering how our algorithms may lead to malignancies. Techniques like this help us explore our responsibilities and take thoughtful action to live up to them.

Further Reading

You can download the Responsible Tech Playbook as a PDF from the Thoughtworks web site.

Last year my colleague JoJo Swords wrote an article that explains more about why it matters that we understand our responsibility for our technology. In conjunction with that, Rebecca Parsons and Chad Wathington addressed the topic in a webinar.

Ship / Show / Ask: A modern branching strategy

I've written a fair bit about how using pull requests can encourage a low integration frequency, increasing cycle time and discouraging refactoring. Rouan Wilsenach has had success using an approach that categorizes changes as Ship/Show/Ask - using this classification to decide whether and how to use pull requests.

more…

What I'm up to now

A couple of months ago I announced that I was stepping back from speaking. A few people wondered whether I would still be writing. I did indicate in that article that I am, but I felt it may be worth saying a bit more about what I’m concentrating on these days.

more…

Gateway Pattern

We often need to access APIs from foreign codebases, and these foreign codebases usually have different vocabularies to ours. I've found it useful to encapsulate this interaction with a gateway that translates between our code and foreign code.

more…