I would consider building a framework layer leveraging the assets of Application 1.  You would then do the vast majority of your development work in your new Framework.  Only those functionalities that are specific to a single implementation layer would be built in the implementation layer.

If you are saying that you need to build common functionality at the Division layer rather than the Enterprise layer, then you could opt for built on applications to the Division application.

Could you provide an example of your use case?  This might allow me to be more specific with my suggestion.

This sounds to me like a classic Pega framework to implementation layer solution.

If you have not yet built your application, when you run the New Application wizard, specify that you want a framework and an implementation layer.  You should then get the structure you desire.  You would leverage the Org layer of the framework for Org level reuse and the Framework organization would include only an Org and a Division, leaving Unit set to the default value.

If you have already created your application and have created a fairly sizable number of assets, you could just build on to the existing application in the new application.  However, your class structure will not indicate the true nature of your current application being reused as a framework.  You would really have an implementation built on to another implementation.  I would avoid this if I could.

You can use the New Application wizard to build a framework only.  You could then alter the Built On application of Application 1 to point to this new framework and move rules meant for reuse into the framework from Application 1.

Hope this helps!  Please let me know if you have any add on questions or need clarification.

"Since 7.3  when running the New Application Wizard you cannot say to build both a Framework and Implementation application at the same time. You can only build one or the other."

This is true.  However, that does not mean that you can't build both.  You can.  In the advanced configuration, you can select one or the other.  My apologies for the misleading answer, but the point is the same.

"It is not necessary that every class name contain "-FW-" when defining a foundation for applications that specialize that foundation. You can construct that foundation layer various ways including leveraging multiple built-on applications and components."

Again, true, however the new application wizard will still use the FW construct when you select Framework and it is, therefore, still a recognized class naming convention.

The principles of my answer are still valid, semantics aside.  It still appears that a classic Pega Framework-Implementation construct would apply well here.  I don't see any arguments to the contrary.

I really appreciate you both looking into this. 

Here is my reference to the "Commons"

Common Business rules + Process = Common Custom Engine. 

So that we can build new applications on this Engine

Let me know if you need more details

One other thing, Santosh.

How soon do you expect to build upon Commons?  Is there any immediate need, a real need in the future, or just he possibility of the need?

There is a real need for us to build the applications on Commons.

For now would like to start of with Application 1 and in next 6 months start working on Application 2.

It is possible to start working on Application 1 and later "spin off" the Commons layer underneath it.

"Later" means when you are ready to start developing Application 2. 

You can do this by using the ruleset override / application-wrapper approach described in the 7.3/7.4 course.

While developing Application 1 you must always be on the lookout for functionality that is specific to Application 1.

When you see such functionality code it into new rulesets added to the top of the application stack. 

Eventually you want Application 1 to only contain those new rulesets and be built on a "Commons" application.

The Commons application's rulesets should only contain code generic to any application that is built on it, e.g., Application 1, Application 2, etc.

Application 2 can use direct inheritance for cases types.  But if you are going to deploy Application 2 to a different database anyway, then you continue to use ruleset-based specialization for Application 2.

Lee - To your point, as stated by Mike I feel that building the "Commons" sound like a fit. But I am still weighing on the optimal solution for this. 

One way to do it is be proactive in filtering out the "Commons", this way we be able to build the "Claims Engine". This Claims Engine will have all the rules and process encompassing claims processing assets. 

After this Framework - Claims Engine is built, then incline towards building "Application 1".

Parallel to this "Application 1", I can let the other team to work on "Application 2"

From your post a while back it sounded like you only had one development team at the beginning so I suggested a way to get Application 1 going without have to wait for the Commons layer to be developed.

If you do have the resources to staff two separate teams that would be preferable.

What I described was a way to build one application at a time albeit having to be disciplined to keep commons code separate from Application 1 specific code.

When Application 2 comes along, by that time a separate Division COE tream would be absolutely necessary.

Time to market is faster. Use of developer resources is more efficient. But more discipline required.

Here is an update.

After doing some research, I feel the requirement meets the Multitenancy Model.

Build the commons in the "Implementation Layer" on PRPC Multitenancy and then Tenants on this layer.

Let me know if this makes sense.

Not trying to dodge your question, but the best way to seek Pega product purchase/licensing advice is to start by contacting the Pega Engagement Lead(s) and Practice Lead(s) associated to your current project(s) then take it from there.