View Full Version : What the flip is/are "business objects"
bigred
15th July 2005, 10:21 AM
In English please.
Frinkiak7
15th July 2005, 10:38 AM
In what context?
Business Objects is the name of a software package claimed by its developer to be able to improve any and all facets of a business. How, they don't really say. You have to spend money on licenses to find that out. It's yet another in a long line of products that allow upper management to appear productive without actually doing any work.
Or, is it a new corporate buzzword used to further obfuscate the internal workings of a company? You know, sort of the way that we're not "employees" anymore, but "resources"?
Bring on the dehumanizing of your workers so you don't feel such a twinge when you lay them off! Woo-hoo!
ETA: Am I too cynical? Or am I not cynical enough?
DickK
16th July 2005, 06:35 AM
Frinkiak7 is sort of right, but I detect some negative vibes there :D .
In my experience it is both the aforesaid package in its own right, permitting the definition of a semantic abstraction layer on databases, in order to provide a managed, consensual view of the data, and a general term for an object abstraction layer in packages like Siebel, maintaining things like referential integrity and managed extensibility. Siebel also integrates with Business Objects(tm), so it has both Business Objects (tm) and business objects. Apart from that, it don't mean a dang thang.
tkingdoll
16th July 2005, 06:57 AM
I sat through a very dull presentation by Business Objects last year, at a company I no longer work for.
In a nutshell, it's reporting software.
So if you need monitor your performance indicators and set service-level targets in a funky colourful useless graph, you can!
Oh wait, Excel does that too.
bigred
16th July 2005, 08:25 AM
lmao - thanks all, I believe you've answered my question quite well. Well except for DickK whose refused to use English and therefore I'm not sure
;)
Paul C. Anagnostopoulos
16th July 2005, 08:57 AM
DickK said:
In my experience it is both the aforesaid package in its own right, permitting the definition of a semantic abstraction layer on databases, in order to provide a managed, consensual view of the data, and a general term for an object abstraction layer in packages like Siebel, maintaining things like referential integrity and managed extensibility. Siebel also integrates with Business Objects(tm), so it has both Business Objects (tm) and business objects. Apart from that, it don't mean a dang thang.
Having trouble determining whether this is a load of BS or not ...
~~ Paul
bigred
16th July 2005, 10:55 AM
I think that was the goal. :cool:
epepke
17th July 2005, 02:38 AM
Originally posted by bigred
In English please.
Assuming you're not talking about a company or product called Business Objects, it's one of those buzzwords that make my teeth stand on edge. It comes from a 1990s tradition of how systems should be designed. All the word that have been used in this tradition are ugly and/or misleading, and it has been over-pseudo-formalized to a counterproductive degree.
The idea is reasonably sound, however. That is that different parts of the code should be kept somewhat separate, as it makes things easier to maintain. Assuming an object-oriented design (which is misleading, as most of these systems are more what I call class-oriented than object-oriented), there should be objects to control the database or file system, objects to interact with the user, and objects between them that do the actual logic of the program. The last group is called "business objects."
This is an ugly name, but it isn't as ugly as the names of the other layers, which are "persistence" and "presentation," except when the latter is "user interface." There are also "system" objects, which is kind of ugly and misleading but at least has a long history.
The persistence and presentation objects can talk to the system objects, but not the same subset of system objects (one of the ways that the metaphor breaks down.) The persistence and presentation objects should not talk to each other directly but only through business objects. The business objects should not talk to the system objects.
Take a spell checker on a word processor for example. The business objects hold all the structure of the document and will ask the persistence objects whether a word is in the dictionary. If it isn't, they will tell the presentation objects to put an irritating little red squiggle under the word, the one that appears every time you use a proper name.
bigred
17th July 2005, 12:16 PM
Originally posted by epepke
Assuming you're not talking about a company or product called Business Objects, it's one of those buzzwords that make my teeth stand on edge. It comes from a 1990s tradition of how systems should be designed. All the word that have been used in this tradition are ugly and/or misleading, and it has been over-pseudo-formalized to a counterproductive degree.
That was my initial impression, but I had to concede that could have easily been due to lack of undestanding.
Thanks.
PS I wish I worked with more people like you. :)
epepke
17th July 2005, 03:35 PM
Originally posted by bigred
PS I wish I worked with more people like you. :)
Well, is your company hiring? I could really use a job. I'm not getting much work consulting.
Wudang
18th July 2005, 03:39 AM
The concept of business objects can be useful in the right hands - for instance Ivar Jacobson's "The Object Advantage" is a pretty good book on the subject. Just like exercise is a very good idea but the ammount of BS that's accumulated from those looking to make a buck rather than address the problems is astounding.
bigred
18th July 2005, 06:47 AM
Originally posted by epepke
Well, is your company hiring? I could really use a job. I'm not getting much work consulting. No, sorry. :( Besides that would require you to move to Hampton Roads VA and I wouldn't wish that on my worst enemy. Well OK I would, but most other people I wouldn't.
DrMatt
18th July 2005, 10:20 AM
Lowercase "business objects" are the object-oriented software components which implement the main functionality of an N-tier application. On the one hand, they talk to data objects, which encapsulate the storage of data in databases; on the other hand, they talk to presentation objects, which encapsulate interacting with users. In between, they define the specific behavior which makes your applicatiion what it is. For instance, in Google Earth, the business objects include such functionality as "fly to a point of view now" and "plan a driving route", any of which makes multiple requests for appropriate geographical and picture data from the data objects which in turn work out the most efficient database query to satisfy those requests, and on the other hand attempts to present the output to the display objects which the end user can use to pan and fly through them.
Uppercase Business Objects, like Uppercase My Computer, Uppercase The Internet, Uppercase Chat, etc., are brand-name commercial products deliberately named after a generic, widely used standards, to make unwary customers feel like they need to buy the brand-name technology in order to benefit from the generic standards.
:D
pmurray
24th July 2005, 05:06 AM
It's the stuff that your system would have to have, even if you were implementing it manually as a set of formally defined processes involving, say, pencil and paper forms and post-it notes. You wouldn't have objects for "disk volume", "url" or "set of selected colums"; but you would still have "customer", "stock item" and "delivery".
a_unique_person
24th July 2005, 07:01 PM
Originally posted by epepke
Well, is your company hiring? I could really use a job. I'm not getting much work consulting.
I read in the paper recently, India is hiring.
epepke
24th July 2005, 10:03 PM
Originally posted by a_unique_person
I read in the paper recently, India is hiring.
I'd love to work in India, but it doesn't seem they're hiring the likes of me.
© 2001-2009, James Randi Educational Foundation. All Rights Reserved.
vBulletin® v3.7.7, Copyright ©2000-2012, Jelsoft Enterprises Ltd.