For additional articles related to messaging and general programming, see the publications section of my website at wmrichards.com.
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.