What makes division layer creation suitable while designing ECS
How do we decide if a Division layer will make sense? Eg: lets say ABC company is starting a project for its Cargo (goods transport) division. Would you build a Transport division layer & build its data model & integration in it? Or will you build it in Org layer itself (maybe in a separate Ruleset too)?
What factors should one consider in Div layer as FW vs Org layer as FW?
Pegasystems Inc.
US
Do not confuse "Division layer" with "Framework/Foundation Layer". A Framework layer is built on the layer that defines its scope. Would the Framework be used across the entire Enterprise or be specific to a Division? Note that Pega's Foundation applications are not Division-specific (how could they be?).
In the Lead System Architect course Organization-hierarchy Division specialization was defined as the situation where a Division develops Applications specific to that Division, i.e., no other Division would ever use them. Basically Division a namespace differentiator, similar to java's package naming convention.
Stepping back and looking at the aggregated ECS across the entire enterprise, a Division layer is optional, i.e., an application may or may not need one.
The same is true for a Framework/Foundaton layer, i.e., an Application may or may not need one.
If the Enterprise has an idea for a Framework/Foundation layer that can be specialized by different Divisions, I would not call that specialization layer a "Division layer". I would call it what it is.
It would be rare for an Enterprise Framework/Foundation app, specialized by Division, to be specialized again. If not specialized again, then call the Division specialization of the framework/foundation the "Production layer".
Do not confuse "Division layer" with "Framework/Foundation Layer". A Framework layer is built on the layer that defines its scope. Would the Framework be used across the entire Enterprise or be specific to a Division? Note that Pega's Foundation applications are not Division-specific (how could they be?).
In the Lead System Architect course Organization-hierarchy Division specialization was defined as the situation where a Division develops Applications specific to that Division, i.e., no other Division would ever use them. Basically Division a namespace differentiator, similar to java's package naming convention.
Stepping back and looking at the aggregated ECS across the entire enterprise, a Division layer is optional, i.e., an application may or may not need one.
The same is true for a Framework/Foundaton layer, i.e., an Application may or may not need one.
If the Enterprise has an idea for a Framework/Foundation layer that can be specialized by different Divisions, I would not call that specialization layer a "Division layer". I would call it what it is.
It would be rare for an Enterprise Framework/Foundation app, specialized by Division, to be specialized again. If not specialized again, then call the Division specialization of the framework/foundation the "Production layer".
Building a Framework/Foundation Layer on top of a Framework/Foundation Layer seems strange but is a possibility if the Framework/Foundation Layer being built on is either very generic or the Enterprise is very large - for example is world-wide.
Aaseya IT Services Pvt Ltd
IN
Thanks for the in-depth response PEDEL. My confusion is around how does it is work in case of an application where there is no fw & just the implementation layer exists (assume having fw is not making sense). Most of the times the applications are specific to a division - say building an application for Logistics division or a Planning division.In such a case, how does it matter if the division layer exists or not?
What I assumed (correct me if wrong) is division layer in such cases can work as reusable layer (for data model,integrations but not work- rules) for new implementation under same division. So Logistics division layer will help build Implementation 1 and in near future an Implementation 2. Assuming Data model and integrations are specific to division.
Thanks!
Pegasystems Inc.
US
The danger in saying "Most of the times the applications are specific to a division" is that silos of code would end up being created. Eventually the need to integrate will arise.
You do not have to use DIV in the class name. If an Enterprise Framework/Foundation Application was specialized by DIV, you could do that, but if the Division-specialized Application would always be hosted separately, then why bother?
A ruleset stack is a ruleset stack. The Application name, itself, is sufficient to tell one application from another. A Division-specific Application would include Division-specific rulesets at the top.
Back to your point, there is always code that can be used Enterprise-wide. From a case type perspective, reusable code is less frequent, but from a Data model perspective, definitely. The Enterprise logo, itself, is Org-level after all.
Even if you are developing an Application specific to a Division, allowance should be made to leverage code from an Enterprise layer. A Division is free define its own Division-specific reuse layer, but needs to be careful not to duplicate functionality defined at the Enterprise layer, or worse contradict it.
I would not call a Division-specific reuse layer a "Framework/Foundation" layer. To me a "Framework/Foundation" layer spans every case type for an application - it is the "Template/Blueprint/Model" for that application.
The danger in saying "Most of the times the applications are specific to a division" is that silos of code would end up being created. Eventually the need to integrate will arise.
You do not have to use DIV in the class name. If an Enterprise Framework/Foundation Application was specialized by DIV, you could do that, but if the Division-specialized Application would always be hosted separately, then why bother?
A ruleset stack is a ruleset stack. The Application name, itself, is sufficient to tell one application from another. A Division-specific Application would include Division-specific rulesets at the top.
Back to your point, there is always code that can be used Enterprise-wide. From a case type perspective, reusable code is less frequent, but from a Data model perspective, definitely. The Enterprise logo, itself, is Org-level after all.
Even if you are developing an Application specific to a Division, allowance should be made to leverage code from an Enterprise layer. A Division is free define its own Division-specific reuse layer, but needs to be careful not to duplicate functionality defined at the Enterprise layer, or worse contradict it.
I would not call a Division-specific reuse layer a "Framework/Foundation" layer. To me a "Framework/Foundation" layer spans every case type for an application - it is the "Template/Blueprint/Model" for that application.
Instead, a reuse layer, whether Enterprise or Division, should contain modular "Component" Applications that other Applications can be built on.
Aaseya IT Services Pvt Ltd
IN
Thanks a lot. That helped.
"You do not have to use DIV in the class name. If an Enterprise Framework/Foundation Application was specialized by DIV, you could do that, but if the Division-specialized Application would always be hosted separately, then why bother? " - Could you provide a use case where DIV is suited to be mentioned in the class name? As in Org-Div-AppName-Work fits the bill?
Regards,
Tanul
Pegasystems Inc.
US
When you use the New Application Wizard to specialize an Application by Division it automatically places the Div abbreviation after Org, plus has every case type it generates directly inherit the cases types defined in the Application being specialized.
You do not need to use the New Application Wizard to specialize an Application by way of ruleset specialization. This was mentioned in the LSA course (see copy/paste below).
Within the same development environment, though, you would end up saving cases to the same work pool table. This is what was meant by "hosted separately". You would not have that issue if your ruleset-specialized application ran in a completely separate environment.
8>< - - - - - Lead System Architect Designing for specialization - - - - ><8
When you use the New Application Wizard to specialize an Application by Division it automatically places the Div abbreviation after Org, plus has every case type it generates directly inherit the cases types defined in the Application being specialized.
You do not need to use the New Application Wizard to specialize an Application by way of ruleset specialization. This was mentioned in the LSA course (see copy/paste below).
Within the same development environment, though, you would end up saving cases to the same work pool table. This is what was meant by "hosted separately". You would not have that issue if your ruleset-specialized application ran in a completely separate environment.
8>< - - - - - Lead System Architect Designing for specialization - - - - ><8
Specializing an application by overriding rulesets
To create an application by overriding rulesets in the built-on application, do the following:
- Create a new ruleset using the Record Explorer.
- In the Create RuleSet Version form, select the Update my current Application to include the new version option.
- Copy the existing Application rule to the new ruleset and give the application a new name that represents its specialized purpose.
- Open the new Application rule.
- Configure the new application as built-on the original application.
- Remove every ruleset from the Application rulesets list except the ruleset you created in step 1.
- Open the original application again and remove the ruleset you created and added in step 1.
- Create new access groups that point to the new Application rule you created in steps 2 and 3.
A ruleset override application can be constructed without needing to run the New Application Wizard.
Aaseya IT Services Pvt Ltd
IN
"When you use the New Application Wizard to specialize an Application by Division it automatically places the Div abbreviation after Org, plus has every case type it generates directly inherit the cases types defined in the Application being specialized" - this is about how it is done. I do get "Specializing an application by overriding rulesets" as well.
I wish to know a real time business scenario where DIV in a class name i.e. Org-Div-AppName-Work will be appropriate. Will Alphabet-Google-SearchApp-Work be right structure? So google related branding,integration,data model goes in Alphabet-Google-Data/Int?
Example will help in understanding the answer better.
Thanks!
Pegasystems Inc.
US
Commercial Insurance involves the same type of data regardless the geopolitcal region, but the rules and regulations are different. A company may decide to establish a different Division for each geopolitical region. Note that Pega's Commerical Insurance Underwriting Foundation application supports multi-national Decision Strategies.
https://community.pega.com/knowledgebase/products/underwriting-insurance-commercial
Each geopolitical region would want its data stored separately. A customers may be on the boundary of a geopolitcal region. It may not be cost effective to host a different development environment for each geopolitcal region (the old fashioned way).
That's my best example :- )
Since you mentioned Google, having Kubernetes orchestrate containers could be another way to implement the "data stored separately" requirement.
https://cloud.google.com/kubernetes-engine/docs/concepts/multitenancy-overview