In a previous post, I wrote about modeling spreadsheets. In it, I described two methods of modeling these. I settled on modeling the Excel application not as an Application Component, but as an Infrastructure Service. That post laid the ground work for this one (so I advise reading it first). This post is about modeling the use of web sites and web applications.
Note: the content of this post has been superseded (amended and extended) by the content on this issue in my book Mastering ArchiMate. Follow this link to the book page (with downloadable PDF) for more information.
It is good to think about the reality of what happens when you use a web site. You start up your browser and you type in an URL, e.g.
The browser connects to the web server and loads a web page that the web server sends. What the web server sends is based on the URL, which is composed of three parts: a protocol identifier (e.g. https://), a domain name (e.g. archimatemusings.wordpress.com) and the request part (the rest of the URL, e.g. /wp-admin/post.php?post=99&action=edit&message=10).
And suppose the website contains materials that require a plugin of the web browser to run? Well, the browser is capable of loading this plugin. As a result, the browser can execute code that is written for it, e.g. Flash, Silverlight, Java, etc. (This of course, has security implications).
The question of course is: is it useful to model the state of affairs at this detailed level? In the previous post, about modeling spreadsheet use, my answer was a clear “yes”. Not modeling those ‘hidden’ spreadsheet applications is sloppy and it seriously undercuts the usability of your models for analysis. In this case, the situation is slightly different, though. The functionality remains inside the browser, if only because of security considerations. So, there will never be direct relations with other functions in your landscape. Modeling the on-the-fly objects may be the most correct way to do it, in terms of the uses of your models, you might do with less detail. What you at least do need to know is the dependency of the Business Process on the browser and its plugins and on the web server. I could personally live with a model without the passive and active objects and the Application Function that is performed by the on-the-fly Application Component. Then it would look like this:
If the web site needs the plugin, the direct Used-By relation between plugin and Application Service is there. If not, the Application Service still depends on it, as the plugin’s existence may influence (e.g. break) normal browser behaviour.
For me: when the web page functionality is really complex, so complex that it needs to be used by various different processes in your business, I would at least like to model the different functionalities (Application (sub)Functions). As an example, think of a complex web-based application where you also have stuff like access control of users and you need to model that separately because you want to show your auditors that you are in control.