Will Business Object Layers Inherit the Earth? Part 1: What is a Business Object?
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.
how about clearing a possible confusion that a Business Object has never been a part of Business Objects? BTW, i like your bringing up the great existing SAP technologies. i have nothing against the newer ones, but it's hard to ignore the installed base.
wrestling with FIPP at the moment...
@greg_not_so (no tweet)
It's a good point. I deliberately decided against the title "Will Business Objects inherit the Earth" to avoid confusion with SAP BusinessObjects and used "Business Object Layers" instead - also "what is a BO" instead of "what are BOs" to avoid further confusion.
Is this enough in your opionion or do you have any suggestions as to on how else I should avoid this confusion?
Re: bringung up the great existing technologies, in the next part I plan to discuss BOR, BOL, CAF and some others. 🙂
Cheers,
Thorsten
your blog makes a great point here which I think too many people have overlooked in the recent past with all of the focus on SOA, design-time governance (via the Enterprise Service Repository), etc.!
Business Objects (or the equivalent in the non-SAP world) is really where a lot of the long-lived value of an IT system is, and the point of interfaces should be to expose this value in an efficient and effective manner.
I have been starting to think that as we have added layer upon layer on top of the fundamental constructs in a system (or architecture for that matter), we have focused on building reuse at each and every one of these layers. Witness Enterprise Services with all their well-defined and governed complexity trying to be all things to all consumers and aiming to be the 'single interface' into a particular function.
Because we have tried to make these higher layers reusable, they have grown too complex to enable the rapid change many business processes demand. We have invested lots in designing for reuse at these higher levels, only to find that the business requirements changed and we never got any return on that big design investment!
I am reading your blog as a call to return to the basics and reconsider which parts of an architecture hold truly reusable and constant value, and which parts should be as flexible and adaptable as possible, and I wholeheartedly agree!
Call it confirmation bias, but I am going to interpret this as something which is well suited to the RESTful approach to integration:
Build as many interfaces as you need to meet particular use cases flexibly, and be prepared to throw them away when things change; and instead focus on reusing your real information assets 'under the hood'!
OK, I'll stop now 🙂
Well done with the blog (again)!
Sascha