Pattern Recognition With The Cookie Monster
[This post is dedicated to Marc Maloy, SVP Worldwide Sales at HireRight, just because he asked for it. It’s the story of objects from a decidedly human resource management (HRM) perspective. For you object modeling mavens, rest assured that my knowledge of this topic as it is applied to software engineering is a little more complete and sophisticated than the approach I’m using here to present these concepts to a broader audience — and forgive me my trespasses.]
I Am An Object
I am an object. I am a single instance of the PERSON object. Right now, our planet holds about 7 billion instances of the PERSON object, each of whom is uniquely identifiable, most reliably by specific biometric attributes. If you’re LinkedIn or Facebook, you’re really like to capture data on all 7 billion of these PERSONs, but from the HRM perspective for a specific organization, what we’re really interested in are those PERSONs, and those roles of PERSON (more below), which are related to doing the work of our organization.
When we model the HRM domain in objects with an eye on automating that domain (and there’s both art and science in doing this well and at the right level of granularity), there are large numbers of small objects. But the big, fat, important objects, the highest level objects which shape the domain and our view of it, are called object classes, and they include WORK UNIT, JOB, POSITION, WORK LOCATION, TOTAL COMPENSATION PLAN, KSAOC (my personal favorite) and about fifty more. I’m capitalizing these object names and using their official names from my licensed domain model, that licensees of my work will recognize them. But what matters isn’t their names but their definitions, characteristics, relationships and behaviors.
Objects Have Attributes
I have one to many attributes (i.e. characteristics or properties), as do all object instances. For PERSON, these might include date of birth (all gifts appreciated), height and weight (entirely my own business) , name (which becomes its own lower level object related to PERSON and, of course, we must think globally here, really everywhere when we’re modeling PERSON, so no anglo saxon first name/middle name/last name allowed), and ethnicity (this too becomes its own lower level object related to PERSON and, again thinking globally, this certainly won’t be governed by the US’s EEO possibilities). The correct set of attributes to model with the object class PERSON (versus one of the lower level objects in the PERSON object hierarchy) are those which are truly about me and not about the various roles I have played, am playing or might play with respect to any specific organization. Not surprisingly, many PERSON objects may have attributes and even attribute values in common, e.g. two PERSONs sharing a birthday date or name, which is why these types of attribute values make lousy unique identifiers. But these common patterns do present opportunities when we’re trying to automate PERSON objects.
Objects Have Methods
I also have one to many methods (i.e. behaviors or things I can do). I can express my date of birth in various formats, complain about my weight, change my name for various reasons, including pure whimsy, and deny my ethnicity. The methods associated with PERSON are those which apply to the attributes which are truly about me and not about the various roles I play with respect to any specific organization. Bringing together conceptually the attributes and their related methods into objects changes fundamentally how we now develop models of any subject matter domain or real world environment as the foundation for automation. No longer do we think about data as something separate from the methods, e.g. the business rules and real world actions, which capture, shape, validate, present, etc. that data, and without which that data is a useless lump.
Objects Have Relationships
Objects also have relationships. The Ron Wallace instance of the PERSON object and the Naomi Bloom instance of the PERSON object, assuming that both of us were of interest to a specific organization for some reason, are related by another, clearly lower level, object we’ll call MARITAL RELATIONSHIP. And that relationship object may also have one to many attributes (e.g. date of marriage, country under whose laws the marriage is governed, existence of a prenuptual agreement and so on) and one to many methods (e.g. like all other dates, date of marriage needs to know how to present itself in various formats, and the country under whose laws the marriage is governed — we’re talking here about the attribute and not the actual country — needs to know how to validate the combination of country and existence of a prenuptual agreement because some of these combinations may not be supported in governing law).
Are you with me so far? Because here’s where it really gets interesting. A single instance of the PERSON, i.e. a single physical person, may have multiple relationships to a specific organization at the same time. Some PERSONs may be PERSON DESIGNEEs, that is PERSONs who are eligible for something of value under the terms of a specific TOTAL COMPENSATION PLAN in which an enrolled EMPLOYEE (bear with me, and I’ll get to EMPLOYEE) has so designated them. Examples of person designee include your life insurance beneficiaries, your ex-wife’s claims under COBRA, and your designation of your 401K’s secondary beneficiary as your son (or you could leave it to your alma mater, so here we’re really talking about EXTERNAL ORG DESIGNEE, aka legal person).
At the same time, that particular instance of PERSON, i.e. that specific physical person, could be of interest to a specific organization because they have done work for them in the past, are doing work for them now, or might do work for them in the future. So, a single instance of PERSON, the Naomi instance, could be both a PERSON DESIGNEE (when you so designate me to get your life insurance) and be doing work for your firm (when you retain me as a VENDOR EMPLOYEE or hire me as an EMPLOYEE) at precisely the same time or serially. There’s a lot more to the PERSON object hierarchy, but for that you’ll have to cross my palms with silver.
Objects Have Life Cycles
Every object has a life cycle, which is really the life cycle of a typical instance of that object. With the PERSON objects (and there are a number of these, even more than are noted above), their life cycle is not under the organization’s control. All we can do is to dip into that lifecycle where it is relevant to the organization. Birth, educational experiences, marriage, medical adventures, and so many more PERSON lifecycle events only become known to the organization as that PERSON’s relationship to the organization makes them relevant. So we’re likely to know a lot more about EMPLOYEEs than we would about VENDOR EMPLOYEEs and even less about PERSON DESIGNEEs. All those lifecycle events occur, but we only recognize and address that ones that are relevant to the organization (which could be simply because of specific regulatory requirements).
But there are some objects, like JOB, POSITION, KSAOC and WORK UNIT, whose definition, attributes, methods, and lifecycle events are much more directly under the control of the organization. There may be relevant regulatory or contractual (and here I’m referring to labor contracts) constraints on how we define objects or on their lifecycles, but much of what goes on here relies on what the organization chooses to do. And there are considerable similarities in the lifecycles of these constructed objects: the organization conceives of the need for a new JOB, it determines the attribute values and methods for that JOB, it opens up that JOB for use by particular parts of the organization, and so on. When modeling the HRM domain, it becomes clear that the highest level object classes and many lower level objects fall into distinct groups — including person, external organization, constructed, event — whose object lifecycles are patterned by group. Knowing these patterns is one key to being able to automate these objects in more of a definitional than procedual way.
Objects Have Applicability
Now I know this is only supposed to be a brief introduction to the notion of objects, but I just wouldn’t be Naomi if I didn’t point out a few more of their important characteristics, especially those which have a profound impact on our attempts to automate them. First up, applicability. An object may have applicability to (i.e. may be relevant to or appropriate for) all the tenants in a multi-tenant environment (e.g. the object of geographic WORK LOCATIONs for the instances that begin with planet earth and work their way down to specific countries), to the activity of all tenants within a specific geography (e.g. the object of US Federal tax tables), to just the activity of a single tenant (e.g. the specific configuration that changes the terminology of employee to cast member for Walt Disney Company tenant, to just the activity of a single tenant defined by a particular JOB (e.g. a specific TOTAL COMPENSATION PLAN that belongs to the Walt Disney Company and which has been defined as only being applicable to the JOB of Mickey), and so forth. Thus, objects, whatever their internal attributes and methods, as well as whatever their relationships, must also be “wrapped” with their applicability rules. Please note that this is my personal term for encapsulating objects with their applicability and is absolutely not the correct technical term for this characteristics but which gives me a very clear mental picture of what’s happening). By the way, these applicability rules for objects are what govern their inheritance across and within tenants, but that’s a topic for another post.
Objects, With Their Applicability, Have Effective Dates
I wouldn’t be Naomi if I didn’t bring one of my favorite enterprise software architecture topics, effective-dating, into this post on objects. But then it’s so applicable. Objects change over time in terms of their overall structure, so not just changes in the data content of the attributes for a specific instance (which also change, but that’s much easier to handle). Their attributes themselves change as do their methods, e.g. when we rethink our concept of JOB to allow for a new grouping/family to support cross-organizational KSAOC analysis or when we change is some profound way (from say years of service to an accomplishment threshold) the eligibility criteria for a specific TOTAL COMPENSATION PLAN. Even more complex to automate, and even as their structures can change, so can the applicability rules for a given object. Following the “wrapper” mental image above, objects containing their attributes and methods, must first be wrapped with their applicability and then be given an outer wrapper with their beginning and ending (but it could be open-ended) effective dates.
Final Thoughts
I’ve barely scratched the surface of thinking about HRM in objects, but it’s a start. A much better introduction to the relevant concepts (and I so wish I knew this author, having “sold” so many of his books over the last 20 years) is “Object Technology: A Manager’s Guide” by Steven Taylor. But before you decide that none of this matters to you, please be advised that modern (so not all current but all modern) systems analysis is based on object thinking as are modern practices in software engineering. The best of HRM enterprise software is built, from the ground up, with at least logical models as an expression of the domain and, increasing, is built from the models themselves. So, if you plan to work with, help design or manage, evaluate or implement modern HRM enterprise software, then object models are you. The very good news is that object modeling is all about pattern recognition, and that’s an easily recognizable KSAOC to which the formality of object modeling can added. The bad news is that if you really don’t have the pattern recognition gene, you really can’t do this well.
Now back to work on my HRM object model musical to the music of Gilbert & Sullivan’s HMS Pinafore: “I am the very model of a modern major general.”