The assignment of program flow chart to connection type “transmits data to” is a nice feature. But on the second level the description of data using Cluster/Data model object and Protocol is quite insufficient. How to show for example the data format and the ETL tool? The most appropriate for the ETL tool is probably Application system type but the Display flow and System fact sheet report will be distorted and they, unfortunately, are not editable. And then the data format can’t be an attribute as it will affect all occurrences of the Cluster/Data model so it should be another object. But which one and which connection type among those allowed by the method of Program flow chart are appropriate?
The alternative object “interface” is actually a symbol of class. If this would be the way to go, what about the issues mentioned above?
Thanks!
Ivo
Personally, I use the Interface object to represent the actual interface. I use the "transmits data to" connection type to show data flowing into and out of Application System Type. I use the "uses" connection to the Application System Type to indicate the ETL software. The Interface object can have both input and output data elements associated with it. You can use Technical Terms (I use these at the logical level) or entities, attributes (I use these from the source and target DB data models at the physical level) or Documents. For complex transformations you can also attach a Module Type or IT Function Type to the interface object.
As for data types, if you use attributes from existing source/target DBs they should already have data types.
Rick,
Thank you for your answer! I need some clarifications:
1. When you use input and output from Interface object do you link the respective data elements to application system type objects that are liked with this interface and if yes, is it idone in the same diagram and what's the result of the Data flow report in this case?
2. Could you elaborate about the data types
The best would be if you could share an example if that's not aking too much.
Thank you!
Ivo
Ivo,
1) Typically I attach data to the Interface object in the same Program Flow Chart diagram. The Interface object is shown as the "Data" in the Data Flow report.
2) Data types are modeled as "ERM Domain" objects on the "eERM" Model Type. So if you have a data model of your application database the data types would be there as domains. I have used third party tools to import database models from a data modeling tool (ERwin) into ARIS. If you do this the domains come along an associated "eERM Attribute Allocation Diagram".
I have some examples but I am not sure how to post graphics here.
Rick
Hi Ivo and Rick,
let me add some comments about this topic from IDS perspective.
First of all I have to admit, that your discussion touches critical points that are also subject of longer internal discussions. We have to deal with the problem, that our broad methodology offers different ways to express the same content. But we are only able to offer functional support (e.g. reports) based on clear methodical conventions.
The data flow between systems can be described in different ways. The standard convention we are forcing is to describe the data in the model assigned to the “transmit data to” connection. If you have problems using this to express all aspects you are intended to do, please provide us concrete examples where in becomes insufficient and we will care for this in further development.
Of course you are free to use the interface object. In this case the data input and output should be connect only with the interface, but not additionally with the ASTs that are connect by the interface. But the standard data flow report will ignore the interface, because he only works with the methodology preferred by IDS. We are thinking bout to enable customers to create a copy of the report and to adapt this copy to their own methodology. I think this would help you, but please keep in mind, that you create a proprietary branch of the report and it becomes difficult for you, to integrate change in the standard report, delivered by IDS in the future, into your own copy.
A last remark about the usage of technical terms: We had long internal discussions how to consolidate the data modeling capabilities in ARIS. The result was a methodology proposal covering all abstraction layers (conceptual, logical and physical). All our new functionality will be based on this proposal. Of course all other ways of data modeling will remain, but new functionality will ignore them. Technical term should not be used for data modeling anymore, their role is to describe the available terms that should be used to name the modeling elements in a consistent way. On conceptual level business Objects (object type cluster) should be used for data modeling, on conceptual level either entity types or UML classes
I plan to write a longer article to describe this preferred data modeling methodology in detail and to discuss it with the Community.
Hi Uwe, thank you for giving a sneak preview of what is coming up in the area of data management. I think it is great to be able to hear such inputs.
If there is one thing that I hope to see with regards to the capturing and display of metadata .. it is that ARIS support them using tables rather than models. Using models to describe long list of technical or business terms are just meaningless because the details of the attributes are not shown.
Often it is the user interface in ARIS that makes for painful capturing and viewing of the metadata. Even with the ERM, could the attributes be displayed within the entities just like an UML class diagram; rather than as separate boxes that take up much more space.
Pls continue to share.. thank you.
HC Lim
Uwe,
So far I couldn't find a perfect solution but the closest I got is the following: 1. To use AST for the ETL service so that all lifecycle and process support map capabilities could be used for interfaces; 2. If the file format is an important aspect, to use information carrier with file format user attribute (list of values); 3. When there is a change of formats the models looks like in the example diagram A where the name of carrier is not shown, only the value of the attribute "file format". However,"filefformat" could not be attribute of the data cluster as it is pertinent to the instance, not to the definition. The bad thing in A is that the data flow report does not show the data and the protocol but at least shows that there is interface between the two systems as well as the direction; 4. The diagram B keeps the report correct while utilising the benefits I mentioned in 1. Well "changes" is not the most appropriate connection type but anyway some relation between the ETL service and the data is needed.
I think I'll stick to B unless there are better suggestions.
Regards
Ivo
Ivo,
are you sure that you have the latest version of Business Publisher? Early releases of BP had this bug. If you are using the latest version, please, submit the bug to Global ARIS Support.
Re: the discussion above - how to model interfaces between IT systems. in detail That has been a subject of couple of projects I am aware of and here is the snapshot which shows hope clearly the solution which worked for the customer (Data Flow report was not considered and anyway can be adjusted if required):
XSLT document above can be related to attributes converted by the operations of the interface.
The scenario 1.1 is a part of larger best practice on Application Integration Architecture, touching other possible scenarios, including those where ESB is involved...
Generally speaking, in most cases an interfaces is a piece of software, either standalone or as a part of hosting major IT system. Rarely an interface is an abstract thing, but even in such cases Interface symbol\Objecttype Class is not semantically suitable.
"Uses" connecition between IT System and ETL software is also not very correct, at least does not correspond to the intention of this relationship. The connection type is used to show the relationships between an IT System and IT components (either software or hardware) supporting this IT system. Same relates to physical level where instances of IT system are using instances of e.g. DBMS.
Looking forward for your comments...
/Konstantin
Konstantin,
Thank you sharing this. It's more less the what I showed in model A. However, as I said data flow report is not allowed for editing (I never got any reasonable explanation why) so I don't know what you mean by "adjusted".
Regarding "uses", yes, it's intended for relating to components but it's the easiest way to have direct relation between system and interfaces which is vital for impact analysis.
Publisher version is 384599 (one build before the current). There are several strange things I found in this version:
1. Most of the symbols do not appear in th network diagram
2. Assignment on "transmit data to" as well
3. Some connections in EPCs are crooked and model attributes like model name do not appear on the model unless view "mark" is selected. I don't know what "mark" is, there is no explanation. And now idea how to have default views configured. In any case it's very frustrating.
Regards
Ivo
Konstantin,
From your previous writings it is not recommended to dipict the interface definition, using the class (interface object) as oppose to the Data cluster to link the application system to the ETL and then to the other application system. If one uses the class (interface object) then the attributes can be linked to the interface object as well. Why is using the data cluster preferred to the interface object? Why isnt it recommended to link the interface object to the ETL, which is shown as an application system type?
Will
