Dynamic Subset or Composite-Object VIEWS
There is a great deal of ambiguity and miscommunication in an enterprise with multiple isolated, autonomous departments. People who handle Marketing, Order Entry and Billing have much different training, business processes, and vocabulary than Design Engineers and Order Fulfillment.
There are three types of common enterprise-wide intercommunication ambiguity:
(1) Multiple departments or specialists have different names for the same Object, and
(2) The same word has very different meaning in different contexts.
(3) Acronyms often spell words that have a different meaning than the acronym.
For example, “run” has over 130 distinct, ambiguous, different definitions in some dictionaries, and some departments may have different meanings for a context-specific acronym like R.U.N. If a communication sender is thinking one meaning of “run” and different communication receivers assume it to mean a variety of other things, corporate miscommunication is the common result. An Enterprise Glossary can document potential ambiguous miscommunication, AND also reduce the creation of future unintentional confusing ambiguities.
An effective, efficient, Enterprise Object Model must disambiguate words in various contexts. This can be done with specific relationship types, such as: synonym, antonym, acronym, homonym, see, similar, contrast, etc. The Enterprise Model builder defines the types of standardized relationships between terms, and then uses generic hyperlink software that allow model users to disambiguate enterprise terms. The links may be within the distributed enterprise “Intranet,” or externally on the World Wide Web Internet.
All human languages have the concept of nouns and verbs. It must be a universal characteristic of human intellectual capabilities. In the Enterprise Architecture Model, nouns are represented as the names of Object types-and-instances. Verbs are usually processes associated with Objects, service-oriented architecture elements, or applications invoked through an enterprise serve bus.
The Enterprise Model builders gather departmental glossaries and common communication forms, and then performs “grammatical dissection.” For example: nouns are represented as Objects, verbs as processes, adjectives as Object data attributes, and adverbs a process invocation parameters.
When non-computer-programmers look at the integrated Enterprise Architecture Model, they should recognize (and be comfortable with) all of its component part terms. Instead of building autonomous computer systems that are modeled after the processors and databases of computer hardware, Our innovative Enterprise Architecture builds integrated computer systems with components that use the common pre-existent vocabulary of enterprise Objects, attributes, processes, and relationships.
One important architectural model issue is that different departmental contexts require different “VIEWS” of enterprise Objects. When an Order specifies product “X”, there is minimal information required, other than perhaps a brief product description. The person who enters the Order does not type the product description. It is obtained automatically from a different source when the unique identifier is specified. This is a “composite view” made up of an Order entry message, and a database that contains product descriptions (among many other types of data).
In the following Subset-and-Composite-Object VIEW diagram, the Enterprise Model Metadata can define an environment whereby any VIEW of Object A, B, or C can be updated, and the update can be validated and propagated to all other VIEWS that contain the modified data element(s).
For example, if A, B, and C are different VIEWS of a product, and a subcomponent part of the product is changed by an authorized user, the change would show in all three views of the product (where needed). A log of all such updates could track the source of all such changes (to help diagnose the point where any possible errors may have been inserted). The log could be easily created as a Subscription to all changes of a particular type.
Another VIEW-change example might be if a person’s address changes, all instances of that person’s address could be changed (within 2 elapsed seconds) worldwide in every Enterprise VIEW where it appears. The Enterprise Object / View Model would describe how views could be used for updates,
as a set of Publish-and-Subscribe messages.
When an Order message is passed on by a publisher to a subscriber responsible for Order fulfillment, then a very-different, more-detailed description of the subcomponent parts of “X” may need to be supplied.
PPerhaps multiple different suppliers (A, B, and C) can supply the parts needed to construct an X. Subsystems may be triggers to check current availability and price of the components from various vendors and make time-specific recommendations to Order fulfillment. All of this may be implemented as different VIEWS of X that are meaningful in different CONTEXTS.
The concept of ambiguous dissimilar VIEWS extends to the types of a business object. For example in an aircraft-scheduling yield-management system, an airline wants to optimize the use of their finite resources. Their goal is to fill every seat on every flight leg. Putting a large airplane on a leg that they predict will have limited passengers is a major expensive error. In the yield management application, “777” is an object instance that should be used for a specific flight leg (any Tail Number will do).
In other applications, such as aircraft preventive maintenance scheduling, 777 is not and instance – it is a type of aircraft, where the instances have individual Tail Numbers. Periodically, you would like each aircraft instance to fly a full flight leg that winds up at a maintenance base that can perform required preventive maintenance on it.
A particular 777 instance may have specific engines that get replaced with other engine instances, which have previously had required periodic maintenance. They must be tracked throughout the life of the aircraft, and all of its components parts (down to the source of all rivets and screws).
The Enterprise Model must define the VIEWS and business events required for all Object processes.
In a non-integrated enterprise, each of these different VIEWS may be implemented in different hard-coded, inflexible, autonomous, department-specific application programs, with a lot of redundancy and incompatibility. In an integrated-enterprise, generic, metadata-driven, reusable software components can be rapidly assembled to accommodate future, unanticipated, system requirements, mergers and acquisitions that perform reliably, consistently, and well in many diverse contexts.
This state-of-the-art concept accommodates cumbersome, sluggish, expensive, distributed, legacy, relational databases, but we go far beyond them with unprecedented, agile, comprehensive, high-performance multi-dimensional, context-specific, Enterprise Architecture DYNAMIC VIEWS.