Layer style applied, but intuition is different

Question

Currently, I'm developing an architecture for a system of the following kind:

There are a couple of existing applications (front end) with which one can define UML profiles capturing some specific domain aspects. Since the tools are proprietary the produced models are not exchangeable by default. On the other hand there are a couple of tools which can analyze the produced frontend models (back end). These also have their own mechanisms (which are different from the frontends) to represent the domain aspects.

Since this would produce m*n model transformations with m frontends and n backends, I chose to introduce an exchange model which captures all relevant information from the frontends and nevertheless allows the backend to have enough information for analysis. This approach results in only m+n transformations.

My bird-eye view on the architecture:

Things go like that:

Transformation is possible between frontend model<->exchange model and exchange model<->backend model. Analysis tasks are triggered in the frontend and are delegated to the backend, where they are executed.

At the first glance, it looked for me like a layered style, but the more I thought about it, the intuition of the problem is not to make different layers exchangeable, where the layers achieve separation of concerns and focus on portability.

It is rather to introduce an intermediate layer, which decouples the two others and targets mainly at extendability. Another point is that the highest abstraction is not found on the highest layer but on the intermediate layer, i.e. the exchange format should be the core of the architecture where frontends and backends can be attached to. It should not need to know anything about its attached frontends or backends. This also means that the backend layer must know how to transform the exchange format into its own model representation, which is a upward usage not allowed in the layered style.

This boils down to the questions:

1. Do you know some architectural style which is similar to the one I depicted and also follows its intuition?
2. Why isn't this a good example for layered style (apart from the upward usage)?
3. Since the application is mainly model-driven, are there some specific architectural patterns/styles for systems of this kind?

Thanks for help in advance!

EDIT: Actually I am concerned with layers, because the coarse vision of this architecture is embedded in an existing project and is communicated there as "layers". But from an architectural point of view, it doesn't fit the style. The problem lies between the documentation and the communication of the architecture. If most of the stakeholders talk about a layered architecture and I introduce the layered view into it, although it isn't applied correctly, wouldn't this confuse all stakeholders, who have the right understanding of a layered architecture?

The goal is to document the views of the style which is really applied to have a correct basis for communicating the architecture.

Answer 1

The Frontend-Exchange-Backend presented in the question can be easily identified as very common three-layer approach, usually seen in distributed systems (see, eg middleware, maybe understood in a slightly broader sense).

Common language among stakeholders is more important, than purity of implementation. For example, many web-based MVC systems are far from the ideal and even far from being MVC in the first place. The meaning of layers in your case can be explained in some Overview section of the documentation.

More important is that the software architecture makes the system less complex by adding abstraction layer between heterogeneous frontends and backends.

At the macrolevel, layered architecture you describe seems to be ok. Personally I'd preferred component-based architecture in your case, but I guess those two aren't mutually exclusive, as components can be easily thought of as arranged in layers.

On a microlevel, take a look at structural patterns like Adapter, Proxy and Facade. Not that those should be used directly (it depends on what you are building, data processing patterns, etc). Patterns also depend on much impedance mistmatch there is between frontends and backends. For example, different modes of operation can make it harder to connect parts (eg, if one frontend uses "push" technology, another "pull" technology and, say, third one uses batch mode to run tasks/dump data once a day - I encountered this case in one of applications).

From your question it is not quite clear whether your application build software using UML models or is the end result of transforming UML into code (or is it even run-time interpreter for UML?). In any case, gluing is needed and the resulting architecture may be quite similar in both cases.

Model-driveness is, IMHO, orthogonal to layeredness of the architecture. However, I am not very familiar with Model-driven architecture, if this is what you mean. And in this respect ready parts of the solution constrain your architecture choice. IF I understood the question well, you have several DSLs (each of frontends use different UMLs).

All in all, it is very hard to advice suitable architectural abstraction from already highly abstracted overview. The advice is however to forget purity and care more for practicality.