using information from other application provider

Post Reply
kgeis
Posts: 5
Joined: 10 Jul 2012, 00:37

I can't get the Application Data Dependencies view to show anything other than an application depending on its own data. In my application provider, in the "Uses Information" slot, when I create a relationship instance, one end of the relationship is the application at hand. This leads me to wonder,
is external data supposed to be modeled somewhere else?
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

We capture the information and data that is exchanged between Applications in the Static Application Dependencies part of the model.
This is a simple graphical model that we can create in the 'Application Dependencies' field of the Application Provider class.

On the graphical model, we drop 'usages' of each application onto the canvas and then double click on each shape to open the form that connects it to the required application. Then we can drag links between each application. Note that this is a dependency diagram, and each arc on the diagram defines that e.g. Application A depends on Application B [--->] - so the information flows against the arrow heads.

To capture the information that is exchanged, we can click on each arrow to open its form and in there, define the Application to Information relationships that exist in the context of this dependency.

This approach enables us to model simple Application A gets Information X from Application B but also enables us to capture more complex scenarios such as where Application A gets Information X from multiple applications.

Another nice thing about this approach is that we only need to model the "nearest neighbours", e.g. only the direct dependencies that an Application Provider has, and not any indirect dependencies. These keeps these models simpler and easier to manage and maintain.

The Application Dependencies Model uses these graphical models to query across all the relevant Static Application Architectures to find all the dependencies and all the Information and Data elements that are used in those dependencies.

Jonathan
Essential Project Team
kgeis
Posts: 5
Joined: 10 Jul 2012, 00:37

Thank you for your detailed response. I didn't realize that the connectors had properties.

Based on the information I now have, as well as some other posts I've read here, I'm wondering the best way to model specific situations.

First, my application uses a single sign-on service; I'd say that my application "depends on" it. It's probably not worth modeling the information exchanged between the systems. There is definitely information changing hands here, but it is not relevant domain information. Is this the place to model this kind of interaction?

Also, I'm thinking about integrations. I have two application providers (I'll call them A and C) and an integration script (I'll call it application provider B.) The script sends a batch file of data from A to C in the evening. In the morning, it retrieves a batch file from C and sends it to A. I'm imagining modeling this as bidirectional depends-ons between A and B, and B and C. That is, [A <-> B <-> C]. Does this follow the intentions of your model?
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

kgeis wrote: First, my application uses a single sign-on service; I'd say that my application "depends on" it. It's probably not worth modeling the information exchanged between the systems. There is definitely information changing hands here, but it is not relevant domain information. Is this the place to model this kind of interaction?
Yes. It makes sense to treat this in the same way as any other system. Information about the IT Domain can be just as important as business domain information. However, we can capture this sort of thing at a coarse grain if it is not that relevant to the current activity. If / when it does become relevant (e.g. a security activity or something) we can then pick this up and elaborate on that sort of information.
kgeis wrote: Also, I'm thinking about integrations. I have two application providers (I'll call them A and C) and an integration script (I'll call it application provider B.) The script sends a batch file of data from A to C in the evening. In the morning, it retrieves a batch file from C and sends it to A. I'm imagining modeling this as bidirectional depends-ons between A and B, and B and C. That is, [A <-> B <-> C]. Does this follow the intentions of your model?
You are correct that the integration components should be modelled as application providers - in particular when you are using integration middleware (in which case the 'flow' or 'orchestration' would be the Application Provider) or an integration script. What we are capturing in that Application Provider is the functionality or behaviour of the integration script (not the technology it's using - that's in the Technology dependencies).

Those relationships on the Application dependency model are uni-directional, so any information coming back would be captured as a separate dependency arc on the model. This particular model is a STATIC view of the application dependencies, so there is no sequential perspective here, e.g. "I send Information A and get back Information B".

So, to model the bidirectional dependencies that you describe [A<->B<->C], we would need four arcs on the model one for each direction - so that we can tell which Information things are moving in which direction.

As an aside, I mentioned that this was a STATIC model, the meta model also includes a dynamic model for application dependencies. This provides the ability to define a set of dependencies between application components and the sequence in which they apply. However, these dynamic models are associated with the functions of the application (Application Function Implementations) and describe what happens when that function is executed. The arcs on these models allow the capture of the information that is sent to and the information that is received from the function (effectively the signature of the function).

I don't think any of the out of the box Views cover this level of detail and for most purposes, the static models provide more than enough detail in terms of understanding the information that is exchanged between the Application Providers in the enterprise.

Jonathan
Essential Project Team
Post Reply