The history and background
In MIIS2003 the ECMA1 (also known as XMA) framework was introduced. It was essentially a file-based connector that allowed adding code around the file processing. There was a call-based export feature as well, but since there was no corresponding call-based import feature, it was less useful. Many connectors were created on ECMA1, but it had obvious disadvantages. Many of the built-in connectors had access to data not available to an external connector developer. This made it hard or impossible to write connectors for some scenarios. For example, the initial Office 365 connector for DirSync (this was before the Azure AD rebranding) was re-written three times to work around limitations in ECMA1.
To address these issues, ECMA2 was developed. It was created with the goal:
A team at Microsoft, a partner or a customer can create a connector that can have the same functionality, stability, and performance as a connector shipped out-of-box.
Almost as soon as FIM2010 had shipped, this was the main project the sync team worked on. ECMA2 was enhanced numerous times (2.1, 2.2, and so on) to complete the vision that all connectors should be possible to build on it. All the new connectors from Microsoft were built on ECMA2, verifying the design and add enhancements as needed.
During development, the project was called "EZMA" (pronounced "Easy-MA") and this acronym can still be seen in the sample code generated by the sync engine and on MSDN.
Some principles were defined when ECMA2 was first conceived. The vision and ultimate goal were that every connector shipped out-of-box should be possible to create with ECMA2. That would allow partners to create connectors to systems Microsoft would never go after. But it was also time to revamp all of the connectors that Microsoft shipped in FIM2010. There were numerous complaints about the feature-lacking out-of-box Lotus Notes connector. All of the database connectors were built on OLEDB, a technology slowly being deprecated by all database vendors.
Another principle was that an ECMA2 connector should be possible to run without the sync engine proper. So why would this be needed? As an example, there is a SharePoint UserProfile connector shipped from Microsoft. When you want to test a new release of SharePoint, you want to make sure it can be tested by the Office team without them knowing too much of FIM2010. By allowing a connector to be invoked outside the sync engine, you can test another product with a test harness, which is mimicking the sync engine. A common thought experiment that was used when designing ECMA2 was: "If Microsoft decided to build a virtual directory, could an ECMA2 connector be used to connect to the remote system". (Microsoft didn't plan to build a virtual directory. This was only used to try the concepts theoretically.)
Yet another reason to build ECMA2 and build connectors from Microsoft on it was so the connectors could be shipped independently from the sync engine. With MIIS2003 and ILM2007, when a bug fix for one of the built-in connectors had to be shipped, the entire sync engine was released. When FIM2010 was released, the FIM Service also had to be released for every connector bug fix. For many customers, it was a daunting task to upgrade both the sync engine and the FIM Service for a simple fix. By separating the connectors, these could be shipped independently of the sync engine.
As of today, the ECMA2 framework is complete and has delivered on its initial goal. It is a good platform for building your own custom connector.
There are a few things an ECMA2 connector cannot do that still requires built-in connectors.
It cannot interact directly with PCNS; only the built-in ADMA can do that.
It does not have access to internal asynchronous interfaces. Only the FIM Service MA has access to these. The asynchronous interfaces allow a connector during export to receive data from the sync engine but not return the export result immediately. Instead, the connector comes back later with the result on another interface. The reason the FIM Service connector is using this is to allow it to be multi-threaded. One thread receives data and dispatches it, but multiple threads process the data and return the result to the sync engine.
Connectors and management agents
The "thing" that is connecting to remote systems used to be called management agents, but these are now called connectors. In the UI and in interfaces the old term MA can frequently be seen.
There were several reasons why the term was changed. The primary reason was that nobody actually called them MAs and referred to them as connectors. The industry standard was "connectors" and in all analyst reports, these were always referred to as connectors.
The Wikipedia definition also didn't help:
A Management agent is a software agent that runs on a managed node (example: a router) and provides an interface to manage it.
All connectors have always tried to avoid installing anything on the remote system. As much as possible, the connectors use public remote APIs and try to not have a dependency on software created by Microsoft installed on a remote system.
To align with the industry, the term "connector" was introduced instead.