Software Architecture Patterns in a Nutshell
In my professional career, I had taken on the role of an Application Architect and have immensely contributed to the design, analysis and development of software projects. In this role, I have designed data models and prototypes, evaluated potential risks and defects, analyzed specifications and provided generic solutions catering to multiple customers. I have also, overseen the design process for application software, provided technical support and training, and created technical documentation. Over the years, I have gained an insight into different software architect roles like Solutions Architect vs Enterprise Architect vs Application Architect, required skillset for each role and their key responsibilities. I have used different architecture patterns like Model-View-Controller, Event-driven, Microservices, Plug-ins, etc., within the realm of architecture styles such as monolithic application, client-server model and service-oriented framework.
In this article, I have provided an overview of software architecture, why is it important and four commonly used architecture patterns.
What is Software Architecture?
Software architecture is a pictorial representation of the application system that communicates the organization of the system, different components and their functions, and how the components interact with each other. This schematic representation is the outcome of the design principles architects use and the decisions they make.
Why do we need to focus on Software Architecture?
The development team makes the first set of decisions during the software architecture pattern selection and this is crucial in any project since sub-optimal decisions might result in budget and schedule overrun. The decisions should account for security, performance, scalability, maintenance and deployment within the constraints of infrastructure support, developer skill set, project budget and deadlines. Software architecture models make it easy to reuse them in other projects since you now know the decisions you made and the various trade-offs.
How do we know if our Software Architecture is good?
From my perspective, good software architecture should facilitate scalability and agility. The development team should be able to easily add new features to the system without affecting performance, integrate the system with external API frameworks, and should be easily maintained and deployed. Moreover, business stakeholders should be able to understand the overall architecture, core components and data ingestion points.
What are Software Architecture Styles?
A Software Architecture Style is the application design at the highest level of abstraction whereas an Architecture Pattern is a way to implement an architecture style. The architecture style specifies the high-level layers and modules of the application, how those modules and layers interact with each other, and the relations between them. This can be implemented using several architecture patterns with specific technology stack, policies and frameworks. Some common examples of architecture styles include Monolithic application, Component-based, Client-server, Layered, Pipes and filters, Event-driven, Service-oriented, etc.
What are Software Architecture Patterns?
In simple terms, architecture patterns help define the basic characteristics and behavior of an application. The patterns have an extensive impact on the code base, most often impacting the whole application either horizontally (ie. how to structure the code inside a layer) or vertically (ie. how a request is processed from the outer layers into the inner layers and back). Some architecture patterns contribute to highly scalable applications, whereas other architecture patterns help build applications that are highly agile. Knowing the characteristics, strengths, and weaknesses of each architecture pattern is necessary in order to choose the one that meets your specific business needs.
Layered Architecture
Layered architecture a.k.a. N-tier architecture pattern is the de-facto standard for most JavaEE applications and hence widely used by architects and developers. Each layer of the layered architecture pattern has a specific role and responsibility within the application. For example, a presentation layer would be responsible for handling all user interface and browser communication logic, whereas a business layer would be responsible for executing specific business rules associated with the request.
The advantage of a layered architecture is the separation of concerns, which means that each layer can focus solely on its role. Proper layered architectures will have isolated layers that aren’t affected by certain changes in other layers, allowing for easier refactoring. This architecture can also contain additional open layers, like a service layer, that can be used to access shared services only in the business layer but also get bypassed for speed.
Challenges/Limitations:
- The layered architecture pattern often results in monolithic applications, even if you split the presentation layer and business layers into separate deployable units. While this may not be a concern for some applications, it does pose some potential issues in terms of deployment, general robustness and reliability, performance, and scalability.
- Source code can turn into a big mess if it is unorganized and the modules don’t have clear roles or relationships. Developers often end up creating tight coupling between layers which results in complex interdependencies.
Best suited for:
- Building simple applications or websites with budget and time constraints.
- Teams with inexperienced developers who don’t understand other architectures yet.
Microkernel Architecture
Microkernel architecture a.k.a plug-in architecture pattern is commonly used for implementing product-based applications which is packaged and shipped as a third-party product available to download, or released as a internal software product with versions, release notes, and pluggable features.
This pattern consists of a core system and plug-in modules. Application logic is divided between independent plug-in modules and the basic core system, providing extensibility, flexibility, and isolation of application features and custom processing logic. The core system contains only the minimal functionality required to make the system operational. Eclipse IDE is the best example for this pattern, wherein the core system is simply a text editor and plug-ins make it a powerful IDE. Internet web browsers also use this pattern.
Challenges/Limitations:
- Since most microkernel architecture implementations are product based, they are generally smaller in size and implemented as single unit, hence not highly scalable.
- Implementation of this pattern is complex since the core system and plug-ins are bound by contract, and changes to core system will often result in changes to dependent plug-ins.
Best suited for:
- Applications with basic core features and add-on features customizable for clients.
Event-driven Architecture
Event-driven architecture pattern enables an application system to detect “events” such as a transaction, site visit, shopping cart update, etc., and act on them in real time. This pattern replaces the traditional “request/response” architecture where services would have to wait for a reply before they could move onto the next task. Event-driven architecture is often referred to as “asynchronous” communication. This means that the sender and recipient don’t have to wait for each other to move onto their next task.
An event-driven architecture leverages a messaging backbone to deliver messages from producers to consumers. This messaging backbone can either be based on a traditional publish-subscribe message broker or a distributed log. A publish-subscribe message broker allows multiple consumers to subscribe to groups of messages. Message are often deleted once all subscribers have received them. In contrast, a log is an unbounded set of ordered events. Consumers keep track of where they are in the stream using offsets. In an event stream, events are replay-able, which means a new consumer can choose to subscribe to events and they can read the log from the beginning if they so choose.
Real-time marketing, Internet of things (IoT), fraud detection, payment processing, website monitoring , etc., are some of the common applications that implement event-driven architecture pattern.
Challenges/Limitations:
- The event-driven architecture pattern is a complex pattern to implement, due to its asynchronous and distributed nature. We need to address various distributed architecture issues, such as lack of responsiveness, remote process availability and broker reconnection logic in the event of a broker failure.
- Since the event processor components are highly decoupled and distributed, it is difficult to maintain a transactional unit of work across them. Hence, we need to continuously think which events can and can’t be run independently and accordingly plan the granularity of the event processors.
Best suited for:
- Asynchronous and distributed systems with asynchronous data flow
- User interfaces, online shopping and financial systems
Microservices Architecture
The microservices architecture pattern is evolving in the IT industry as a viable alternative to monolithic applications and service-oriented architectures. The three key concepts of this pattern includes separately deployed units which allows easier deployment; the notion of service components, which can vary in granularity from a single module that represent a single-purpose function or an independent portion of a large business application; and a distributed architecture, where all the components are fully decoupled from one other and accessed through some sort of remote access protocol. These key features call for an effective and streamlined delivery pipeline which leads to increased scalability, and a high degree of application and component decoupling within your application.
The most common and popular topologies are the API REST-based topology and application REST-based topology.
The API REST-based topology exposes small, self-contained individual services via API. This topology consists of fine-grained service components that perform specific business functions independent from the rest of the services. Examples of this topology include single-purpose cloud-based RESTful web services found by Yahoo, Google, and Amazon.
In the application REST-based topology the client requests are received through traditional web-based or fat-client application screens instead of coming in via the simple API layer. The service components are larger, more coarse-grained, and represent a small portion of the overall business application. This topology is common for small to medium-sized business applications that have a relatively low degree of complexity.
Challenges/Limitations:
- Since the microservices architecture pattern is a distributed architecture, it has same complex issues found in the event-driven architecture pattern, which includes contract creation and maintenance, remote system availability, and remote access authentication and authorization.
Best suited for:
- E-commerce websites and streaming media applications which demands high scalability
- Development teams that are spread out, often across the globe
Pattern Analysis
The below table summarizes the architecture pattern attributes and help you determine which pattern to use based on your requirements. For example, if your primary concern is scalability, then event-driven and microservices pattern are probably good architecture pattern choices. Similarly, if you choose the microkernel architecture pattern for your application, then scalability and development might be risk areas in your architecture.
When choosing an architecture pattern, you must analyze all aspects of your environment like infrastructure support, developer skill set, project budget, project deadlines, and application size, etc. Choosing the right architecture pattern is critical, because once an architecture is in place, it is very hard and expensive to change.
Assessing your own experience
- Do you know the architecture style of your application system? Do you see more than one style?
- Is there any documentation on your application system architecture?
- What architecture patterns have you used? How has this helped you address specific business problem?
- Is your application scalable? Is it highly performant?
- Does your organization have software architects? What are their key roles and responsibilities?
References
Software Architecture Patterns by Mark Richards
