JB
Good day everyone,
This is my first post and I would greatly appreciate your help.
We are currently developing conventions for our EA effort and we saw that in the Demo DB-United Motors Group, that the DBMS, programming languages, Operating systems , etc. are modeled using the Application system type. But upon further exploration of the tool, we discovered that there are objects such as DBMS type, programming language, Operating systme type. May I ask what is the difference between the Application system type and the more specific objects? What are the difference (in terms of possible connections, assignments, and reports that can be generated) if any between them?
Hope you can help thanks.
Hi Mr Blando
You can find very useful info in your Method Manaul Document about your question, but generaly as you know the process/contol view of ARIS houes (like the other views) has a 3-tier life cycle include:
1. Requirement Definition Level
2. Design Specification Level
3. Implementatin Level
And we don't use any concrete object (i.e. DBMS, Applications system, IT function, etc) in Design level of Process view in combination with organasation objects. Instead, the tipifycatin of this objects (i.e. DBMS type, Application system type, IT function type, etc) is used to combine with the objects of organization view. The Individual objects must be used in Implementation Level.
Refer to pages 162 to 163 and 170 of your Method Manual Document. Sorry for my bad english. Have a nice day.
Tue, 09/07/2010 - 11:38
I think this question about another thing.
Application system typeis object for concrete systems, but DBMS, programming languages, Operating systems objects are uses to show Application system’s allocation. E.g. operating systems object shows that concrete system needs concrete operating system, etc.
I do not recommend to use this kind of objects, IMHO, they are ARIS’s remnant.
Also, you need to beware of using the more specific objects DBMS, Programming Language and Operating System as they have very limited availability in Model Types. That is why I generally avoid them. If you really like the more specific symbols, I suggest you import them (or some other symbol you like better) as user defined symbols for the Application System Type object. It will provide you with much more flexibility.
I agree with the above, stick with using the application system type objects. DBMS and Operating Systems objects add uneccessary complexity.
But, if you do want to categorise your objects, you could consider using the IT Archtitecture Matrix model type, create architecture elements for each category e.g. operating system, programming language etc then place map them to the application system type object. This will give you a picture of your technology stack. You could consider using a Technology Reference Model such as the one TOGAF provides to develope your technology categories.
