Communication, As-Is situation, roadmap or expected To-Be are the day-to-day work of a domain architect.
In case the Enterprise architect would manages the domain architect, than the domain architect would manage the solution architects.

The Domain Architect works with the same tools than the Enterprise Architect.
He develops cartography & models and uses these tools for his communication.
To work out Domain Architecture he or she uses a certain number of models in order to share different views regarding the information system. They ensure consistency of the information system in the Domain and in the Enterprise.

The DA presents an expression of a business vision for a specific domain, proposes a reflection on different choices and makes sure that these choices are in line with the Business Strategy.
To set up a communication, the DA:

• starts with a description of the Information System for his own domain.
• Afterwards a descirption is made of the different To-Be scenarios, as well as the different migration paths between As-Is and To-Be scenarios.
• Finaly, it is documentation which will explain the established choices.

By describing different To-Be scenarios, the DA creates a framework for future systems.
In this role, a scope must be defined which specifies the functional and technical limits in which projects must fit.
This framework is a scientific balances between the corporate interest and specific interests to each project.

With description of As-Is and the build of the To-Be for a Domain, this role is the bridge between the objectives and the execution.
In fact, the DA is there to create the link between documentation and assess the strategic objectives and the operational activities realized thanks to IT tools.
In this perspective, the DA expresses the result of a negotiation between the wishes & feasibility, a pilot of the quality for the IS components and means of managing the costs (Reduction in the number of project failures, avoidance of overlap and/or double functions).