The Essential Project Forum

On the technology domain we have a Technology Component which is realized by a Technology Provider - and the relationship between the two has attributes held by the Technology Provider Role class.

The Application equivalents would seem to be Application Service being provided by Application Provider - but in this case there is no discrete class to hold the attributes of the relationship; no Application Service Provider Role class.

We think we feel the need for this as we attempt to exploit the licensing and contract classes. Frequently application software license terms are broken out by functional component: SAP HCM may have different license metrics than SAP BW, for example.

Have I overlooked some other, better, way of approaching this within the meta model?

Kevin

Hi Kevin,

Interesting question.
As a bit of background, the thinking behind the Technology Provider Role is to give us the ability to reflect how a particular Technology can be used in our architecture and define our current policies on a particular use. e.g. Oracle 10g as an RDBMS might be our production standard, whereas Oracle 10g as a J2EE Application Server might only be by exception only.

I don't think it's quite the same sort of thing going on with Application Services and Providers - where we've got a kind of relaxed SOA model. I say relaxed because we don't require that an Application Provider implements all of the Functions defined for an Application Service in order to 'provide' that service.

What you describe in terms of the different SAP components - and being able to manage the licensing terms for each separately - we would approach by defining separate Application Providers for SAP HR, SAP ERP, SAP BW etc. Exactly how you split them up - e.g. do you separate the modules of ERP (FI/CO, SD, MM etc.) - is a really a question of what level of detail you require in your repository.

By splitting each of these up as separate Application Providers, you will be able to define the individual license terms, potentially separate underlying Technology Architectures, the processes that these modules support separately and so on. However, to help manage these as 'SAP' we introduced the Application meta class to loosely gather these individual Application Providers together, e.g. when trying to find them in Viewer.

We've also used the Application meta class to group different implementations of an Application Provider. e.g. in scenario where a bespoke solution is lifted from one part of the organisation and further customised for use in another part of the organisation. We would model these two versions as separate Application Providers (they are now functionally different) but as they are known by the same name, group them with an Application of the name that they are both known by.

Let me know how you get on with approach

Jonathan

Jonathan

I think that will work - we'll give it a try. I've already found that I really need to create separate application software instances for each part of an application that is deployed to different technology nodes, and then list them all as deployed application instances within an application deployment. It's obviously going to lead to something of an instance proliferation though!

Kevin

Yes, it can do.

Protege scales very well, however, so it really just becomes an issue of finding the instances etc. Remember to use the Search drop downs when selecting / finding instances - these take normal wild card characters, e.g. * and work well.

It's all really an issue of detail - we're actually building a knowledge base about your organisation and we need to capture accurate information. But this is what gives us the power when it comes to delivering the Views and insights from them

Jonathan

A follow up thought on this topic.

Once we've separated the functional elements into distinct technology providers, we are then obligated to duplicate the technology build architectures, and obviously also the technology provider usage instances. While this is needed if the deployments are, or could be, separate it's a large overhead when everything is actually contained in the same deployment.

If the ERP had, say, 6 primary modules which we wished to model we're going to have to create 6 identical technology build architectures, which in turn will create 6 copies of all the technology provider usages. Rather than now modeling multiple module deployments sharing the same infrastructure software instances, we've expanded the number of infrastructure software instances by 6 as well. In every environment!

Have I missed an alternative approach?

Kevin

The intention with the Technology Builds is that they are logical templates that can be re-used. So, therefore, if each of your Application Modules requires the same technology architecture, then they can each be related to the same one.
I think it makes sense for, e.g. your Technology Architects to define the 'ERP Technology Architecture' that provides the platform on which you deploy all your ERP Application Provider components.

When it comes to the Physical architecture, then we might have separate instances of the components in ERP Technology Build for each module but we treat these as instances of the logical build, so there's no architecture diagram etc. to re-define. Rather, from the Technology Build Architecture, we can deploy the actual instances of each component to the physical nodes to meet the deployment requirements.
Note also, that it's only at the Application Deployment time that we relate the Application to a Technology Architecture (Technology Product Build) that describes the specific products that are used to realise that technology architecture.

Of course, if each of your Application modules requires different technology capabilities from the technical platform, then they might require different component architectures and therefore builds. However, I think that that is actually a technology architecture design decision. Your TAs might still design a single ERP Technology Build that provides the superset of technology capabilities for all of the Application modules in the ERP.
I think it's worth re-iterating that at the logical application view (Application Provider) we are defining relationships to Technology Component Architectures. That is, architectures that describe classes of technology as opposed to specific technology products. e.g. Relational Database Management System rather than Oracle 10g. Given that we're working at that level of abstraction with the technology, there should be more possibilities for these Application Modules to share a Technology Composite.

Perhaps it might help for me to lay out how some of the technology layer works as it relates to the Application Providers.

- An Application Provider can define a relationship to the implementing/supporting Technology. This is a relationship to a Technology Composite.

- A Technology Composite can have a defining architecture that describes logical Technology Components that are used. Note these are not specific products, yet. The Technology Composite also has relationships to a set of Technology Product Build Roles that define specific builds of Technology Products that can be used to realise the Composite. So that we can define builds that vary across e.g. deployment scenarios (Production, Test, Development), a Composite can have more than 1 Technology Product Build Role associated.

- The Technology Build Role defines a context in which a Technology Product Build can be used. i.e. that it is being used to implement the Technology Composite and we associate a "lifecycle status" to this build playing this role. That is, what is the standard/policy for this - strategic, waiver required, etc. This mirrors the Technology Product Role that defines how specific Products can be used in our enterprise.

- The Technology Product Build can have a defining architecture that lays out the products that are used and how they depend on each other in that build. When it comes to Physical Technology capture, it's usually easier to 'deploy' each product on the build architecture to the nodes just as they are in the physical world.

- It's at the Application Deployment (physical Application view) that we relate a deployment of an Application Provider to a specific Technology Product Build. So, for the test instance of our ERP, we would relate it to the Testing ERP Technology Build and the production deployments would be related to the Production ERP Technology Build.

Back to your question and scenario, I think how you relate the Applications to the Technology Builds is either a design decision (in a top-down scenario) or a matter of what the facts are (in a current-state capture, bottom-up scenario).
Application Providers can share Technology Builds - and that's definitely something that we've made provision for and from a purely architectural point of view, something that we would encourage. However, if in reality each module has a different Technology Build (different components, different capabilities provided, etc.) then if we don't capture each of these different Builds, we're losing information about the architecture.

From what you describe it sounds like you could define 1 Technology Composite that has a Technology Component Architecture that supports all 6 of your Application modules. This Technology Composite could then have just 1 Technology Product Build that describes the products that we will use to realise the build for our Application modules. e.g. 1 each of the following:

• ERP Technology Platform (Technology Composite)
• ERP Technology Platform Architecture (Technology Component Architecture, related to the Technology Component)
• Production ERP Build as ERP Technology Platform (Technology Product Build Role, related to the Technology Composite as an realising product)
• Production ERP Build (Technology Product Build, related to the above Product Build Role)
• Production ERP Build Architecture (Technology Product Build Architecture, related to the Product Build)

This defines our Technology Architecture.
In the Application modules, we can then relate each of them to the ERP Technology Platform and this tells us that they all share the same Logical Technology Architecture. Remember we can still be specific about differences in supporting products etc. when it comes to the deployments of these modules (Application Physical).

To complete the picture and to make sure that the out-of-the-box Application Module Summary view works to its best, define the set of Technology Capabilities that each Application Module requires. This is a simple, direct relationship to the capabilities. These should at least cover the capabilities that the components in your ERP Technology Platform provide and if you have other technology capabilities that are required but are not provided by your defined platform, the Application Summary view will demonstrate this and then you can review your technology architecture to address these requirements.

Hopefully this reply helps explain how the Application and Technology layers are connected but I hope it hasn't gone into too much detail. The bottom line is that from what you've described, you can define 1 logical technology build and have the 6 applications share it.

Jonathan

Thanks for the helpful explanation. The one piece I'm not quite clear on is the role of the Technology_Build_Architecture. It appears as if I must create several of these to support the dev, test and production environments?

In our case we have ERP modules deployed to two countries, with three environments for each - 6 ERP Instances effectively. I suspect that I'm going to need to have 6 Technology Build Architecture instances in this case? Will that in turn mean multiple instances of the Technology Provider Usage, named slightly differently for each of the component instances in each of the builds?

Kevin

The Technology Product Build can be treated as a 'black box', which means you create the definition of it in the form but do not describe how it works inside.

In terms of how this works in Protege, it's the Technology Product Build Architecture that has the graphical model, the Build is just a normal form.

So, depending on how much detail you want/need to go into, you can just define the 3 Technology Product Builds for Production, Development and Test. Alternatively, if you want/need to capture how these 3 builds differ (maybe you run on different specification of server) then you need to define the Architecture for each of these Builds.

In terms of what you've described, if you 2 countries are 2 deployments of the same 3 environments, then in the Logical view, you only need to create the 3 Technology Product Builds (and their architectures, if you need that detail) - Production, Test, Development.

At the Physical view (which is where we define the deployments of technology), you define the relevant servers that are deployed in each country (as Technology Nodes). To capture how the technology is deployed, we do need the Technology Product Build Architectures and from each of these, we 'deploy' each usage in the architecture to the relevant Nodes - normally as Infrastructure Technology Instances.
This might sound like a lot of work, but it's actually not that time consuming and it is by being this specific that we can clearly understand how the technology architectures are 'realised'.
The tools cannot 'generate' the physical model for you because there are so many deployment decisions that could be made by the TAs, but by 'deploying' the components from the Technology Product Build Architecture, you are using the build specification to guide you in the deployment modelling.

Another thought here is that we've been talking about Technology architecture here. Your ERP modules from the Application layer are your configurations of an ERP package solution (e.g. SAP). In this case, your configurations are the Application Providers, but the SAP software (what you install from the DVD before configuration) is a Technology Product that will form part of your TA.
The point about the Application architectures is that to capture the actual applications that people in your organisation are using, you need to model the Application Deployments - 3 of them, one for Production, Test and Development. From each deployment, you create 2 instances - 1 for each country that it's deployed in. This assumes that each country has a functionally equivalent 'copy' of the Application. If the behaviour is different between the 2 countries, then each country has it's own Application Provider. Note, though, that these 2 Applications can still share the same Technology Architecture!
You can be as coarse-grain or as detailed as you need to be with the Application Deployments to Technology infrastructure. It all depends on the detail you require. e.g. you can 'deploy' an instance of your application as a single Application instance on a single server. Alternatively, if you need to show how an application operates as a distributed system, you can define the relevant software components of that distributed system and deploy them across the relevant servers (and define the dependencies between each.

On the Technology Provider Usages, don't worry about how many of these you have. The point of these is that each captures the contextual information about how that Provider is being used in the context of a particular architecture. So the relationships that are defined between Technology Providers are between the usages of the Providers NOT the Providers themselves because this is only the case in the context of that architecture (Build). Consequently, if you have a lot of architectures (builds) you will create a lot of usages. However, there is no management of these usages that is required as such. They merely represent a link between the Technology Provider (normally a technology Product) and the architecture (Technology Product Build Architecture) and the tools look after them for you.

Apologies if you already understand all this but creating a usage is just a matter of dragging the required icon onto the architecture canvas. Once you've got it there, you can 'open it up' and wire it up to the Technology Product that you're using. And that's it. The only thing to remember is that if you want to delete an architecture, delete the usages first, using the 'X' button at the top right of the architecture canvas.

Hope this helps - and that I haven't muddied the water with the Application Deployment stuff.

Jonathan

I'm making some progress with our model. Here's the thought path thus far:

To model the license entitlements and deployments, we must have application providers modeled similarly to the structure of the license. If the license spells out an entitlement for FI, then FI must be an application provider.

If a module is used by one country, but the same functionality comes from a different application provider in another country, then I must have country specific Technology Product Builds.

Here's my current scenario: Country A uses AP, AR, GL from ERP provider. County B uses only GL from the ERP provider, and uses AP and GL from another application provider. Unless I split the technology build architectures an enquiry through the reports on the AR module will show deployments to both Country A and Country B infrastructure - because the provider usage is the same for both, because the fundamental platform is the same for both for the GL module, which they both use though on different hardware/software instances.

Is it the weekend yet?!

Kevin

Hi Kevin,

Sorry for not getting back to you sooner.

I think you're thinking on the right lines but I would just like to turn your statement about the licenses around!

Licenses can be applied to any element in the ontology. However, that means that to apply a license to specific 'part' of an element then you need to define those parts individually. e.g. as you say, if the licensing of a packaged application is managed at the 'module' level, then we need to define each of the modules individually. So, in the end, it's a question of granularity. Because we are building an ontology / knowledge base about our enterprise, we need to be explicit and clear about the elements in the enterprise. Whenever you find yourself trying relate something (e.g. a license) to part of something else (e.g. an Application Provider), then we need to go into more detail about that Application Provider to explicitly capture which parts. Any "it's sort of like this" is not going to work. And this is true across all of the elements of the meta model.

Back to your scenario.

If a module is used by one country but the same functionality comes from a different application provider in another country, that's 2 Application Providers that are required. The Technology Component Architectures (and the implementing Technology Product Builds) could be the same but, if the Application Providers are different (e.g. Oracle ERP in US, SAP mySAP ERP in Germany) then it's likely that the underlying Technology will be different.

In a packaged application scenario, in particular, the Application Providers represent specific configurations of the package. We represent the package itself as a Technology Product but our implementation of, e.g. SAP, is an Application Provider. If those Application Providers have the same behaviour - let's say that we have a standard configuration for SAP across the organisation - then we have 1 Application Provider for this. We then use the Application Deployments to define the US instance, the Germany instance of the same Application Provider.

But, if the Applications are based on different packages (e.g. Oracle and SAP), then even though the functionality might be considered the same, as you say, they are NOT the same because they have different technology platforms (1 is Oracle ERP, the other SAP).

So, there are number of different ways to capture this depending on the specifics of the scenario in terms of design of the application, deployments of it, the technology platforms etc.

Remember that Logical view is about design. Physical is about deployment of those designs.

Specifically on the scenario you describe - and hopefully the Essential Meta Model terms will help us get to the crux of this! - my interpretation of how you should model this to get the right results in the Views is:

Create:

• Application Providers for AP-ERP, AR-ERP, GL-ERP. Each of these depends on a Technology Composite that is linked to a Technology Product Build that includes your ERP Technology Product. This Technology Composite could just have a 'Packaged Application' Component.
• Application Providers AP-APP2, GL-APP2. Each of these depends on a Technology Composite that is linked to a Technology Product Build that includes your APP2 Technology Product, as above.
• You could then create an Application instance to group AP-ERP, AR-ERP and GL-ERP and call it something like 'ERP Application'. This helps people to find these components. I'm going to park composite applications for now, although a possible alternative approach.
• Now we can apply licenses to each of the individual Application Providers - 5 x licenses.

Now, when you view the Application Summary for any of these Application Providers, you'll only see the relevant technology for that Application Provider.

OK, so you'll have noticed that I haven't mentioned anything about the use of these Application Modules by the 2 Companies A and B. Again, going back to one of the first points I made, we need to be explicit about how these companies use the applications. We do this by defining Physical Business Processes. These can be really coarse-grain if we don't know much about the details, by the way, but it's with a Physical Business Process (which defines which part of the organisation - each Company in the 'Group' is captured as a Group Actor - is playing a role to perform a Process). Again, we can be coarse grain about this, so we could just define processes that describe the super set of all the finance processes and relate that to GL.

From this, we'll see that when Company B does these processes, they use 2 Application Providers - GL-ERP and GL-APP - in the Views. This might be fine but the Views will make this clear when we look at how the Processes are supported by Applications.

I've taken a bit of different tack here to look at how we relate the Physical Business elements to the Applications - which tells us who is using what Application to support them in specific processes. I appreciate that your focus might be on the technology, so let's get back to that - but one last word on this. To understand whether an Application is shared or whether there are different copies/variations of the same logical application we need to include some physical business elements.

In the approach I mentioned above, I defined 2 Technology Product Builds - 1 for each of the technology platforms of the packaged applications that the Companies are using. Each of these builds will include the Technology Product for the packaged application itself (effectively the contents of the DVD you buy from the software vendor), along with the other infrastructure software such as Relational Databases, servers, OS etc. However much detail that you require.

From what you've described, I'm going to assume that there are production deployments of AP-ERP, AR-ERP, GL-ERP that are used by Country A and Country B (for the GL). We'll also define deployments of AP-APP and GL-APP that are used by Country B.

The AP-ERP, AR-ERP and GL-ERP deployments can be related to the Technology Product Build for ERP that we've already defined. Similarly the AP-APP and GL-APP deployments.
To describe how these components are actually installed on the physical infrastructure from each deployment, we define instances that are installed on specific nodes. With each of these instances, we can define the specific physical relationships between this and other instances. e.g. that the application instance depends on DB1 but not DB2.
When we create the instances of GL-ERP we can ensure that there's just one that is shared between Country A and Country B OR we can create different instances deployed to Country A's servers and Country B's servers.

I think one of the tricky bits here is whether you separate the modules of ERP Provider into (sub) Application Providers or represent them as Software Components. I think the thing to remember here is that it's the Application Providers that support specific parts of the business, not the software components. However, from a licensing perspective, we might need to define the license elements at the software component level. It all depends on how your organisation works.

Hope this helps and doesn't just add confusion!

Jonathan

I think we've reached the same end state through some internal experiementattion.

We have created a Technology Composite to represent the ERP platform itself, with an associated Technology Component Architecture. We then have multiple Technology Product Builds representing each of our various enviornments (Dev, Test, Production), but with no regard to company or module. We've repeated this for each of the platforms supporting an application provider.

We have multiple, company specific, application deployments - each representing a company using an application provider (GL, AP etc) in an environment with the associated Technology Product Build.

This seems to work out pretty well. The one remaining limitation with regards to licensing concerns what quantity of an entitled license metric is consumed by each application deployment. Say for example we have a blanket entitlement of 500 users for SAP HCM, of which 350 are associated with the usage by legal entity 1, and 150 by the deployments associated with legal entity 2. Or it could be 40 CPU licenses for a database server, which are allocated to a number of infrastructure software instances. We don't seem to be able to model the "consumption" of a license entitlement by an instance without an associative class?

Thanks again!

Kevin

Great to hear that you're making progress.

In terms of capturing the details of the license, have you used the Contract class in the Cost Management area of EA_Support?
I think this is the class you are looking for and links the License with the thing that is being licensed and contains the various numbers that you'd expect (unit cost, number of units, overall deal cost). The idea with this one is to give the flexibility to capture all types of 'deal'/contract that you might encounter - from enterprise licenses to per-CPU or whatever. Indeed, it's possible to have multiple contracts on an element.

For some examples and further discussion of how this relates to the License class, have a look at the ECP-1 topic. There's also an example Protege project repository to download and review that includes some examples.

Apologies, I should have pointed this out before, but the intention of the License class is to capture 'types' of license that are used in building a contract to use an element. The contract brings the legal terms of the license together with the financial and other aspects.

Jonathan