Application vs. technology - versions and lifecycle

Post Reply
NJC
Posts: 2
Joined: 29 May 2012, 06:03

Hi,

Did look around the forum but couldn't find an answer.

Looking to understand best way to model application technologies, e.g.

So if Siebel is the CRM system, where does the technology aspect of Siebel get modelled, e.g. that actual technology instance is say Siebel v7.8

Also is there a place that Vendor roadmap / support can be modelled, e.g. when does Siebel 7.8 go out of support, when did 8.0 go GA and go out of support, when did 8.1 go GA etc.

Thanks
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi,

The technology aspect of Siebel is modelled as an instance of the Technology Product class. As it's a business application, we can then create a Technology Product Role for Siebel 7.8 to map it to the 'Business Application' Technology Component and associate a Lifecycle Status to it to capture our architectural standards for the use of Siebel 7.8, e.g. 'Pilot', 'Production' and so on.

Note that each different version of a Technology Product is captured as a separate instance, e.g. we would create two instances for Siebel 7.8 and Siebel 8.0. We do this because each version can (and often does) have different dependencies, support different applications and so on.

We can relate the versions in a couple of ways. Firstly, we would create a Supplier instance for Siebel (or Oracle these days!) and relate both products to this supplier - and to make things easy to find in the repository, by default we include the supplier name in the fully-qualified name of the product.
Secondly, we can use the 'superseded version' field to relate Siebel 8.0 to Siebel 7.8 to show that version 8.0 has replaced 7.8 in our architecture.

In terms of the Vendor Roadmap, this is something that we have been thinking about for some time - as others have mentioned something like this too. It is not something that we have out of the box, currently but we have some strong ideas for how we would provide this capability.

I would like to use our community development process (ECP) to create this new feature. This works through the forums and need not take long but enables us to capture the requirements, suggest and develop the solution in an open way with our community. We'll provide an Essential Update Pack when we have devised the solution that will apply the new features to your repository using the Update Tab.

I'll kick of the ECP now and set out the first iteration of the requirements and our proposed solution and post back here with the link to that new topic.

Jonathan
Essential Project Team
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

I have now kicked off ECP-9, Lifecycle Model to collaboratively develop the required extensions to support the ability to capture, define and manage lifecycle models (including temporal elements) for any element in the repository

Jonathan
Essential Project Team
Post Reply