Companies and organizations usually need tools to measure how they are doing and what improvements are required to take the businesses to the next level.

The Maturity Model is one of the tools used by organizations to measure their capabilities in different areas and domains and assesses the requirements for improvements. The exciting thing about the maturity models is that they represent progressive upgrades from one step to another. Each new level provides new requirements in addition to the previous levels’ requirements.

As of today, there are many maturity models exist, such as People Capability Maturity Model (PCMM), OPM3 (Organisational Project Management Maturity Model), the Sustainability maturity model, and the Capability Maturity Model Integration (CMMI).

Like many other concepts and tools, the Maturity model is derived from business and engineering domains into the software domain — for example, Open Source Maturity Model, Service Integration Maturity Model, and Modeling Maturity Levels.

In this article, we will be focusing on the Maturity of REST APIs. How to measure the design of an API, and what is needed to achieve a better one. But, we need to understand first the purpose of evaluating our APIs and the value of improving them.

For more details, check the below article:

REST API Maturity Cube for Developer-Friendliest APIs

While building the microservices applications, you will find yourself in situations requiring using one or more of these patterns.

Although the Microservices-Architecture Style is relatively new, it becomes, in no time, rich with the mature tools, libraries, and frameworks that support most of the previously described patterns.

Implementing any of these patterns by yourself is an undesirable reinventing of the wheel because it will be a tedious, time-consuming, and error-prone exercise.

Before implementing any of these patterns, check the below mindmap for Microservices’ most important tools, libraries, and frameworks.

Microservices Power Tools

By the end of the 90s, three main leaders (Booch, Rumbaugh, Jacobson) have been grouped under a single consortium for the purpose of integrating their methods into a single, unified, de facto standard language for diagramming notations named UML.

Microservices architecture as a style is relatively new and similar to the beginnings of the visual modeling, a lot of leaders have individually defined the microservices according to their own perspectives. But, unfortunately, the discrete efforts had negative impacts on defining the shape of this style in a unified manner, especially the design patterns.

Nowadays, there are mainly 3 different schools for Microservices Patterns; Microsoft, Richardson, and Arcitura, introduced cumulatively about 145 patterns, with a lot of differences in the names and details, to provide reusable solutions for the common challenges that we may face while building Microservices Applications; Richardson introduced 58 patterns, Arcitura introduced 50 patterns and Microsoft introduced 37 patterns.

After reviewing the details of the 145 design patterns from the 3 schools, it has been noticed a lot of similarities and intersections between them, although the names in many cases are different. By taking the similarities and intersections into consideration, we were able to come up with 79 unique patterns which we will be listed in the following story.

Please find the below story for the complete list of the microservices patterns unifying the three schools.

Unified Microservices Patterns (UMP)

Don’t forget to follow me to get notifications for my new articles and please clap for the article if you liked it.

In Overview, we have seen the high-level roadmap.

By completing Part 1, you are ready now for more specialized domains. In this part, we will draw the reading path that need to be followed to be a Great Integration Architect.

Books for Great Software Architects - Integration Path

Don’t forget to follow me to get notifications for my new articles and please clap for the article if you liked it.

In Overview, we have seen the high-level roadmap.

By completing Part 1, you are ready now for more specialized domains. In this part, we will draw the reading path that need to be followed to be a Great Application Architect.

Books for Great Software Architects - Application Path

Don’t forget to follow me to get notifications for my new articles and please clap for the article if you liked it.

Personally, and through my reading journey, I found a link between these books. This link defines which book is considered a pre-requisite for another and which book’s content can make sense when read after another and which one should be the next to gain the full picture.

Without knowing this link, the reading will be rough and frustrating, consuming a lot of your time and effort. For example, and in many cases, I had to read the same book twice; the first time was before reading its pre-requisites, which was boring and confusing. On the second time, it was after reading the right pre-requisites, where everything suddenly became crystal clear.

In this article, I will show and explain the right reading sequence for the most important books in the software architecture world in the form of a roadmap composed of multiple paths, which is supposed, if followed, to streamline your reading process and make your journey smoother (hopefully smoother than mine) and to become a great software architect faster.

Note: In this article, it’s assumed that you have a good experience in one or more programming languages and you are interested in entering the software architecture world.

Overview

As explained in my previous article “Types of Technology Architectures”, there are many different types of software architectures that address different types of specializations, such as Application Architecture, Integration Architecture, Data Architecture, etc.

The reading roadmap in this article follows the same and it will have different paths according to the different types of software architectures, as depicted below:

As per the roadmap, no matter which architecture type you are interested to be specialized with, there is a fundamental path that must be followed before going into your own specialization.

Accordingly, the article is divided into 4 parts:

• Part 1 covers Fundamentals Path
• Part 2 covers Application Architecture Path
• Part 3 covers Integration Architecture Path
• Part 4 covers Data Architecture Path (still under progress)

Don’t forget to follow me to get notifications for my new articles and please clap for the article if you liked it.

As the software architecture field has been evolving rapidly over time (See The History of Software Architecture story), new terms have been constantly emerging and existing terms’ definitions have been continuously changing. As a result, the whole industry struggled to precisely provide universal definitions for many concepts in the IT community and the above concepts are not different.

Personally, I have read tens of books to get a clear answer about the three concepts, and eventually, I reached the most widely accepted definitions among all the communities which I will explain here in this story with an emphasis on how these concepts are complementing each other.

Please check the following article for more details:

Main Concepts in Software Architecture

Don’t forget to follow me to get notifications for my new articles and please clap for the article if you liked it.

To answer these questions and more, I have built the below timeline infographic that shows how the architecture evolved over the time and became in its current shape(s):

Infographic for Software Architecture History

In a previous thread named API Definition and History, we have explored how the APIs have evolved through time, generation after generation, until we get to the Web API generation. In this thread, we will list and consolidate the most common rules, conventions and standards for designing Great Web APIs, and we will group them into the following list of categories:

• Security
• Performance and Reliability
• Clarity and Consistency
• Change Management

For more details, please check the below-detailed rules:

Consolidated Design Rules and Standards for Great Web API

In a previous thread named Consolidated Design Rules and Standards for Great API, we explored the merged list of rules and standards for designing Web APIs which can be applied for REST and non-REST APIs. This thread builds on the previous thread and deeps dive into REST APIs in particular and lists the most common conventions, rules and standards that make REST APIs great and will be grouped by the HTTP methods.

At the end of this thread, we will see a step-by-step process to help you design a Great REST API.

For the General Rules, check the below article:

Consolidated Design Rules and Standards for Great REST API - Part 1

For HTTP method-related rules, check the below article:

Consolidated Design Rules and Standards for Great REST API - Part 2