Hello,
I want to use Aris IT Architect to create system architecture visualizations. From the enterprise architecture perspective you might call it a system engineering view.
Typically when I have to design a platform, also considering the surroundings systems, the following components and connections are needed. So far I was not able to find a model type which supports this. Even though a model type might have all needed object types, the connections are usually too limited. But since there are so many model types, I might not have found the correct one. Which one is recommended to create a system architecture?
Objects:
- Hardware Servers
- Network components like Load-Balancer, Firewal, SAN als logical component, etc.
- Sofware components like SAP, webMethods components, IBM MQ, Database, Application Server, etc
- Custom software modules hosted on the Application Servers, hosted on the webMethods servers,etc.
Connections:
- Map the software components to hardware
- Map the custom software modules to the software components
- Show communication paths between software components, network components and custom software modules
You might want to distinguish between the logical breakdown and the physical information (e.g. App System Types vs the App System [instance]). For most of the information you list above the Network Diagram model type is the way to go.
In addition to this I recommend to have a look at the demo database and how the PRO ORDER application system type is described.
Thank you for your answer!
The Network Diagram model type is the type which I am mostly using. But it has too many restrictions for the connections.
Why can't you connect an application system with a database system? Why can't you connect two applications systems with each other?
Or am I completely wrong and Aris doesn't know about communication paths and it is more about designing relations between objects?
We are using the using the Access Diagram (Physical) to represent each individual server in Aris Business Architect for SAP. This model allows the association of & access to the DR Plan, Costing document and multiple Application Systems running on the server. These Application Systems objects show up in the Business Process models (EPCs).
We also connect from the Access Diagram to the Project Model that shows the time line for upgrades, etc. that we are planning on working on. The Overall IT Infrastructure Plan model (Project Model) has the Application object that connects back to the Access Diagrams and shows the timing of the projects so we can coordinate with the business process owners.
Again, this is the distinction between the *type* vs. the *instance*. The network diagram allows you to show the instances of an application (just look at the various intances of Pro Order in the demo db model) answering the questions "What is installed on the box?". Consistently you have to use instances of your database in this model type. Instances are shown as "Application System" and the others as "Application System Types". In you example you would have to model which database instance (the physical DB) is used by which app instances - both object types would be "application systems".
To show the logical components (types) you will have to use different model types. For example if you want to show what your application system type uses as DB system or which HW type is used, you want to use an Access Diagram. Look at the Pro Order access diagram for an example.
Interfaces, as you describe them in your last comment, are logical constructs (e.g. which AST exchanges which (logical) data with which other AST and what protocol is used). For this case you might want to use the Program Flow Chart model type. The demo DB also has examples of this model type.
What ARIS does not allow -for a good reason IMHO- is to mix the logical and physical view of the applications.
You can find additional information how ARIS handles this in the Method Help (in the Help menu), the Method Manual (a PDF in the documentation folder), and the IT Architect Manual if you have ITA (also a PDF).
Thanks!
I agree that seperating of different views is important. But at the same time, having too many views is just as confusing as having all views in one graph.
Therefore all good architecture graphs are a compromise concerning mixing of views.
But for now I will try out all your proposals and let you know my experiences.
