Pragmatic Enterprise Architecture with a focus on ArchiMate

ArchiMate Patterns – Application Layer

For some reason, I can sit down and crack out a couple of hundred words for a weekly project update on a weekend, but never manage to find the time to put pen to paper fingers to keyboard, make the clickiky clackity noise and type something up for my ongoing (hah) ArchiMate 3.0.1 patterns and examples (aka nonsense). That said, it’s probably fear… you can’t get comms wrong, can you?

Anyways… without further ado, from my least favourite layer (sorry Business, ya bore me… yes, I know, EA is all about the business) to my… most… favourite layer, I guess?

Application!

First a quick run through of a (very) basic application pattern, followed up by a more detailed look at how I have modelled a recent Salesforce project.

Pattern

Application Component

An application component represents an encapsulation of application functionality aligned to implementation structure, which is modular and replaceable. It encapsulates its behavior and data, exposes services, and makes them available through interfaces.

An application component represents an interactive application which can be used to fulfil a purpose by the business. It may be realised by an “artifact” running on a PC, or it could be a distinct set of functionality supported by a web platform.

Application Function

An application function represents automated behavior that can be performed by an application component.

Application Data

Example 1: Side By Side

I thought it was worth just extrapolating the basic example out to show that a local application running on a desktop can be modelled using the same pattern as a web application running through a browser.

Example 2: Salesforce

For the last 9 months I have been involved in a large scale Salesforce implementation for a major charity. The following example shows how I used the basic ArchiMate Application pattern to model the Salesforce platform, and applications developed on that platform.

This example highlights the “CRM Application” which has been built within the Salesforce Org (also modelled as an Application Component). Each of the functions within the CRM application have then been highlighted, although in the project I am involved in, each of these functions then maps to a number of high level epics which break the functionality down to further granularity.

The Salesforce Org itself then provides a number of API’s used to interact with the applications and data deployed within the org. Finally, the Salesforce Data Loader is then modelled as another Application Component which is served by the Salesforce APIs.

Hopefully, if anyone stumbles upon these examples they will find them useful!