Before EA come out, software architecture already used modelling to manage software matching of user requirements.
Software models break down requirements in functions and associate them with components. Then, one requirement may be in relation with many components as many requirements may be associated with one component.
In the case of one requirement relying on more than one component, all them perform a collaborative work which means many messages to be exchanged, some of them internally, some of them outwardly.
A message is, at least, a query about a part of an object state or an event notification to an object for changing its state.
The same may happen between functional components, regarded from the business point of view, and technical components regarded from developers point of view.
Developer is keen to connect its technical work with user requirements and business to show how the previous support the last one.
When development finishes, it has to be componentized for preparing deployment. Deployment packages contain logical components which are deployed on physical computers.
Basically, EA reuses the same approach but one scale larger since it encompasses all projects. EA provides the framework to glueing software models.