Sparx Systems Forum
Enterprise Architect => General Board => Topic started by: steen.jensen on October 04, 2018, 07:59:26 pm
-
We have created some sort of Integration catalouge for all ouer integrations (nearly 1000) but thats only <30% of alla systems...
But we are struggling how to represent each integration in technical views and in the catalouge.
1 We have a Sematic Interoperability that we model as Business-Object ie Patient-Data
2 We have a technical interoperability where we use Interface-object ie Web-service on Source & Target systems
3 One chain of Integration-flow can be several technical integrations ie System1 --Integration1--> ESB-1 --Integration2--> ESB2 --Integration3--> System2
But what are best-practice with Archimate for this?? or what other methods is used?
-
I'd guess that interface design is crucial. Whether you go for a service oriented approach or something else depends on too many factors. But I'd guess the effort to define business objects (if you don't overdo that as everybody "knows" what has to go into Customer or Person and the like) will pay off more sooner than later.
q.
-
But what are best-practice with Archimate for this?? or what other methods is used?
I find that Archimate leads down a rabbit-hole. What I do when trying to come to grips with a new organisation is to use a very simple UML palette.
Capture as many applications as possible as UML components. If you discover a "system' just create it as a component and dump any constituent applications inside it (If you're feeling fancy use a packaging component).
If it's easy capture the organisation as actors and assign them to the components naming the association with a limited set of names; uses, supports, owns.
Where you absolutely understand the integration connect the two components with an assembly. Where you don't use a dependency.
Create an information item with the "concept" that is flowing between the two system. For example "customer" or "mortgage application". Create an information flow between the two components carrying the Information Item. And realise it across the assembly to save space. Do not try and model data at this stage - concepts only.
If you have got this far you have created half of the top row of a Zachman framework and have a map of your organisation.
-
...
Respect. Very concise. I'd just second that path.
q.
-
I agree with the method Glassboy indicates as well, but I think the notation can be both ArchiMate or UML, it doesn't really matter. As long as you have a clearly defined metamodel + guidelines that documents the notation, the purpose and how it should be used.
It should also be clear that anything that isn't in the metamodel is not allowed.
Geert