Software architecture recommendations by Mark Richards

Apiumhub team organized a software architecture interview with a hands-on software architect we really admire – Mark Richards. Mark is a GSAS speaker, Apium Academy Professor and an experienced, hands-on software architect involved in the architecture, design, and implementation of microservices architectures, service-oriented architectures, and distributed systems in a variety of technologies. He has been in the software industry since 1983 and has significant experience and expertise in application, integration, and enterprise architecture. Mark is the founder of DeveloperToArchitect.com, a free website devoted to helping developers in the journey to becoming a software architect. He is the author of numerous technical books and videos, including the Fundamentals of Software Architecture, Software Architecture Fundamentals Video Series, and several books and videos on microservices as well as enterprise messaging. In addition to hands-on consulting, Mark is also a conference speaker and trainer, having spoken at hundreds of conferences and user groups around the world on a variety of enterprise-related technical topics. Let’s look at key software architecture recommendations.

Interview with Mark Richards: key software architecture recommendations

What is software architecture for you?

My view of software architecture is that it is comprised of two aspects: software architecture as structure, and software architecture as process. Within the structural aspect of software architecture there are 4 dimensions: architecture characteristics, architecture components, architecture styles, and architecture decisions. All 4 of these dimensions are required to form the structural aspect of any system. The process aspect of software architecture includes techniques as well as soft skills – negotiation, facilitation, and leadership.

What are the top 3 soft skills you believe software architects need ?

The top 3 soft skills for any software architect are negotiation, facilitation, and leadership. Negotiation is a required skill as an architect because almost every decision you make as an architect will be challenged. Your decisions will be challenged by other architects who think they have a better approach than you do; your decisions will be challenged by business stakeholders because they think your decision takes too long to implement or is too expensive or is not aligned with the business goals; and finally, your decisions will be challenged by development teams who believe they have a better solution. All of this requires an architect to understand the political climate of the enterprise and how to navigate the politics to get your decisions approved and accepted.

Facilitation is another necessary soft skill as a software architect. Architects not only collaborate with development teams, but also collaborate closely with various business stakeholders to understand business drivers, explain important architecture characteristics, describe architectural solutions, and so on. All of these gatherings and meetings require a keen sense of facilitation and leadership within these meetings to keep things on track.

Finally, leadership is another important soft skill because an architect is responsible for leading and guiding a development team through the implementation of an architecture. They are there as a guide, mentor, coach, and facilitator to make sure the team is on track and is running as smooth as a well-oiled machine, and to be there when the team needs clarification or has questions and concerns about the architecture.

What are the top 3 responsibilities of a Software Architect within the company?

The top three responsibilities of a software architect are as follows:

1) Understand the business needs and identify the underlying architecture characteristics required of a system
2) Make architecture decisions, justify those decisions, and effectively communicate those decisions
3) Lead and guide development teams and promote collaboration between software architecture and software development

What are the key software architecture attributes?

While there are literally hundreds of possible architectural characteristics, some common ones include such things as performance, responsiveness, availability, fault tolerance, agility, reliability, security, interoperability, scalability, elasticity, data integrity, and feasibility. However, it is critical to understand that there are no software architecture attributes that are common to any given system. Each system, and more specifically each part of a system, has it’s own architecture characteristics (“ilities”) based on what is important to the business for that particular system. You simply cannot say “Every system should focus on performance” when in fact performance may not be a concern.

There are, however, some common implicit architecture characteristics that are inherent to any given system – those attributes that are implied. These common implicit characteristics include feasibility, security, reliability, and maintainability. These implicit characteristics become explicit when they are important enough to be critical to the success of the system. For example, consider maintainability. This attribute remains an implicit characteristic until you get a business need such as very quick time-to-market. In this case, the speed at which you deply new features or bug fixes is critical to the success of the application, and therefore maintainability becomes a driving (or explicit) characteristic rather than an implicit one.

What is your opinion about Innovation vs Pragmatism ?

The second best words of advice I’ve ever received when I first became an architect was that I must remain pragmatic, yet visionary. Pragmatic is defined as “dealing with things sensibly and realistically in a way that is based on practical rather than theoretical considerations”, whereas being a visionary is defined as “thinking about or planning the future with imagination or wisdom”. Both are needed as a software architect, and striving for a balance between these, although difficult, is one of the keys to being a successful and effective software architect.

What are your insights about Performance & Responsiveness ?

While both are related to how fast a system is, responsiveness and performance mean two different things. Responsiveness is about how fast feedback or an answer gets back to the end user, whereas performance is about how fast a system can process information.

To illustrate the difference, suppose a user wants to post a comment on a website about a particular product or service, which takes 3 seconds to process. Assuming a network latency of 50ms to get to the service, Using synchronous communication protocols (such as REST) would result in a response time of 3100ms (3000ms for the comment posting, 100ms in round-trip latency). However, that same request using an asynchronous protocol such as messaging would only take 25ms (25ms to post to a queue, then control is returned back to the user). It would still take another 3025ms to post the comment, but the user is not waiting for the comment post to happen. This is a good example of responsiveness, because nothing was done about fixing the performance issues associated with the comment service. The tradeoff of this scenario, of course, is error handling.

What are your expectations regarding software architecture events, do you think in 2021 everything will be online?

My expectation (and hope) is that we will be back to in-person conferences by mid to late 2021. While online conferences do provide some of the knowledge transfer goal of conferences, much is missing in terms of networking, face-to-face collaboration, and human interaction. I miss that part as a speaker, and I am assuming attendees are also starving for that aspect of the conference experience as well.

What software architecture trends have you noticed this year?

One software architecture trend I have noticed this year is the movement towards low-code/no-code environments. I believe the reason for this trend is the need for businesses to respond faster to changes in the market, and writing and testing code simply takes too long. However, there are many negatives to this trend, including what is called the “last 10% trap”. Low code/no code environments are good at getting you 90% there very quickly, but the last 10% of effort is what kills most of these initiatives, mostly due to specific user or functionality needs that aren’t supported by the low code/no code environment.

I have also noticed a trend this year (finally!) with companies placing more of a focus on architecture as part of the daily activities of the development process rather than an singular activity that is done one at the start of a project. Companies are now realizing the benefits of evolutionary and incremental architecture, allowing the initial architecture to take shape during implementation where details are better understood and realized. This requires architecture to be flexible to accommodate that frequent change.

Lastly, I’ve noticed a downward trend this tear towards the adoption of pure microservices. More and more companies seem to be questioning the pure microservices architecture style and instead are moving to more hybrid architectures, combining service-based architecture and microservices together to form tight bounded contexts only in parts of the system where it makes sense.

Do you believe that silver bullets exist in software architecture?

I do not. Neal Ford and I coined the “First Law of Software Architecture” in our recent book Fundamentals of Software Architecture which states “Everything in software architecture is a tradeoff”. This is why architects usually answer every question with “it depends”. That said, I do believe there are some essential practices within the process aspect of software architecture, such as “always analyze tradeoffs”, and “focus on the why rather than the how“.

What is your opinion about Elasticity vs Scalability ?

While both elasticity and scalability both relate to maintaining a consistent response time when requests to a system increase, they differ from an architecture standpoint. Scalability is about ensuring consistent response times and capacity for sustained growth of a system over time, whereas elasticity is about being able to handle immediate spikes in user load (such as concert ticketing systems and auction systems such as eBay). Elasticity is also about MTTS – mean-time-to-start. The larger a service (or system), the slower it will be to respond to a user or request spike due to the length of time it takes to start additional service instances. Consider three basic architecture styles – monolithic (single deployment) architecture, service-based architecture, and microservices. Monolithic architectures don’t scale well, whereas service-based and microservices do. however, from an elasticity standpoint, only microservices supports this well due to the single-purpose, fine-grained nature of the services (MTTS is very low).

Could you share your insights regarding software architecture patterns?

When I first started publicly talking about architectures such as the layered monolithic architecture, microservices, service-based architecture, event-driven architecture, space-based architecture, pipeline architecture and microkernel architecture, I referred to these things as architecture patterns. This created quite a bit of confusion in the industry because people would ask “how do these patterns relate to other patterns such as CQRS (Command Query Responsibility Segregation), the Gateway pattern, the Adapter pattern, the Anti-Corruption Later pattern, and so on”?. I never really had a good answer, usually responding that the architectures I was talking about were more “higher-level” patterns. Several years ago, I started coining things like microservices, microkernel, event-driven, space-based, etc. as architecture styles to differentiate them from underlying architecture patterns.

Hence, an architecture style describes the way your overall system is structured (such as microservices, layered monolith, and so on), whereas architecture patterns are ways of describing certain and specific architectural aspects of that overall structure. For example, you can apply the CQRS architecture pattern to any architectural style – in other words, it doesn’t change the overall shape of that architecture. The same holds true with any other architecture pattern – any of them can be applied to better describe the underlying details of the overall architecture style you are using.

What software architecture recommendations would you give to big international companies ?

The number one recommendation I would give big international companies in terms of software architecture is to make sure you identify (and continually analyze) the architecture characteristics (“-ilities”) that are needed for that particular system. You simply cannot create a successful and functioning architecture unless you have the right architecture characteristics in place. Is scalability your most important concern? Is it performance, data integrity, system availability and fault tolerance, or security? Each architecture style supports it’s own set of architecture characteristics. If scalability and fault tolerance are your number one concerns and you have a traditional layered monolithic application, it will eventually fail, regardless of the functionality of that system.

Deriving the required architecture characteristics from business needs is the key. If the business is undergoing major acquisitions and you focusing on performance, you will likely fail – interoperability, extensibility, and scalability are what are important. If the business requires the shortest possible time-to-market so that new features and bug fixes can reach it’s customers in the fastest way possible and you focus on scalability, you will fail – agility is what is important.

What software architecture recommendations would you give to startups ?

Regarding startups and architecture, my recommendation is to focus your architecture efforts on extensibility, adaptability, and change (flexibility). Using domain-driven design, start out with a simple modular monolith, then move those modules to domain services using service-based architecture, then move those domain services requiring more scalability, throughput, and agility to microservices if needed. This evolutionary progression allows startups to get functionality out the door quickly and to then evolve the architecture as you learn more about the business needs and business direction.

What are the main issues in software architecture?

One of the main issues I see in software architecture is the continued practice of “putting the cart before the horse” – making architecture decisions and choices without qualifying the business needs through architecture characteristics and undergoing proper and complete tradeoff analysis. Too many times we “jump on the bandwagon” of a particular trend, platform, product, or technology without analyzing the tradeoffs of those choices. For example, so many companies jump to microservices without analyzing whether they need it or not, or start embracing quantum computing or AI/ML without fully understanding the implications of those areas or whether they even need them or not.

Your software architecture journey: lessons learned ?

My lessons learned:
1) Soft skills (people skills) matter in software architecture – they constitute 50% of being an effective software architect.
2) Always keep the project and business constraints in mind when creating and analyzing software architecture (cost, time, budget, skill leves, etc.)
3) Don’t get caught up in the hype as a software architect – stop, analyze tradeoffs, study trends, and approach new technology with caution.
4) Focus more on the “why” rather than the “how” – this is what is truly important is software architecture
5) Spreading knowledge is more valuable than being an individual contributor.

BIO & Contact Info

Independent Consultant
Founder of DeveloperToArchitect.com

• Twitter: @markrichardssa
• LinkedIn 
• Email: [email protected]
• Website: Developertoarchitect