Wat is Object Orientation?
What you see is what you get
Object-oriented system establishment represents an approach to the establishment of business systems wherein the system decomposition is grounded in the concept of an object.
An object serves as a fundamental building block within Business Systems, Application Systems, and the Operating Environment. Objects essentially represent the noun component of any typical sentence. Shifting from a function-oriented to an object-oriented mindset is akin to transitioning from an active to a passive tense.
Object Orientation is a method of organising hardware and software resources into modular units, facilitating the seamless connection and utilization of an object with any other object in the environment, contingent upon adherence to specified object interface rules.
Systems devised in an object-oriented manner often manifest distinctive characteristics compared to those developed using more traditional functional approaches. Large object-oriented systems typically adopt a layered abstraction structure, where each layer signifies a collection of objects and classes with constrained visibility to other layers, referred to as a sub-system. Moreover, components within a sub-system tend to be structurally flat, departing from strict hierarchical and deeply nested structures.
The global flow of control in an object-oriented system differs significantly from that of a functionally decomposed system. In the latter, a single thread of control typically follows the hierarchical lines of decomposition. Conversely, in an object-oriented system, identifying a central thread of control is challenging as objects may operate independently and autonomously. Instead, numerous threads may be active simultaneously throughout the system, a model that more accurately mirrors our abstraction of reality. It is noteworthy that the subprogram call profile of an object-oriented system often features deeply nested calls, with the implementation of an object operation frequently involving the invocation of operations upon other objects.
While the concept of an object assumes a pivotal role in object-oriented systems, it is not a novel idea. As MacLenna asserts, programming is fundamentally object-oriented mathematics.
For many, object orientation involves structuring actions and processes around data. While this basic approach suffices for the software application layer of the I.S. architecture, it may prove inadequate for the business and operating environment architecture layers.
Why is Object Orientation so Important?
Why do we need Object Orientation?
1. Deployment of multiple hardware and software components to execute the functions of the same constituent. For instance, a machine may operate both OS/2 and DOS as operating systems concurrently.
2. Utilisation of incompatible, and sometimes mutually exclusive, components. As an example, running Ventura (Desktop Publishing) under DOS and GEM, configured for a WYSE 7190 high-resolution graphics adapter, cannot occur simultaneously with GUIDE (Multimedia) running under DIS and Windows, configured for a Super VGA adapter.
3. Implementation of hybrid software and hardware components. For instance, utilising OS/2 PM on an IBM PS/2 as one workstation, and Unix, Motif, and OpenLook on a SUN as another workstation, both linked to a DEC/VAX mainframe running Sybase as a database manager. Hybrid technologies introduce highly intricate operating environments, potentially evolving into challenges for system administrators and users due to the efforts required to maintain seamless Information Systems (IS) operations.
4. Presence of poorly integrated facilities in the operating environment leading to:
- Conflicts between components
- Inconsistencies in data and outcomes of operations
- Redundancy (or duplication) of data, functions, and facilities
- Fragmentation of operational systems.
Objectives and Benefits of Object Orientation
1. To formalise our model of reality through a suitable mechanism, establishing a direct and natural correspondence between the world and its model.
2. To provide a more natural paradigm for emulating the real world in the application environment.
3. To enhance understandability and maintainability by associating objects with their related elements.
4. To ensure the reusability of all system components, encompassing hardware, software code, designs, concepts, and systems.
5. To guarantee the "open-endedness" of software (and hardware) components, enabling maximum configurability.
6. To facilitate a cooperative and concurrent processing environment to achieve maximum throughput.
7. Applicability to problems involving natural concurrency, where the object-oriented method demonstrates superior solutions, particularly in real-time processing scenarios.
8. Mastering and dynamically allocating appropriate system resources for optimal task execution.
9. To reduce the total life-cycle software cost by increasing programmer productivity and diminishing maintenance expenses.
10. To ensure system robustness.
11. To implement software systems resilient to both accidental and malicious corruption attempts.
12. Modular, object-oriented programming yields software products on which modifications and extensions (maintenance) are significantly easier compared to programs structured in a more conventional, procedure-oriented fashion.
13. To rationalise and optimise the organisation of the Information Systems (I.S.) Application Environment.
14. To facilitate the "packaging" of hardware and software components supporting distributed architectures.
15. To ensure interchangeability of hardware and software components, thereby facilitating diversification and natural technology enhancements as migration to improved environments becomes transparent.
16. Comprehensibility and architectural elegance.
17. To ensure system quality.
18. To establish a Business consisting of Business objects.
19. To establish a Methodology consisting of Method objects where operations are localised.
What does Object Orientation mean to the Businessman?
The imperative for businesses to ensure their survival is compelling a swift responsiveness to evolving business requirements within a matter of weeks. Maintaining a competitive edge hinges on the capability to foresee and implement changes more expeditiously than competitors. To stay attuned to the current pace of change in the business landscape, businesses must possess the agility to adapt both their business and information systems concurrently, preempting impending transformations.
A business structured around distinct business objects, amenable to replacement in an object-oriented manner, stands a favourable chance of achieving the requisite rate of change. If a business object, such as a Procurement process, can be seamlessly replaced without disrupting surrounding business objects, the process of change becomes notably simpler and more streamlined. This objective is attainable through object orientation implemented at the business level.
The genesis of object orientation can be traced back to the technological realm of systems, where true objects initially manifested in hardware formats. For instance, a graphic card is endowed with a set of methods facilitating control over displayed images on a screen. Subsequently, the evolution of objects progressed to programmable processes designed and coded as objects. Businesses are now liberated from the onus of investing in and developing these disparate levels of objects, as they are readily available in the commercial domain. Objects that programmers were coding individually a year or two ago are now procurable off-the-shelf.
Presently, there is a notable shift in focus towards business objects, with organisations investing in the development of objects at an architectural level. These objects are anticipated to yield similar benefits as those at the other two architectural levels. In the near future, objects at this level are expected to be commercially available off the shelf.
The current rationale underscores the strategic significance of businesses making an investment to either acquire or construct a suite of business objects. However, it is crucial to recognize that solely relying on business objects is insufficient to address the problem at hand. A dedicated set of business objects is necessary to proactively anticipate the need for change. Consequently, there is a requirement for a set of business objects specifically tailored for business engineering, enabling the establishment of strategic business systems comprising business strategic objects.
The industry should concentrate on the development of both generic objects and more specialized classes, making them accessible for purchase by any entity. Businesses are encouraged to share their business objects with competitors, recognizing that providing such objects affords them a competitive advantage. Ultimately, it is not just the possession of objects but the adept application of these objects that will distinguish businesses in the long run.
In the realm of Object-oriented paradigm, any new development of a business object focuses on creating small objects, categorizing them into class structures, assembling larger objects from smaller components, and constructing objects with more explicit and streamlined interfaces. This approach facilitates the retirement of a business object and the creation of a new one.
Organisations adopting this methodology are more susceptible to change crises due to their ability to adapt rapidly. This underscores the importance of Change Management, as individuals are likely to encounter challenges associated with change more frequently. Therefore, fostering a culture of Change and Learning within the organisation becomes imperative.
Layers of Business Objects
A business structured around objects diverges from a conventional business framework by being inherently object-centric rather than transaction-centric.
In a typical business model, various business functions are established to facilitate the sale of products to customers. This transactional process involves the customer placing an order, initiating a chain of events such as order verification, inventory management, and product procurement from a supplier. Subsequently, additional functions come into play, generating documents like purchase orders. Managers are then tasked with scrutinizing these purchase orders against request-for-purchase documents to ensure accuracy in quantity.
Upon submission of the purchase order to the supplier, product delivery is accompanied by a delivery note. Another set of business functions, staffed by individuals, is engaged in disseminating the delivery note and cross-referencing it with outstanding orders to ascertain which deliveries correspond to specific orders. This step is crucial for understanding the associations between deliveries and orders that are yet to be fulfilled.
A business that has its systems structured around such a transaction requirement needs a bigger staff component and many more control mechanisms, which ultimately complicates and slows the process down.
The alternative is to construct the business from system components that are grouped around objects. What this means is that we have to identify the potential objects. In the previous example the Product qualifies as an object. Then we have to identify all the transaction states that the object can have.
The product can Be Sold, Be Requested from Inventory Management, Be Quoted For by the supplier, Be Ordered from the supplier, Be Delivered by the supplier, and Be Received by us. What we have to do now is to group methods around this object that can interface with methods of other objects.
The methods of a particular object also have to have the ability to change the status of the object to one of its relevant transaction states. An example of another object could be the Supplier that could have states of Be Ordered From and Has Supplied.
In the aforementioned example, the Supplier functions as the Respondent, while the Product assumes the role of the Initiator.
A distinct rationale for design was applied in the latter scenario. The arrangement of functions was organized based on processes rather than transactions, as is customary. The typical business cycles or processes can still be accomplished by employing the functions of the objects in a specific sequence and enabling their interaction with functions from other objects.
Within the object-oriented paradigm, businesses are built upon layers of objects. Business objects are overlaid on commercial objects, which in turn are superimposed on technical objects.
- 1. Business Strategic Objects
- Characteristics of these objects:
- They pose challenges in development.
- Competitors find it difficult to replicate them.
- Over time, development durations decrease due to the object-oriented development paradigm, although initial development may still be time-consuming.
- They provide benefits that are challenging for competitors to match, resembling a genuine first-mover advantage (Building the Wall).
- They create opportunities for a new customer base, such as South African deep gold mining operations capitalizing on their expertise for consultation.
- They alter the competitive landscape, pushing a product market towards a service or solutions market with minimal markup on actual products.
- They establish a platform for continuous evolution, allowing strategic objects to be continually modified from an object-based platform (Widen the Gap between you and your competitors).
- Conceptualizing them may be challenging at times.
- Examples of the Objects:
- Forecasting product trends.
- Forecasting market trends.
- Sales channel front-end tools.
- Sales advisor/configurators.
- 2. Commercial Objects
- Characteristics of the Objects:
- They exhibit similarity among businesses of the same industry type.
- Commercially available in packages.
- Easily accessible.
- They do not require substantial investment for enablement.
- They are relatively easy to understand, based on fundamental business practice principles.
- Perceived as essential.
- Examples of the Objects:
- Bill of Material.
- Inventory Management.
- General Ledger.
- Procurement.
- 3. Technical Objects
- Characteristics of the Objects:
- Initial conceptualization may be challenging.
- Relatively basic in nature, such as a cursor.
- Fully programmable.
- All are purchasable.
- They do not require a significant investment to establish.
- Configuration management could be problematic due to their abundance.
- Examples Of the Objects:
- Device Drivers.
- Graphics Objects.
- Data Engines.
- A cursor.
- A column of a table.
- The objects accumulated are based on business decisions dictated by business requirements. Building object-based business systems involves establishing business requirements and reflecting them in Strategic Business Objects. These objects are based on a layer of Commercial Business Objects below them, which, in turn, are based on Technical objects one level below them. All three layers of objects together represent all the business objects.
- It is possible to have designed and implemented objects at any of the three levels with only a partial representation of true object designs and implementations at the other two levels.
- 4. The Impact of Object Orientation on a Process Oriented Business Design
A process orientation typically embodies a highly structured business design, owing to its sequential nature. Modifications to components within such processes invariably impact the entire procedure, necessitating the implementation of a phased change plan over an extended period to accommodate the required shift in mindset. Executing changes gradually, however, implies a risk of not fully capitalizing on available business opportunities in many instances.
When a process is composed of autonomous objects, it facilitates the seamless replacement of one object with another. From a technical design standpoint, an object-oriented system allows for a controlled implementation of change, minimizing the overall impact on the process by confining the effects to the specific object or objects that undergo replacement.
This approach enables a considerably faster implementation of process changes, ensuring that the window of business opportunity is not missed. Continuous alignment of a process with the necessary strategies becomes more manageable. However, in a business structured around processes, individuals must possess a broader skill set to navigate various functional areas, given that a process often spans multiple functional domains. Changes to such systems encounter diverse resistance, as a broader group of individuals is affected.
The inherent nature of process-oriented systems implies that individuals become more accustomed to the procedural aspects of their work. The ability to change processes rapidly and regularly poses a challenge in securing buy-in from personnel managing the systems. Introducing new objects affects a larger number of individuals, necessitating potential re-skilling efforts and encountering resistance from a broader spectrum of stakeholders.