Sometimes you may not want models such as a Business Process or a Process Version. It is easy to delete such models in WSRR Studio. However, some parts of the WSRR Business Space rely on models being present, most notably the Chart Widget. If the Chart Widget cannot get the labels for a model type that should be in the GEP, it will error and not work.
Therefore I advise to make models you do not want abstract using WSRR Studio. This means they still exist, but users cannot make instances of them.
Extending the Business Capability and Capability Versions
The Business Capability and Capability Version models are there to describe services and their versions. It is possible to extend these models to create your own flavors of services and versions (for example a Component Service). However, if you look at the Governance Profile Validator (GPV) rules which control what should be on instances when transitions happen, you will see that these rules hard-code the names of all the Business Capability and Capability Version models in the GEP. The GPV rules do not say "anything that is a subclass of BC and CV", but explicitly specify all those subclasses. So if you add a new subclass, you must go through the GPV rules and add the type of this new subclass to every single GPV rule which talks about BC/CV types. This is time consuming.
Worse is that if you ever upgrade to a newer version of WSRR, you will have to redo all these changes to the GEP, and thus redo all the GPV changes.
A recommended approach is to use classifications to classify a Business Capability or Capability Version, to indicate it is the flavor of service that you want to. For example you can add a "Component" classification and classify a Service Version as a "Component", which means that it is a Component Service. This new classification can easily be added to a new GEP, and all the current GPV rules will still apply to the Service Version. You can also add new GPV rules specifically for things classified as "Component" if you need different behavior.
Adding classifications under the GEP systems
Given the above you would think you could add classifications anywhere. Indeed you can, however only the Environment classifications (that indicate which WSRR runtime something is for) actually need to be added to the GEP classifications. If you have your own classifications, it is recommended to add these to your very own classification system, rather than just add them somewhere inside the systems already provided with the GEP.
This is mostly to make migration to future versions easier; your own system is saved as a .emx file which can be easily copied into a newer GEP profile. Adding classifications to the GEP systems means you need to re-add all of them if you upgrade to a new version of the GEP.
Image from www.jetpens.com.