SAML stands for: Security Assertion Markup Language

Security Assertion Markup Language (SAML) is an open standard for exchanging authentication and authorization data between parties, in particular, between an identity provider and a service provider. As its name implies, SAML is an XML-based markup language for security assertions (statements that service providers use to make access-control decisions). SAML is also:

• A set of XML-based protocol messages
• A set of protocol message bindings
• A set of profiles (utilizing all of the above)

The single most important use case that SAML addresses is web browser single sign-on (SSO). Single sign-on is relatively easy to accomplish within a security domain (using cookies, for example) but extending SSO across security domains is more difficult and resulted in the proliferation of non-interoperable proprietary technologies. The SAML Web Browser SSO profile was specified and standardized to promote interoperability. (For comparison, the more recent OpenID Connect protocol is an alternative approach to web browser SSO).

See above.

A federal enterprise architecture framework (FEAF) is the enterprise architecture of a federal government. It provides a common approach for the integration of strategic, business and technology management as part of organization design and performance improvement.

In business, master data management (MDM) is the comprehensive method used to consistently define and manage the critical data of an organization to provide a single point of reference. The data that is mastered may include reference data- the set of permissible values, and the analytical data that supports decision making.

MaaS stands for: Messaging as a Service.

IDentity as a Service (IDaaS)

PaaS: Platform as a Service
IaaS: Information as a Service
SaaS: Software as a Service
(Kaas is the Dutch word for cheese)

4+1 is a view model designed by Philippe Kruchten for "describing the architecture of software-intensive systems, based on the use of multiple, concurrent views". The views are used to describe the system from the viewpoint of different stakeholders, such as end-users, developers and project managers.

Valid goals are:
In general: a Message Queueing Service aims to eliminate the traditional overhead associated with operating in-house messaging infrastructures. These operating overheads include:
Specifically: unused capacity installed to meet peak demands
Specifically: projects idle time waiting for resource provisioning
Specifically: the need to isolate messaging resources
A message queueing service seeks to simplify access to messaging resources and therefore facilitate integration efforts within organizations and between them.
Human resources that are necessary to maintain messaging infrastructure

Improving response speed of web applications or distributed applications is, generally speaking, not a goal that can be reached using a Message Queueing Service. On the contrary, response times may be getting greater using such services.

A Message Queueing Service is a message-oriented middleware or MOM deployed in a compute cloud using software as a service model. Service subscribers access queues and or topics to exchange data using point-to-point or publish and subscribe patterns.

A microservices architecture is an approach to building a server application as a set of small services. Each service runs in its own process and communicates with other processes using protocols such as HTTP/HTTPS, WebSockets, or AMQP. Each microservice implements a specific end-to-end domain or business capability within a certain context boundary, and each must be developed autonomously and be deployable independently. Finally, each microservice should own its related domain data model and domain logic (sovereignty and decentralized data management) based on different data storage technologies (SQL, NoSQL) and different programming languages.

In software engineering, coupling is the degree of interdependence between software modules; a measure of how closely connected two routines or modules are; the strength of the relationships between modules.

All of the alternatives are enterprise architecture standards.