Hi,
I'm currently looking to model some target state architecture options and one possibility involves SaaS options such as Salesforce.com. In particular I want to make the linkage, but maintain the separation between the product/service being provided by the service provider and the actual configured application that we would be using.
What I think though is that depending on how you think about something like salesforce.com, there could be a couple of different ways to do this in Essential I guess, so I'm looking for some guidance.
I think a specific offering from salesforce.com would be modelled as Technology_Product, and I think it is easy enough to make the linkages to Technology_Components & Technology_Capabilities.
And coming from the other direction and creating an Application_Provider for our companies specific implementation of, say their Sales Cloud offering, that makes sense, but linking this to the technology requires a Technology_Composite and this is where it doesn't quite make sense to me where a cloud service like salesforce.com is concerned because there isn't really a Technology_Composite involved I don't think, or perhaps I'm thinking about it wrong?
Another way I've thought of modelling this is to treat salesforce.com (or aspects of it) as a Software_Component and link the layers together like that, but that also doesn't feel quite right.
So, I'm wondering what is best practice for modelling SaaS in Essential?
Modelling SaaS
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
Great question!
There are certainly some options for how we can capture this but let's start by thinking about what it is that we are interested in capturing.
The idea with the Application Layer is that this is where we capture behaviour / functionality. This is what supports our processes. The Technology Layer captures the technology that is used to provide the platforms on which the applications depend.
However, as you have spotted we also have software components (within the application layer) but I would recommend using those when we are in situations where we actually have to manage those components in terms of things like where are they deployed, what technologies do they depend on etc.
With something like SaaS, we might not have to worry about the technology or the software, that's what we're buying in the service. However, there is an Application component (Application Provider) that we are using to support our processes, even if we are not hosting it in any way. We can give the Application Provider a name that reflects how it is known within the organisation. In practice this might just be "Salesforce" but it's certainly best to use the name that people would recognise rather than using some contrived (perhaps more accurate!) name. This Application Provider represents our configuration / how we use one or more Technology Products to deliver the functionality.
There are some attributes on the Application Provider to capture things like who is the supplier of this Application Provider ("Supplier", which we can use "SalesForce.com" for the value) and to classify the application ("Codebase Status", which we can use the 'Software as a Service') value in there.
This combination of capturing the supplier and codebase status might be enough to reflect what you need. However, if we do want to understand more about what
the technology is that is supporting our SaaS application, then we can define the relevant bits of the technology platform that supports the application, using Technology Components (e.g. "Business Application" or even "SaaS Business Application"). We would probably ignore - or most likely - be totally unaware of any of the other Technology Components that actually take part in how SalesForce works.
If we want to go into more technical detail about what's going on, we will need a deployment of our Application Provider and from there we can define and relate the specific Technology Product Build (a set of one or more Technology Products) that makes up the platform for e.g. our production environment. We do this at the deployment level because often different Technology Products are used in production deployments verses development or test environments.
How much we capture depends on what we need to understand. It may be that the Application Provider definition is sufficient for SaaS solutions but if we need to get into more detail about the technical platform for that application (whether it's SaaS or not) then we can use the Technology Composite (architecture of Technology Components) and the Technology Product Build (architecture of Technology Products) to capture that.
Jonathan
There are certainly some options for how we can capture this but let's start by thinking about what it is that we are interested in capturing.
The idea with the Application Layer is that this is where we capture behaviour / functionality. This is what supports our processes. The Technology Layer captures the technology that is used to provide the platforms on which the applications depend.
However, as you have spotted we also have software components (within the application layer) but I would recommend using those when we are in situations where we actually have to manage those components in terms of things like where are they deployed, what technologies do they depend on etc.
With something like SaaS, we might not have to worry about the technology or the software, that's what we're buying in the service. However, there is an Application component (Application Provider) that we are using to support our processes, even if we are not hosting it in any way. We can give the Application Provider a name that reflects how it is known within the organisation. In practice this might just be "Salesforce" but it's certainly best to use the name that people would recognise rather than using some contrived (perhaps more accurate!) name. This Application Provider represents our configuration / how we use one or more Technology Products to deliver the functionality.
There are some attributes on the Application Provider to capture things like who is the supplier of this Application Provider ("Supplier", which we can use "SalesForce.com" for the value) and to classify the application ("Codebase Status", which we can use the 'Software as a Service') value in there.
This combination of capturing the supplier and codebase status might be enough to reflect what you need. However, if we do want to understand more about what
the technology is that is supporting our SaaS application, then we can define the relevant bits of the technology platform that supports the application, using Technology Components (e.g. "Business Application" or even "SaaS Business Application"). We would probably ignore - or most likely - be totally unaware of any of the other Technology Components that actually take part in how SalesForce works.
If we want to go into more technical detail about what's going on, we will need a deployment of our Application Provider and from there we can define and relate the specific Technology Product Build (a set of one or more Technology Products) that makes up the platform for e.g. our production environment. We do this at the deployment level because often different Technology Products are used in production deployments verses development or test environments.
How much we capture depends on what we need to understand. It may be that the Application Provider definition is sufficient for SaaS solutions but if we need to get into more detail about the technical platform for that application (whether it's SaaS or not) then we can use the Technology Composite (architecture of Technology Components) and the Technology Product Build (architecture of Technology Products) to capture that.
Jonathan
Essential Project Team
Thanks Jonathan, that is very helpful, and consistent I think with what I thought was the right approach.
One thing I was trying to achieve was that logical separation between the implemented application (represented as the Application Provider) and specific SaaS product.
Salesforce.com is quite a good example because although we tend to think of it as a single platform, it is licensed as a set of different 'products' (i.e. configurations of functionality) and what I wanted to do was capture that a given Application Provider is based on 'product x' as provided by SaaS provider y (e.g. Service Cloud on Salesforce.com).
Although using supplier with Application Provider gets me part of the way there, it doesn't really help with this problem. I think that based on what you described you would need to use a Technology Component so you could make the link to the actual Technology Product.
In some ways it doesn't feel entirely right because as you said, with SaaS we're not really seeing the actual software component, but the way the Essential meta model is structured doesn't really give another option I think.
Michael
One thing I was trying to achieve was that logical separation between the implemented application (represented as the Application Provider) and specific SaaS product.
Salesforce.com is quite a good example because although we tend to think of it as a single platform, it is licensed as a set of different 'products' (i.e. configurations of functionality) and what I wanted to do was capture that a given Application Provider is based on 'product x' as provided by SaaS provider y (e.g. Service Cloud on Salesforce.com).
Although using supplier with Application Provider gets me part of the way there, it doesn't really help with this problem. I think that based on what you described you would need to use a Technology Component so you could make the link to the actual Technology Product.
In some ways it doesn't feel entirely right because as you said, with SaaS we're not really seeing the actual software component, but the way the Essential meta model is structured doesn't really give another option I think.
Michael
-
jonathan.carter
- Posts: 1087
- Joined: 04 Feb 2009, 15:44
The way I find works to make that distinction between an Application thing and a Technology thing is to think of the Application (in particular of a packaged application) as the specific configuration that is supporting our business. Parking SaaS for the moment, what we download from the vendor’s site (or buy on a CD!) is a Technology Product. When we configure it in any way to use as an application, that aspect is the Application Provider.
From what you’ve described here, I would model the components that you’re describing as Application Providers (e.g. Service Cloud, …). Are these how these apps are known in the organisation or are they actually referred to by other names? It’s always worth using the names that they are generally known by.
Even though we’re not physically deploying or managing any technology products, we are still using them and we can make the relationships between our Applications and our Technology Products via the Technology Component Architectures (that describe the set of types of technology that are required to support the application - Technology Composite) and the Technology Product Build Architecture (that describes the suite of relevant products that are supporting each Application Deployment (e.g. Production environment, test environment etc.) - Technology Product Build).
The idea with the Technology Product Builds is that these logically define the set of products that are being used and these can be re-used by multiple applications. So, for each of the Application Providers we have that are based on Sales Force, we can re-use the, e.g. Sales Force Technology Product Build, to describe the technology that’s being used. Alternatively, we can define separate builds for the different Sales Force products that are being used. That’s a modelling choice to make.
You will notice that the Technology Product Build is associated with the Physical layer Application elements rather than the Application Provider. This is because different products might be being used in the production environment compared to the development or test environment for our Application Provider (we see this a lot!) but with something like SaaS this might be the same build re-used by all deployments and focussing on the ‘packaged application products’ rather than any of the technology infrastructure (which is less important for SaaS).
Hope this helps
Jonathan
From what you’ve described here, I would model the components that you’re describing as Application Providers (e.g. Service Cloud, …). Are these how these apps are known in the organisation or are they actually referred to by other names? It’s always worth using the names that they are generally known by.
Even though we’re not physically deploying or managing any technology products, we are still using them and we can make the relationships between our Applications and our Technology Products via the Technology Component Architectures (that describe the set of types of technology that are required to support the application - Technology Composite) and the Technology Product Build Architecture (that describes the suite of relevant products that are supporting each Application Deployment (e.g. Production environment, test environment etc.) - Technology Product Build).
The idea with the Technology Product Builds is that these logically define the set of products that are being used and these can be re-used by multiple applications. So, for each of the Application Providers we have that are based on Sales Force, we can re-use the, e.g. Sales Force Technology Product Build, to describe the technology that’s being used. Alternatively, we can define separate builds for the different Sales Force products that are being used. That’s a modelling choice to make.
You will notice that the Technology Product Build is associated with the Physical layer Application elements rather than the Application Provider. This is because different products might be being used in the production environment compared to the development or test environment for our Application Provider (we see this a lot!) but with something like SaaS this might be the same build re-used by all deployments and focussing on the ‘packaged application products’ rather than any of the technology infrastructure (which is less important for SaaS).
Hope this helps
Jonathan
Essential Project Team
