Application layer vs Information layer

Post Reply
bbain
Posts: 18
Joined: 11 Jul 2012, 13:05

Hi there,

I work for a Police Service and we are trying to map out our Business processes, software we use, and data within that software, mostly as it pertains to employee information (payroll, recruitment, KSAs, time & attendance, scheduling, etc.) with a goal to reduce redundancy and integrate the software applications. We are struggling with where to enter the information within Protege.

How is the Application layer connected to the Information layer? And where is the preferred place to enter database names e.g. 'Oracle HR database, Firstclass Email' - within the Application or Information layers?

Scenario: A number of applications/databases use the data element Person_ID, but they call it different names e.g. EmplID, Username, OperatorID. How do we map the Task, and Software application to the data element? Which layer would contain the software application, and which the data element?

Thanks,
Bev
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

The Application Layer is all about behaviour. What is the functionality that is being provided?

We capture the actual systems that we know in our architecture using the Application Provider class. So, we'd create an Application Provider instance for your Oracle HR system and one for your FirstClass Email system. Note that these represent YOUR configuration of these Technology Products to provide the specific behaviour in your organisation. We recommend that you name these according to how they are know in the organisation rather than just the name of the product that it is based on - whilst recognising that in some cases these are the same names!

I'll park any further discussion of the whole Application / Technology thing just now and focus on your question about Application and Information.

In terms of the databases themselves, we capture those as Information Stores (which could be things other than databases as well) and we can describe the types of information that exists in each Information Store and even things like the organisational scope of the information and data in there. E.g. Oracle HR Database X contains Person data for department A, whilst Oracle HR Database Y contains Person data for department B.

We relate the Applications to the Information that they use (produce and consume) via the Uses Information field on the Application Provider class. This actually uses a relationship class that enables us to add additional contextual information about how the Application uses the Information (e.g. the CRUD) and in that context, what Data elements are used.

Note that we separate Information and Data and this works really nicely to support things like Master Data Management and other Information and Data Management activities. This forum post explains the "what is Information, what is Data" approach that we have taken.

In your scenario, we have a couple of options. Which one to use depends on what you mean by "call it different names". Where it is people (typically business users) who call the same Data element by different names, we can define Synonyms for that element to capture all the different terms by which it is known.

However, I think what you're describing is how the application knows the Person_ID element. In this case (the most common), we use our abstraction layers to model what the application means by, e.g. EmplID or Username. We do this in the logical information layer, using the Data Object / Data Object Attribute classes to capture the element as it 'should' be known in the Information Architecture and the Data Representation / Data Representation Attribute classes to capture what the specific applications are using and then relate the Representations to the Objects. Note the same principle applies to the Information View / Information Representation classes for Information things.

So, we might create a Data Object called Person_ID and then three Data Representations for each of EmplID, Username, OperatorID and relate each of these back to the Person_ID object.

As I mentioned before, we relate the Applications to the Information that they are consuming and / or providing. In the context of each of those relationships, we relate the Data elements that are being used in that context. This approach provides a lot of power in particular for accurately capturing what is going on, which gives us high fidelity in the model.

Don't forget that we can model all this at as coarse or as fine-grained as we need - we don't always need to get down to attribute level to provide a lot of value. It depends on your scenario.

Finally, you mention Software and this is managed as a part of the Application Layer, using the Software Component classes. Note that this is not about UML modelling the classes in the Application but provides a connection to the Technology that is supporting the Application Provider. In particular this can be important for distributed applications. What we capture is the main software elements or components - typically identified by what bits of software would you install. e.g. client component, server component and so on.

However, the key relationships are between the Application things, which are focussed on the behaviour of your systems (the functionality - what do they do?) which are then supported by a technology platform (in terms of hardware and software infrastructure technologies as well as packaged application technologies). Our applications might be completely home grown, in which case we might be more interested in capturing the software components or off-the-shelf products. In the case of application products, it is our configuration of that product that is the Application Provider.

Jonathan
Essential Project Team
bbain
Posts: 18
Joined: 11 Jul 2012, 13:05

Thank you,

That really helps to clarify how we will enter our information. Now we can begin!!

Thanks again.
bbain
Posts: 18
Joined: 11 Jul 2012, 13:05

Hi there,

I have another question...We have linked our applications (app provider) to our data objects very nicely and can see this in the Data Object Summary report in Essential Viewer under 'Systems Impacted'. (Application Provider -' Uses Information' - open Uses Information instance and complete the fields uncluding 'Specific Data Operated On' - open 'Specific Data Operated On' and link to Data Representation & Data Object, completing CRUD)

This report also shows 'Business Processes Impacted'. We have yet to figure out what links to make so that the applications are somehow linked to Business Processes.

Can you help??

Thanks,
Bev.
bbain
Posts: 18
Joined: 11 Jul 2012, 13:05

I have another question...in the Data Object Summary report, there is a section that shows which Business Processes that data object affects. We can't seem to find the link that will populate this part of the report.

We were able to link the Applications to the Data Object re: 'Uses Information' in the Application Provider and then drilling that down farther to the 'Specific Data Operated On'.

Where is the connection for the Business Process?

Thanks,
Bev.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi Bev,

Firstly, your first question about Application Providers impacting Processes:

Application Providers support Physical Processes (I will come back to these) via a relationship class called Application Provider Role, which enables us to understand what the Application Provider is being used as when supporting a particular process. e.g. OurGlobalSAP as a CRM System, supporting the CRM process. The Application Provider Role also gives us the ability to capture our strategic view / standards about how that Application Provider should be used. e.g. are we allowed to use OurGlobalSAP as a CRM System?

The Application Provider Role connects the Application Provider and an Application Service (e.g. CRM System, ERP System, etc. - 'types' of application). It also has the relationships to the Physical Processes that the role is supporting.

The Physical Process is found in the Physical View of the Business Layer and captures an actual Actor (team, department, individual, etc), playing a Role as they perform a process (as defined in the Business Logical layer using the Business Process class).

The actual definition of how that process works is defined in the logical Business Process, and so we can have multiple Physical Processes that realise a specific Business Process. Sometimes when we're modelling the processes bottom up - e.g. Current State Capture, we might not know the details of the logical Business Process, but that's fine. All we really need to get started is a name and, ideally, a description. We can come back to the rest as we discover it or need it. On the other hand, when doing a top-down design, we might not know all the Physical Processes, so we can again create 'placeholder' instances that just have a name and a coarse-grain Actor/Role combination in there.

The reports can then navigate all these specific details about how different teams might be using different applications to perform the same process (opportunity for application portfolio rationalisation) to display the higher level, logical roll-up of what is going on - but importantly, we have the specific details in the repository to draw upon for hi-fidelity reporting.

On your second question about Business Processes and data objects:
Processes don't directly work on data. Rather they operate on - or rather use - information things. It's a bit like the data is information as software is to applications, if that makes sense?

The concept we are using is that the Business Processes use Information that is provided by applications. We have a powerfully loose definition of what constitutes an application, which means that it doesn't have to be an IT or software thing (and who knows what sort of applications we'll be using in 5-10 years!). Perhaps stretching the common semantics for application, a paper form would be modelled as an Application Provider that captures or provides the information that goes into the fields of that form.

The Applications use and produce that information by operating on data - and you've already started using the Application Provider to Information Representation classes, from where as you've described you've related the Data that is being used in that context.

From the Physical Process Types (this includes both Physical Process and Physical Activity), there is a relationship to the Information that is being used. We typically create a new instance of the Physical Process to Application Provider to Information Representation relationship class. It might seem a bit subtle but all it is doing is capturing the what information, provided by which application is being used by the Actors performing that process. As I mentioned above, different physical teams or individuals might use Information from different sources in order to perform the same process and we need to understand this. The nice thing is, having captured your relevant Application Provider to Information Representation instances, you re-use these in the context of these new Physical Process to Application Provider to Information Representation relationships (which may have the data relationships captured too).

I'm pretty sure that this is the route that the Data Object Summary is using.

Just for completeness, there are simpler, logical relationships between Business Processes and Application Services and to the Information Views that are required. These can be particularly useful in top-down design - we often refer to these elements as 'pure design' but don't give us enough detail about the real teams, the real processes and the real systems - the implementation design - that we need to understand more accurately how the real data is being used, e.g. in support of Data Management activities.

It's a bit of an essay but I hope this helps answer your questions. Sounds like you are really getting into the modelling, which is great.

Jonathan
Essential Project Team
bbain
Posts: 18
Joined: 11 Jul 2012, 13:05

Thank you. Sorry it has taken a while to get back to you. All of what you said makes sense now that I have been using it for a while.

I am sure I will have more questions in the future!

Thanks again,
Bev.
Post Reply