It appears that you're focusing on one specific point in Mark Richard's paper without considering the context that the rest of the paper provides.
Read the following three paragraphs (quoted from the paper). I have highlighted some key points in bold:
SOA is well-suited for large, complex, enterprise-wide systems that
require integration with many heterogeneous applications and services.
It is also well-suited for applications that have many shared
components, particularly components that are shared across the
enterprise. As such, SOA tends to be a good fit for large insurance
companies due to the heterogeneous systems environment and the
sharing of common services—customer, claim, policy, etc.—across
multiple applications and systems.
However, workflow-based applications that have a well-defined processing
flow and not many shared components (such as securities
trading) are difficult to implement using the SOA architecture pattern.
Small web-based applications are also not a good fit for SOA
because they don’t need an extensive service taxonomy, abstraction
layers, and messaging middleware components.
The microservices pattern is better suited for smaller, well-partitioned
web-based systems rather than large-scale enterprise-wide
systems. The lack of a mediator (messaging middleware) is one
of the factors that makes it ill-suited for large-scale complex business
application environments. Other examples of applications that
are well-suited for the microservices architecture pattern are ones
that have few shared components and ones that can be broken down
into very small discrete operations.
What the author is saying, in a nutshell, is that SOA is better suited to large, diverse systems with heterogenous components; that is, systems that must talk to each other, but each having differing interfaces and data protocols.
OK, now read the following three paragraphs:
Contract decoupling is the holy grail of abstraction. Imagine being
able to communicate with a service using data in a message
format that differs from what the service is expecting—that is the
very essence of contract decoupling.
Contract decoupling allows services and service consumers to evolve independently from each other, while still maintaining a contract
between them. It also helps give your service consumers the ability
to drive contract changes, thereby
creating a more collaborative relationship between the service and
the service consumer.
There are two primary forms of contract decoupling: message transformation
and message enhancement. Message transformation is
concerned only about the format of the message, not the actual
request data. For example, a service might require XML as its input
format, but a service consumer decides to send JSON payload
instead.
The author's original assertion should now be self evident:
Microservices architecture does not support contract decoupling, whereas contract decoupling is one of the primary capabilities offered within a SOA.
Of course, whether you consider that statement self-evident or not is entirely up to you. It's not clear to me why a microservices architecture would preclude the use of contract decoupling mechanisms, though it's probably true that SOA supports such "middleware" more robustly, or provides such middleware out of the box so that you don't have to write it yourself.
