Interview: Key Software Architecture Recommendations
Apiumhub, January 2021
Interview with Mark Richards about some key software architecture recommendations.
A Promising New Metric To Track Maintainability
by Alexander von Zitzewitz
Hello2morrow, December 2018
In this article Alexander introduces an interesting new metric for how to measure the overall maintainability of a system.
Architects: Communicate like your job depends on it
by Fred Churchville
TechTarget.com, July 2020
Fred Churchville talks to Mark Richards and Neal Ford about software architecture and the skills an architect needs to survive.
Saga Pattern
by Chris Richardson
Microservices.io, August 2018
Chris Richardson describes this useful pattern when having to deal with transactionality in a highly distributed architecture like Microservices.
Pattern: Backends for Frontends
by Sam Newman
SamNewman.io, November 2015
I’ve been referring a lot to the BFF pattern lately (Backends for Frontends), and this article by Sam Newman is a great reference for this common pattern, particularly when designing API layers in a microservices ecosystem.
Sacrificial Architecture
by Martin Fowler
MartinFowler.com, October 2014
This short must-read article by Martin Fowler talks about what it means to essentially “throw away” portions of the code, and places a focus on architectural modularity, one of my favorite topics.
On Orchestrated Microservices
by Matt Stine
Build To Adapt, July 2016
This article really caught my attention because of the tweet Matt starts the article with: "if your microservices must be deployed as a complete set in a specific order, please put them back in a monolith and save yourself some pain”. How true this is. This article is a worth-while read as it might save you lots of pain and lessons-learned regarding the dangers of inter-service communication and orchestration within a complex microservices ecosystem.
Finding Structural Decay in Architectures
by Mark Richards
NFJS Magazine, April 2017
Most things around us wear out and eventually experience decay; the car we drive, household appliances and electronics, highway bridges, even ourselves. Software architecture is no different. One of the many responsibilities of a software architect is to continually assess the architectures supporting applications to determine whether they are still sound or in need of repair. But what does that mean and how do we do that? In this article I will discuss both architectural (macro) and source code analysis (micro) techniques for finding and fixing structural decay in your application architectures.
Tips for Transitioning into Software Architecture (Video)
by Mark Richards
O’Reilly SACON Interview, April 2016
In this interview video I discuss the attributes that a developer needs in order to transition into architecture. Ik also outlines the common mistakes that new software architects tend to make, as well as how established software architects can stay current.
The Challenges of Service-Based Architecture
by Mark Richards
NFJS Magazine, Nov 2015
Microservices is taking the IT industry by storm as the go-to
style for developing highly scalable and modular applications. While
Microservices offers significant advantages over monolithic architectures,
there are some significant challenges to consider and overcome before
jumping onto the Microservices bandwagon. In this article I will discuss
some of the challenges you will face when considering a service-based
architecture style and some ways of overcoming those challenges.
Architecting For Change
by Mark Richards
NFJS Magazine, June 2014
As an architect, you have probably heard at some point from the business “Our business is constantly changing to meet new demands of the marketplace”, or “We need faster time to market to remain competitive”, or even “Our plan is to engage heavily in mergers and acquisitions.” What do all these statements have in common? Change. It’s a different world than it was many years ago. Both business and technology are in a constant state of rapid change. That means architectures have to sometimes change as well. However, the very definition of architecture is “something that is really hard to change.” So how can we make our architectures respond faster and easier to change? In this article, I will explore the “architecting for change” meme and discuss several common techniques for ensuring that your architecture can properly adapt to change.
Leveraging the Roles and Responsibility Model
by Mark Richards
NFJS Magazine, June 2012
Whether starting out from scratch or maintaining an existing
application, there will always come a time when you need to add new business
functionality and capabilities to an application. Which classes and components
should contain the new functionality? This question may sound simple and
obvious but in most cases it isn't. All too often applications end up becoming
overly complex and unmaintainable due to one missing component: the simple but
powerful roles and responsibility model. This article shows how the roles and
responsibility model can be leveraged to build robust and maintainable software
applications.
The Secret to Building Highly Available Systems
by Mark Richards
NFJS Magazine, July 2010
During the summer of 2008 more than 200 flights
were delayed or canceled at the Dublin airport due to a shutdown in the Dublin
air traffic control radar system. In 2009, a shutdown in the FAA’s automated
flight planning and communication system caused significant flight delays and
cancellations across the country. In 2006 almost 200 flights were canceled at
the Seattle Tacoma International Airport due to power outages and system
failures in the Terminal Approach Radar system. Real-life situations such as
these can place people in significant danger simply because critical systems
were not available when they were needed the most. This article talks about how to approach highly available systems.
Creating an Effective SOA Service Taxonomy
by Mark Richards
SOA World, Oct 2008
It’s hard to think about Service Oriented Architecture without thinking of services; after all, services are the main focus of SOA (it’s even in the name). If Service Oriented Architecture is an approach where the business and technical architecture is oriented around services, then what exactly is a service? Unfortunately, the answer to this question varies greatly depending on whom you talk to and how you are using SOA in your organization. This variation tends to create quite a bit of confusion when trying to design and implement a SOA-based solution.