Application Deployment Patterns

ArchiMate covers the standard three layers of enterprise architecture: business (products, business processes, business functions, business objects, roles, actors, etc.), application (application components, application functions, application services, data objects, etc.) and infrastructure (devices, nodes, networks, infrastructure services, artifacts), the infrastructure layer is often not seriously modeled, it just resides in the CMDB. But it can be and that can be very helpful to get the complexity of your environment in the picture.

Note: the content of this post has been superseded (amended and seriously 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.

In my observation, most practitioners of Enterprise Architecture tend to dwell more often in the upper layers of Enterprise Architecture and tend to restrict themselves to `global’ and `rough’ models. Details in Application Architecture are said to be `design’ and should be left to software designers. If Application Architecture is already a bridge too far, you can imagine what happens in the area of Infrastructure. Not much. It is the domain of even more remote hardware designers. Not something for enterprise architects, surely.

I think this is a a bit of `unknown makes unloved’ and a bit of fear for that where one does not have the experience. I also think that the often heard dichotomy between `architecture’ and `design’ is a false one. Enterprise Architecture is just another kind of design, overlapping with software design, organization design, hardware design. Enterprise Architecture is not only the upper layer, it is the alignment of business, application and infrastructure. It is also not just `rough’ or `global’ design. It is the art of knowing when details count and when they can be left out, all with the goal of steering on alignment and complexity reduction in mind. There is no separation of `architecture’ and `design’, there is a lot of overlap.

Anyway, to help people on their way in the often undervalued area of infrastructure, I am presenting here a series of application deployment patterns. Starting with the simplest: a single tier application running on a desktop system and moving up in complexity to three-tier applications, ASP’s and more.

Before I start with the first pattern, I’d like to explain a bit about the modeling choices we have made in the infrastructure layer:

• Infrastructure is modeled in such a way that each TI component needed for a system to run is expressed in an Infrastructure Service. These infrastructure services (which are called TI Building Blocks) are then aggregated into a single Infrastructure Service. It is on this Infrastructure Service the IT organization can deliver a Service Level Agreement (SLA).
• We generally model the interlayer relations between passive structure (artifacts, data objects, business objects) and behaviour (infrastructure service, application function, application service, business process/function). As the behavioural link closely matches the active structure link, the active structure interlayer links (e.g. from Application Interface to Business Role) are not really necessary to understand the landscape. And we start from the behaviour anyway (in the end, it is the behaviour that matters for results and not the structure, something that is true even outside of Enterprise Architecture as we all know)
• Our labeling of objects is generally in three parts:
  • A `grouping name’ in square brackets (TI is often named in the CMDB based on the node it resides on)
  • Some sort of description
  • A type in round brackets (this redundancy, especially, makes views easier to read for people not using ArchiMate every day)

Single Tier Application

Here is the first and most simple one: a system deployed on a desktop that accesses data on the desktop, like your desktop at home. This is not a pattern you expect to see often, especially not in large organizations. Organizations tend to shy away from this because of the troubles with support, backups, security, etc. (note: all images can be clicked to get a larger version):

And we note:

• We model hardware as a node that is comprised of the actual hardware (device) and the system software installed on it. We make a separation of the software that results in the Infrastructure Services (e.g. Windows or MS Excel) and the software that makes use of the Infrastructure services (in this case our `Application X’). The latter can be seen as an Artifact (not System Software) that realizes the software (Application Component) at the Application Architecture level.
• As there is only one Infrastructure Service in play to be used by the Application Function, there is no aggregation yet in this pattern. See next patterns for how that works.
• The distribution of Application X is an Artifact that resides on the desktop.
• The data of Application X is realized by the SomeFile.txt Artifact
• We do not model the way the constituents of the Node realize the Infrastructure Service. See below in a more complex pattern why.

Single tier Application with shared data

Having done the simple preliminary, we move to a slight extension: the same app, but with the data sitting on a network file share somewhere.

(image typo fixed on Nov 19) And we note:

• A file server has been added in the infrastructure. It provides the file share Infrastructure Service and it hosts the SomeFile.txt Artifact. The file share Infrastructure Service is used by the operating system of the desktop.
• As we now need two Infrastructure Services to run this application, we aggregate both `TI Bulding Blocks’ in the single aggregate service where the SLA is based on.
• This particular server has a Ctrl-M client for running batch jobs and so forth on it. Note: this (and any other) pattern is not an endorsement of any product mentioned.

Two tier: desktop application talking to database server

From the previous situation it is a small step to a desktop application that uses a database server instead of a file server for its data Artifacts:

And we note:

• It is not the desktop operating system anymore that uses the Infrastructure Service that provides access to the data, it is the Application Function. This is not drawn as we have decided not to draw the individual `Used-By’ relations between the Application Services and the constituent `TI Building Blocks’ of the aggregated Infrastructure Service. Via the Data Object and the Artifact, we can still find the dependency on the database server, though.
• We have modeled a bit of the complexities of an SQL Server setup. That is because instances of that system may function somewhat separately and if one doesn’t work, the other still might. Hence, if want to do analysis later on, the separation enables us to understand dependencies correctly.
• Here you see again that we model the Infrastructure Service as provided by the Node and not by the constituent System Software. Technically, you can also choose to let the system software realize this and that is even more correct (so you might choose to do it differently). But when a server provides multiple Infrastructure Services, the model can become pretty complex with all the relations and analysis also becomes more complex. And in our practice, it is enough to know what node is providing the service. I would suggest only to model it more precisely if there is a pressing need.

Shared application

A variant on the standard application is the application of which the distribution is shared: say it lives on a network share and is mounted by many desktops (or Citrix servers, which may take the place of a desktop in these patterns). This looks like this (example here is based on a two-tier application so you can see both the server for the data and the server for the distribution):

And we note:

• We could have shown this with a single tier as well, of course
• The distribution lives on the file share. The desktop mounts that file share to get access to the distribution. The execution of the distribution takes place on the desktop.
• The aggregated Infrastructure Service (the one where the SLA is based on) now has three components. To be able to use this application, the TI provider must provide the execution on the desktop, the file share with the application distribution and the database server.
• We have added some complexity to the database setup. Now there are two instances and two databases and two data objects and two business objects. This is just for fun.

Three tier application

Next up is the three tier application. Here, the heavy lifting application work is done on a server and not on the client. The client generally is light weight and might even only send requests to (and receive replies from) the application server and only be responsible for presentation. In the pattern below, there is still a client distributed on the desktop (maybe a Java app, with a .jar distribution Artifact and a Java System Software that acts as platform to run it on). In a later pattern we move to ASP/SaaS, where there only is System Software (e.g. MS Internet Explorer) installed on the client side.

And we note:

• The Data Object is not realized by the database as in the previous pattern, but by some Artifact (possibly in memory) on the application server. There is no direct link between client application and database server, even if the database server SLA-wise needs to be part of the aggregate Infrastructure Service that  makes using this application possible. It is the application server’s System X System Software that uses the database directly.
• Often products also have a database on the application server itself, saving application states, user information and such. This is not drawn here. But given the importance of stuff like backup and recovery, this should of course in real life be modeled.

`Three tier’ application with remove Application Server (ASP)

So far, all of our TI has been in-house. But there is no need for that. The application server (and the underlying data server) could as well be somewhere else. In fact, there are several services which are setup that way, e.g. Bloomberg investment management application support. Moving the application tier and data tier outside makes your internal landscape simpler of course. There is a price tag (as there should be) and there are limitations to the way the application sever and data server can be integrated with the rest of your landscape. It looks like this:

And we note:

• Life has become a lot simpler at our end. We just need to provide the desktop and (let’s not forget) the internet connection, but all the heavy lifting is done elsewhere.
• We now have two SLA’s. One for the desktop and the internet connection, provided by our own TI-provider, and one for the application server and everything behind it provided by the external provider.
• We could model the application server of the provider and let our application function use that one instead of the infrastructure service. That wold be correct, but it adds complexity without much use for us. In the end, the service provided for the business can be realized by the application function of the client application, even if the client application is just a thin shell only doing request/reply with the heavy lifting application server in the back. Modeling the application server in the application layer of our EA is only useful if we want to model the process for changing the software as well. As we cannot change the provider’s system, it is not that useful and it need not be modeled.
• We call this `three tier’, but in fact only the two top tiers are visible to us. It could in fact be called two tier. We call it `three tier’ because our client application does not perform all the heavy lifting itself and just talks to database server, it talks three-tier-style request-reply to the provider’s server as in the earlier three-tier pattern. But we do not know that or are certain in any way.

SaaS

It is only a small step from the previous ASP pattern to a SaaS solution that uses an internet browser as front end for the user. The main change is how we place the browser. If we see the  browser as a platform in which a provided HTML/Javascript Artifact is turned into an Application Component, the client application becomes a fickle on-the-fly affair, downloaded from the provider and run in a local (internet browser) sand box (And lo! There is no application distribution in our landscape as there should not  be in a SaaS solution! I am reminded here of Hannibal Smith). It looks like this:And we note:

• There is now no client application installed anymore on the desktop. There just is an internet browser (and possibly some plugins) needed.

And finally:

Providing your own SaaS (`Internal SaaS’)

Those `provider’s application servers’ may reside within your landscape of course, as we saw with the classic three tier application earlier. But instead of a client distribution on the desktop as with the normal three-tier, you may have an `Internal SaaS’, where you (as in the previous pattern) do not have actual client software installed on the system (there is a browser interface instead), but you do have the application server. This might look like this:And we note:

• As we provide the application server in house, the Infrastructure Interface it provides has become an TI Building Block that is part of the aggregated Infrastructure Service where the TI SLA is attached to.
• We do not need access to the internet, so that Infrastructure Service TI Building Block is not needed.
• The application server itself as modeled here is probably not all we need. We probably need more, like a data server etc.. In fact, when we extend the above picture to what is needed, it might look like this:and it becomes clear that there is more to that simple browser based application in your landscape than meets the eye of the user. In fact, that is one of the psychological disadvantages of `Internal SaaS’ from the IT organization’s perspective. There is a lot of structure needed behind the scenes to make it all work. And the business is generally surprised at the cost of all the TI involved.

There is of course a myriad of variations on these patterns. Like applications that access both shared files and a database. Or application servers that not only replies on requests, but that actually deliver parts of a solution in the form of shared libraries on the desktop which are updated without your knowledge or intervention (quite scary from a security perspective, but I know more than one provider of the `remote application server’ type that does this).

Finally, the TI-support for an application in these patterns runs from TI to the Application Function via Used-By (and from Application Function via Application Service to Business Process/Function). But a single Application Component may of course perform various Application Functions. If all these Application Functions need the same Infrastructure Services, it would be preferable to aggregate the various Application Functions in one big aggregate and let that aggregate Application Function use the aggregated Infrastructure Service (while letting the various Application Services still be realized by the separate Application (sub)Functions). But if one big Application Component provides Application Functions that serve wildly different Business Processes and those separate Application Functions require quite different Infrastructure Services (e.g. different databases or file servers, internet access or not, etc.), having two separate SLA’s for that one Application Component might be preferable so that the requirements (think for instance continuity) for one Infrastructure Service do not automatically mean other Infrastructure Services must be as expensive. As they say, YMMV, this is why you have a job as architect.

PDF’s of the above patterns can be downloaded so they can be printed large without becoming pixelated.