I confess: I’m a huge fan of business object layers. It’s my personal goal to plaster every platform and application in the SAP space with powerful, feature-rich and completely interoperable business object layers. This first instalment of my blog series about business object layers shines some light at the fundamental terms business object, entity, and business process.
What is a Business Object?
In case you haven’t worked with one before, please let me explain what a business object is.
Every business application system (e.g. the SAP Business Suite) contains a domain model of the business domain it supports. This means that a business application dealing, for example, with financials has a representation of the (more or less abstract) real-world objects of this particular domain such as financial records, creditors, debitors, invoices, ledgers, and so on.
Aspects of the representation: data and operations
One aspect of this representation is the data it needs to store in order to represent the real-world object. This part can be fairly detailed and break the representation down into several elements such as a document header, positions (perhaps even different types of positions), and so on. It also contains the relationships between both the object parts and objects. (Examples: object parts would be header and positions, related objects would be creditor, approver, account, cost center.) At the technical level, this is the application’s data model: the database tables in which all the object parts are stored.
The other aspect of the representation are the operations that can be performed on each object. For example, an invoice can be created, edited, checked, forwarded, rejected, approved, paid, cancelled, changed, archived, and so on. At a technical level, this is source code that manipulates database records or their counterparts in the application’s memory.
Fig.: Business Object
These two – data and operations – belong closely together. The operations contain the checks and business logic that guarantee that the data is always changed in a consistent way. Only in conjunction do the data and operations represent a real-world object in a meaningful way. Such a representation of a real-world object in an application system, consisting of data and operations, is called a business object. (Note: The data are normally called the attributes and the operations are called the methods of the business object.)
What is an entity?
Since we’re already in full swing defining and explaining terminology, let’s quickly cover the entity, which is a closely related notion. The terms business object and entity are frequently used interchangeably, but there are some subtle differences:
- While a business object may contain of several object parts with different structures and cardinalities which are stored in several database tables, one entity usually corresponds to exactly one database table. So it’s often right to say that a complex business object is composed of several entities.
- While a business object contains data and business logic, an entity is just data without business logic.
For completeness’ sake, I should mention that while most applications store their business objects and the entities of which they consist in the local database, some applications perform on remote business objects and entities, consuming data and ordering the execution of business object methods through remote interfaces such as web services or Remote Function Calls. This is a rising trends thanks to the widespread adoption of technology-independent standards such as SOAP and REST.
What is a business process?
Business Objects are one thing, but without a business process they would just lie there passively waiting for somebody to do something with them. This is where the business process comes into play: A business process is a procedure that consists of several steps that may be performed by one or several different users and the system. A business process may touch a number of different business objects along the way. Most steps involve executing a method of a business object.
Stable object, fleeting process
Now what’s important to understand is that in many business domains, the business processes change much faster than the business objects. Business objects such as customer, invoice, or material don’t change their structure frequently and are thus quite stable.
However, the processes around them change much more frequently:
- Many processes depend on the organizational structure, which in many companies is redone every year or so.
- People try to optimize work processes for various criteria (speed, safety, cost-effectiveness, you name it) all the time, resulting in rapidly changing business processes, while an invoice is an invoice is an invoice.
- New processes emerge in which different combinations of business objects are used: Somebody comes up with the idea that whenever some customer master data is changed, the contracts with this customer should undergo a four-eye approval process in a different organizational unit. Somebody else comes up with a new business process for notifying a sales representative about every invoice a customer has rejected.
Meanwhile, the business objects remain unchanged.
(By the way, the idea that business processes change frequently due to innovation and their dependency on changing variables such as organization while application cores are more stable is at the heart of SAP’s product philosophy for NetWeaver BPM, which externalizes those changing business processes to allow for flexibility and rapid adaptation at the process level while minimizing the impact on the application core in the ABAP backend system.)
Conclusion of part one
It’s clear that the business objects as the stable foundation of an ever-growing and ever-changing multitude of business processes, are the most valuable unit of reuse in a business application system.
Please bear with me, I’ve got to repeat this because it can’t be stressed enough: Business objects are the most valuable unit of reuse in a business application system. Consequently, exposing and consuming a business object for reuse should be very easy and well-supported by the infrastructure. This is what we’ll discuss in the series’ next instalment.
4 Comments
