Static Application Provider Architecture without xxxUsage?

Post Reply
aba
Posts: 7
Joined: 14 Dec 2009, 20:38

Hallo,
I have a question regarding the "Usage" objects used to model relationships between Application Providers (and other objects), e.g. static relationships between Application Providers. I've read the topic "http://www.enterprise-architecture.org/ ... p?f=8&t=78", but have further questions. Since this seems to be a pretty low level discussion, I say sorry in advance regarding the length of this post.

Situation: In our enterprise static relationships between applications (or Application Provider in essential model) are an important entity. The organisation is used to discuss integration architecture issues based on these entities. Today detailed information about our so called Application Interfaces are kept in excel sheets, including many attributes. We now consider to use essential protege in the future.

Problem: When modeling static relationships with essential xxx_Architecture objects, the RELATION objects are actually connecting two Usage objects.
Sample: We have Application Provider A and B. A interacts with B via an interface called "getCustomers". In both Static_Application_Provider_Architectures for A and B I want to visualize this interface via a relationship (which is actually an :APU-TO-APU-STATIC-RELATION instance). Due to the essential decision to connect Application_Provider_Usage objects instead of the Application_Provider objects directly, this leads to a duplication of the interface, which is not acceptable for our requirements.

Questions:
a) Is it generally a good idea to model our so called Application Interfaces via essential Static Architectures? Or did I miss the proper way to use the essential meta model?
b) I tried to extend the essential model with my own Static Architeture class and RELATION class (via subclassing), directly connecting Application Provder objects - that worked fine for me. BUT: Is that a recommended way to use essential? It seems to be a deep "intrusion", am I right that we will loose ability to upgrade to future essential model extension?

Thanks in advance for any hints and clarification.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Thanks for your post.

When we designed the Essential Meta Model, we realised that Integrations are a class of applications that usually do not have any user interaction. They still have behaviour (which is what applications are about) but rather than working with user interfaces, they have system interfaces. Therefore, integration solutions are captured using Application Providers, too.

The static application architecture captures the dependencies between application (providers). To more accurately capture how this works with integration solutions (e.g. a flow defined in an integration broker, a Web Service-based composite application), an application depends on the integration solution rather than on the application at the other end of the integration flow. Both in terms of technical connectivity and the data forms. However, there's not much detail that can be associated with this dependency.

You mention in your example the 'getCustomers()' interface. This could implemented as a single integration solution (in which case you can capture this as an Application Provider) OR it could be that this is effectively an operation on an application. In this case, we capture these operations (or functions) as Application Function Implementations (apologies for the long name!). These are used to capture a specific API, transaction, screen etc. of the Application Provider that exposes a particular bit of behaviour. So, in this example, there could be a getCustomers() Application Function Implementation on a CRM Application Provider.
Each of these Application Function Implementations can have a Dynamic Architecture that describes what happens (in terms of more detailed dependencies) when that function executes.

Usages are very important concepts that provide the contextual information about an element when it is 'used' in an architecture. The Application Module Summary report in the Essential Viewer explores all the usages of the Application Provider in question to find all the dependencies to and from that application, across all the Static Application Architectures. This means that dependencies to this application (A) that are defined in the static architecture of another application (B) are discovered. Application A might appear in the static application architecture of many other applications.

You can also drop Application Function Implementation Usages onto the static application architecture to show there are dependencies (invokes is the default label) on a specific function rather than just generally on the application.

I realise that at the moment, the contextual information on the Application Providers and the relationships is quite light at the moment. However, it may be that we need to start adding some attributes to e.g. the relationships to describe the list of Information elements that are passed on the dependency in a bit more detail. Right now, you can capture this in the description of the relationship or in it's label (which doesn't have to be "depends on").

Usages are very important and are discussed a bit more in this article on working with architectures.
I would not recommend linking the application providers directly because you will lose the contextual information. For example, with the usages, we can capture that A depends on B in the context of A's static architecture (and add some more about this dependency) while A also depends on B in the context of C's static architecture. For a summary level report (e.g. the Application Module Summary) this amounts to the same thing, however, the contextual information might be very important for other reports. However, when we then go back to these architectures and remove dependencies, e.g. C's architecture has changed so that A no longer depends on B, the dependency between A and B remains in the static application architecture of A. Relating A and B directly would not allow us to do this.

You are seeing duplication in your visualisation because you have defined the dependency between A and B in both the architecture of A and of B. I think that this is a modelling issue. The duplication that you are seeing raises the question - is it right to capture this dependency twice or are they in fact 2 different dependencies between A and B?
Currently, the Application Module Summary report in Viewer will report all the dependencies - it won't de-duplicate these as it's not possible to tell at report-time whether this is a duplicate or whether there is a DIFFERENT dependency between A and B in the context of B's static architecture. It could be that different people are modelling A and B - and we've tried to design all this with multi-users in mind - and they could be trying to capture different things.
I think the bottom line here is that I don't think you can say that there is only ever 1 dependency between 2 applications across all the static architectures and I wouldn't want to enforce that in the meta model. Resolving duplicate dependencies is a model-governance issue.

I appreciate that the benefits of the Usage concept might not be as apparent as they are e.g. in a technology architecture, but it's a very powerful and useful approach to managing the dependencies between things and most importantly the context in which the dependencies exist.
I think this would be a good opportunity to explore what contextual information we should be capturing in the static architecture - and this relates to another recent posting about data flow. At the moment, each dependency between applications in the static architecture says that there's a send or receive of data between the linked applications. There's no more detail in the static model. Perhaps we need to look at adding a bit more detail to the dependency.

To answer your final question, although it's hard to tell without seeing the details, I don't think you'll have too many issues with updates to the meta model - your classes will inherit any extensions to the Application Provider or the Relation classes. The worst-case scenario there is is some sort of re-factoring update which re-structures the class hierarchy. We would need to work together on how to take that forward. The biggest issue that you'll find is that all the application reports and analysis in Essential Viewer will be written to work with Application Provider classes and the specific APU_TO_APU relation classes and will not pick up your extensions. So, for example, the Application Module Summary report will not work with your extensions unless you extend/customise the report.

Thanks again for your post. Apologies for the very long reply but I hope that a bit more background to the meta model is useful.
I would be more than happy to explore with you more details of what you need to capture and how best to approach it in Essential. Also, if there are requirements that you have that can't be met by the current meta model, let's look at how to address these.

Jonathan
Essential Project Team
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

I've just been reminded of a useful rule to use when defining the static application architecture.

If you're defining the static application architecture of Application Provider 'A', only define the dependencies FROM 'A' to other applications. Dependencies TO 'A' will be captured in the static application architectures of those other applications that depend on 'A'.

Finally, we've just been discussing this in the project team and we think that it makes a lot of sense to be able to specify the data that is exchanged on each dependency (as an attribute of the relationship class) in terms of the Information Representations used.

Let me know your thoughts on this and we can prioritise this as an update to the meta model.

Jonathan
Essential Project Team
seldont
Posts: 11
Joined: 14 Jun 2016, 10:58

Is this advice still correct or are there any better ways to model interfaces/integration?

I will be working from data flow diagrams that show a number of applications and the data flow between them (including [Direction of flow], [Push/Pull],[Frequency/Event trigger], [Transport Method] ).

I would like to store the above information in Essential along with more detailed information about the data content, validation and process control. Can this information be represented in Essential?

This work is in preparation for converting many CSV and direct database interfaces into web services that will communicate via an Enterprise Service Bus.

Do you have any recommendations?

Assuming we can model this information in Essential - is it possible to reproduce any sort of data flow diagram from the stored data?
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi,

Yes, this advice is certainly still correct. Use the Static Application Architecture models to define the dependencies that exist and then add the information that’s flowing between the applications on the ‘arcs’ of that model to show what’s being consumed from an information perspective.

The type of content that you’re looking to capture is certainly the sort of thing that can be managed and used in Essential.

- The direction of flow is defined by the dependency arrows on the model. Each of these arrows on the model defines an instance in the repository that is uni-directional, defined by the :FROM and :TO slots. Note that this is a dependency relationship, showing that, e.g. A depends on B, in which case the relational goes FROM A TO B. However, in terms of information / data flow, this means that A gets information from B, therefore in the model, the information flows from B to A.

- In terms of Push / Pull or transport method, we can define this using the “Acquisition Method” slot on the Application Dependency Relationship class, :APU-TO-APU-STATIC_RELATION that is represented by the arrows on the static architecture model.

If you need to get into things like the events that trigger the movement of the information, we have a lower level of detail that we can get into with the Application Function Implementations and their associated Dynamic Application Provider Architecture. These architectures describe the dependencies that exist when a particular component of, e.g. Application A is invoked and each dependency arrow (again, another class) from an Application Provider to a function on this diagram shows a sequence of the order in which things happen and can hold the information that was sent as well as the information that is returned when Application Provider A invokes function X.

It certainly is possible to produce data flow diagrams using these models - and we have one coming very soon in the next release of the Essential Viewer, that combines information about which system is storing the data and where it goes next. We have also done some custom views that track the flow of data from external sources right into the applications at a Data Attribute level. This is nice but does require a LOT of modelling.

You may find that using the Import Utility helps a lot but should start to give you a strong model of what information is being moved using those CSVs and direct database integrations.

Do let us know how you get on and please do let us know if you need any further help with this

Jonathan
Essential Project Team
TMC
Posts: 15
Joined: 27 Oct 2017, 12:17

I've just discovered my modeling through static architectures was leading to duplicate data flows, and this article confirms that if application A shares information with application B, defining that dependency in the static architecture of both creates a duplicate. (Which isn't visible in '3 col model' of Application Dependency Model, but appears when you expand to 'detailed feeds / 5 col model'.
I get the recommendation of each application only defining 'inward' flows as an approach to avoiding this duplication (I had just figured that out as a possible approach as I started scanning the forum). But I would make the observation that this approach rather assumes a steady state, mostly complete model coverage. We are building out model coverage application by application from a zero base, so it is far more natural for each application to specify inbound and outbound - otherwise no application will be complete until we have covered many of the applications. We intend to make individuals responsible for modeling their assigned application(s), but that will not work as well if the modelers themselves are dependent on others.
A more useful approach to me (and one which I assumed was in place based on the three col display of the application dependency model) would be to allow duplicates in the static architectures, and match and ignore duplicates when displaying the dependency model. That would still preserve the vital advantage of the model in revealing dependencies for an application that aren't noted in that application's static architecture.
Regards
Tudor
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi Tudor,
 
You found one of the cases where the distinction of Protégé as a relationship modelling tool rather than a diagramming tool is most evident, i.e. it wasn’t really designed for this sort of case. 
 
For anyone reading this not sure what we’re talking about, if you create a static architecture diagram for Application A with all the applications depending on it, and all the applications it depends upon, then Protégé will capture those relationships. 

In the diagram, you may model Application C depends on Application A (the focus application) depends on Application X.  However, if you now move to Application X in Protégé and look at its static architecture model then Application A does not appear – as a result you may inadvertently redraw Application A in the static architecture of Application X  (i.e. Application A depends on Application X (the focus application)).  

In the repository we now have two relationships between Application A and Application X.  Whilst this is NOT incorrect - and thanks to our ‘usages’ concept, ensures that we are not creating duplicates of our applications in the repository - it can make managing the set of application dependencies more difficult. To get around this situation, we always recommend that you model the applications that the focus application depends on in its static architecture model.
 
The view could filter this out, however the underlying model would be wrong, which has knock-on impacts to other views, so the static architecture model requires careful modelling.  We’ve recognised that, in cases like this, pushing out the data capture to a wider audience can create issues, which our upcoming ‘everyone’s an architect’ data capture approach for Essential Cloud addresses.  Interestingly, due to the complexity in this modelling, this is the first one we’ve built.

Jonathan
Essential Project Team
Post Reply