ECP-5 Skills modelling in Business Layer

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

ECP-5 will develop the requirements and meta model extensions to support the ability to capture and model Skills required by Business Roles and provided by Actors in the business layer.
Essential Project Team
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Requirements
I have a situation where I'd like to capture information related to the specific skills an Actor has associated with them (personally). e.g. John Smith has skills with Java 1.6 SE.

When I look at the Business metamodel at the conceptual level, Business Capabilities are defined and then related to Business Roles which are in turn filled by Actors. This allows us to define the capabilities a business role is expected to provide, but it doesn't tell us what skills an Actor can provide.

What I want to be able to describe a list of skills and then describe these for specific Actors, I don't see a way of achieving this in the model at the moment. I could create more detailed Business Capabilities and then link them to Actors, but this breaks the Conceptual/Logical/Physical partitioning of the model and seems like it is turning Business Capabilities into something they are not meant to be (I think).

What I was wondering is whether this type of information appropriate to be kept in this model? And if so, what the best way of modeling this would be? I can't see a way of capturing what I need in the current meta-model so I'm thinking it'd need to be expanded to suit what I'm looking for.

Of the top of my head, it seems to me that at the Logical level I could create a Business Skill class that then links to an Actor at the Physical level and up to a Business Capability at the Conceptual level. I think this would achieve the effect I'm looking for, but it'd be good to know any general thoughts on this approach (or others) and the validity of holding this type of information here in general.

Michael
(mjtapp)

First Proposal
I agree that trying to use Business Capability for this is stretching the semantics of that meta class too much. It's very important that each class has clear semantics. The Capabilities are intended to be used to capture WHAT the business does or needs to do. These are realised by the Processes and it feels like the skills are a different dimension.

If I understand your requirement correctly, we want to be able to define the skills that are required to perform a particular Business Role. Also, to capture the skills that a particular Actor (Group or Individual) has. Then we can use this information about the skills to make decisions on whether an Actor is actually able to perform a Business Role.

In this case, we can create relationships from Business Role and Actor to instances of the new Skill class. At this level, I think we want to be specific about the actual skills - even at the Logical, Business Role level. We can then report very easily on any skills mis-matches that might exist.
I'm trying to decide on where the Skills lives in the Business Layer. Feels like the logical view. We might also want to be able to 'semantically ground' these skills with a conceptual level skill. i.e. determine what TYPE of skills Java 1.6 SE is. Is this a development skill or a system admin skill. Doing so opens up some further reporting possibilities. Perhaps these Skill Type classes relate to Business Capabilities to let us define the types of skills that we will need to have in order to realise the capability. Again, more good reporting opportunities on skill gaps etc.

Jonathan
Essential Project Team
mjtapp
Posts: 19
Joined: 19 Aug 2009, 09:57

Thanks for the response Jonathan, I've drawn up a diagram that I think represents what you've described:
Business Skills.png
Skill Category: A type of skill that the business requires to provide it's capabilities e.g. Application Design
Skill: A specific skill that a Business Role may require to perform that role or which an Actor provides as part of their experience e.g. Rational Rose System Modeller

A couple of points:
- I changed the Skill Type to Skill Category to be consistent with Site
- At the risk of getting too detailed, it might be useful to hold information with a skill such as whether it is formal/certified or not
You do not have the required permissions to view the files attached to this post.
User avatar
jonathan.carter
Posts: 1087
Joined: 04 Feb 2009, 15:44

Hi Michael,

Thanks for posting back and confirming the requirement.
I've tweaked what you suggest a little and clarified some of the relationships between things like Process and Capability in the following class diagram.

I've gone back to Skill Type as I feel that what we're trying to do here is say that, e.g. Java SE skills is a type of development skill. I appreciate your thinking and it may have highlighted an in-consistency in the Site Category class name!
Image

Otherwise, I think we're really in agreement. I've added a new enumeration class (we have a number of these in the EA_Support area) which allows us to capture Skill Certifications, which are then an attribute of the Skill class. e.g. Java SE would have a Sun Certified Java Developer certification associated with it.

As I think that we are so close in terms of how this should work, I've put together a sample repository to test out how this works in practice. This doesn't include any reports yet but I've defined a couple of skills, certifications, skill types and linked them to the Roles and Actors.
See how this works for you and if you think of any other attributes or relationships that we might need, we can get them into the sample repository to test.

If you think that the extensions that I've introduced into the ECP-5 sample repository meet your requirements, I'll create a meta model update pack that you can apply to your project (which introduces these enhancements to your existing model without having to re-work or import existing data).

Look forward to your thoughts.

Jonathan
Essential Project Team
mjtapp
Posts: 19
Joined: 19 Aug 2009, 09:57

Thanks Jonathan,

That looks good. The only other thing that did occur to me as I was looking at the sample repository is that it may be useful to know how skilled a Role needs to be or an Actor is. In the current model you could split skills up into different levels to achieve this e.g. Java SE 1.6 Expert vs Java SE 1.6 Novice.
The other way I can see is to hang this type of information off the relationship between Role/Skill & Actor/Skill. I'm not sure which would be best, one is obviously simpler than the other, but also potentially more repetative.

Apart from that I can't think of anything else so I'll wait for the update script :).

Thanks

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

That makes sense. We would create a relationship class that we can use between Actors and Skills and also between Roles and Skills. On this class we can capture properties such as the skill level (another enumeration, I think) and perhaps other things to do with things like their experience.

I'll have a look at that today

Jonathan
Essential Project Team
mjtapp
Posts: 19
Joined: 19 Aug 2009, 09:57

Thanks Jonathan, sounds good.

Michael
sarah.smith
Posts: 56
Joined: 04 Feb 2009, 15:44

A few words of caution about making sure that this doesn't become too complex.

It is not too hard to add this extra information. In order to make it available, however, the relationship is no longer a simple connection between e.g. an Actor and a Skill. Now, you need to also define the instances of a relationship class, which is an additional step to the definition of the relationship, slightly more than just directly relating them. It also makes reporting slightly more complex, although again, not too much to worry about.

It would be good to understand if this extra information is likely to be a very rarely-used nice-to-have feature or whether capturing the qualities of the relationship is going to be an important feature of this release.

Having used these types of relationships before I know it can be 'annoying' to have to keep adding them if the qualities are then never used, or what the relationship classes do are not fully understood. Obviously, the flip-side is that if you need attributes / properties / qualities on your relationship, then you need them and without them the tool is less useful.

Having said all that, I would be interested to get your views on whether you think the qualities of the relationship are something that we are likely to need or whether they are a bit ‘bells and whistles’. If they are likely to be needed, then we should introduce it now, as refactoring it later will be a little more complex.

Look forward to hearing your views.

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

Good points, Sarah.

The key point is if we think we'll need to add qualities to the relationships to Skills, then we should do this now. But, to keep things as easy-to-use as possible, we should be confident about the potential for that requirement rather than adding it just in case we might need it one day.

We do have a number of these relationship classes in the meta model already - in this context the Actor-to-Role relation is an example.

Just to be clear - either approach is simple to implement in the tools. We're just looking to make this easy to use but with all the required capabilities.

What do you think, Michael?
Is the ability to qualify how a skill is provided by an Actor or required by a Role (potentially with a range of attributes to that 'how') something that you think could become quite commonly used? And therefore well worth the additional work for anyone capturing such relationships?

Thanks

Jonathan
Essential Project Team
mjtapp
Posts: 19
Joined: 19 Aug 2009, 09:57

Hi Jonathan,

Sarah's points are pretty much what I had in the back of my mind when I've been thinking about this. I think there is a danger of getting drawn into setting up the model to capture all sorts of information that causes it to become less about architecture and more about something else e.g. An HR database in the case of skills.

I think the trick is to focus on the 'Essential' bit and keep questioning if you're crossing over into something that would be better kept in a specialised system of some kind.

Coming back to the issue at hand, I do think that skills are a useful thing to tie into capabilities and for the work I'm doing, I know it would be useful to be able capture how skilled someone is as well. I also realise though that capturing that level of information is getting close to something that might be captured in more of an HR system for many organisations.

So to answer the question 'Do I think it would be commonly used?', I think my inclination is towards keeping things simple and keeping the responsibilites of the EA model clear. This means that although the specific information I'm trying to capture at the moment would most likely be best captured in the relationship we're talking about, I guess I'm hesitant to suggest that it is an 'Essential' part of the generic model. Does that make sense?

I realise I haven't really answered the question, but to my mind what we are discussing is a bit of a grey area that essentially asks the question of where do you put the boundary of the business model in terms of what you capture. In this instance I'm happy to extend it for my specific needs or set up the skills as I suggested in the interests of keeping the model simpler (if this is what we decide is best).

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

Hi Michael,

Thanks very much for the feedback. Excellent stuff.
You are absolutely right about the issue of where to draw the boundary being balanced against what you need to be able to understand. In this particular case, it could be that setting up some sort of synchronisation with the relevant information that is authored and managed in the HR system would be appropriate - we've done similar things in the physical technology domain with configuration management systems.

So, I think the bottom line here is that we add the relationship class and use it for the relationships between the Skills and Roles and Skills and Actors. Each relationship will be a new instance of this relationship class and then in reporting, we would compare these instances, e.g. looking for mis-match of skills provided by an Actor to play a Role.

Here is the updated meta model.
Image
I will publish an update of the ECP Sample repository later on today or maybe tomorrow so we can see how it all works. Then I'll produce the update package so that you can start using this.

Thanks again for your input

Jonathan
Essential Project Team
mjtapp
Posts: 19
Joined: 19 Aug 2009, 09:57

Thanks Jonathan,

No problem, it's great to have the opportunity to contribute :).

Regards

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

I've uploaded the new version of the ECP-5 meta model sample repository for testing and approval. This now includes the Skill Relationship classes so that we can capture qualities on the relationship to Skills, e.g. Skill Level.

Have a look at the 'J Jones' and the 'London IT Support Team' Actor instances to see the Actor-Skill relationship class in action. I've also added some Role-Skill relationships to the project. Also, you should be able to navigate to these from the new Skill class instances.

Jonathan
Essential Project Team
mjtapp
Posts: 19
Joined: 19 Aug 2009, 09:57

Hi Jonathan,

That looks good and will certainly meet my requirements now, I'll look forward to the upgrade script :).

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

Just a quick one to let you know that the Meta Model Update pack for ECP-5 is now available for download.

This update will apply all of the changes to implement the ECP-5 sample repository in your Essential Repository.

Download the ECP-5 Business Skill Pack from the Share area.

I'd advise making a quick backup before running this script just in case. Or, if you're running using a file-based repository (PINS, PONT, PPRJ files) don't save until you've verified that the update has run successfully.

Jonathan
Essential Project Team
Post Reply