Business objects and their tacit and explicit data
Business Object Defined
To set the groundwork for this entry, let me begin by offering a working definition of a “business object.” For my purposes, I am not using the object-oriented programming definition entirely, which is that a business object is an programming object that represents the business entity in the domain in which the program is designed to support. My definition includes this programming definition, but expands it a bit further. My definition: A business object is an entity within a business domain upon which work is performed and about which data is gathered.
For example, in the anti-money laundering business domain, a case, which supports the investigation of an anomaly raised by a detection system, would be a business object. A case, regardless of whether it is managed electronically or physically, will have certain data associated with it. For example: data about the account, data about the account holder, data listing account transactions, data describing the anomaly, data representing an investigators’ notes, data representing law enforcement’s involvement, etc. The case itself is the amalgam of these sets of data, and since a case may be comprised of electronic data, paper data, and the investigator’s own experience and knowledge, you can see why I think the programming definition of a business object has to be expanded.
Working with the Definition
Let’s stick the example of the “case” for a bit longer. If we consider the data I listed in the example: account, holder, transactions, anomaly, investigators’ notes, etc., it will become apparent that there are multiple sources for this data. The account data, account holder data, and transactions will come from a core banking system, but will likely come from different modules within the core system. (Think silos.) Data on the anomaly will come from a money-laundering/fraud detection system. Depending on the organization’s environment, the investigators’ notes may come from some sort of collaboration tool, or it may come in the form of paper. Being necessarily external, law enforcement actions would be in a completely different organization, let alone system. (Note to practitioners: I acknowledge law enforcement does not typically provide feedback, but for the sake of illustration of a concept, let’s pretend they do.)
As I describe in an earlier blog post, one of the major goals of an Enterprise 2.0 architecture is to break down silos. A portal environment can go a long way toward aggregating data from disparate sources. So in our example of the case, using Web services, APIs, or an ESB, et. al., the data from the electronic systems can be pulled into a portal page and serve as a representation of the case being worked on. This goes a long way toward an accurate representation of the case business object; however, it excludes the other data from our example–that is the investigators’ notes and law enforcement actions.
At this point, it is useful to differentiate between two types of data: tacit and explicit. Explicit data is that data which is stored in and relatively easily retrieved from databases. Tacit data is that data which is outside of electronic systems, likely stored in a human or on paper, and typically much more difficult to retrieve.
A More Accurate Representation of a Business Object
So what would it take to capture the tacit data about a business object? By now it should be pretty apparent that my example is screaming for an implementation of social media functionality.
In my example of the case, micro-blogging by the primary investigator would allow easily recording of the current disposition of the investigation and the case. Enterprise content management would allow for the attachment of paper-based notes; appropriate references to laws, rules, and regulations; and news reports. Threaded discussions would allow for recording the interactions of the investigative team. Additionally, mobile access would allow for the update of the case records while not on premise.
The result of capturing this tacit data and representing it along with the explicit data leads to the most accurate representation of the business object.
The Takeaway
As a software professional, I am sometimes guilty of con-fusing software with the process with the object. I think it is an easy thing to do. Previously, while assuredly increasing efficiency, software made demands on the way business was conducted. If you wanted to work on a purchase order, the system demanded that you do it a certain way. The state of enterprise computing and the standards upon which it is based, now provides and alternative to this.
By implementing Enterprise 2.0 concepts, an organization can begin to be more agile and adaptable, and being able to accurately represent a business object and work on that object is an example of the power of Enterprise 2.0.
Filed under: Enterprise 2.0, KM, Technology | Leave a Comment
No Responses Yet to “Business objects and their tacit and explicit data”