Last month's column discussed the Object Management Group's (OMG) Model-Driven Architecture in terms of the recently-approved Semantics of Business Vocabulary and Business Rules (SBVR) specification.^[1]  That column discussed how concepts are represented and how modeling languages and models are composed.  Many models are required to describe fully anything so complex as a business or a distributed information system.  In this month's column, attention is turned to the bigger picture of how to organize and relate a series of models that collectively describe a complex business or information system.  This is the topic of architecture.

In 1987, John Zachman, then at IBM, published a seminal article^[2] in which he proposed a framework for systems architecture that has become known as the Zachman Framework for Enterprise Architecture.  The concept of 'enterprise architecture' (EA) has been developed extensively in the years since Zachman's article appeared.  Several EA standards have been promulgated, including the ISO/IEC Reference Model of Open Distributed Processing (RM-ODP:  ISO 10746, ITU-T X.900 ), the IEEE Recommended Practice for Architectural Description of Software-Intensive Systems (IEEE Std. 1471), the Department of Defense Architecture Framework (DoDAF), OMG's Model-Driven Architecture, and others.  Each of these has its roots in Zachman's work.

"Many innovations are resulting from this attention to the architectural level, among them architectural description languages and associated tools and environments; architectural frameworks, models, and patterns; and techniques for architectural analysis, evaluation, and architecture-based reuse." (IEEE 1471)

Viewpoint is a central theme of enterprise architecture, defined (in IEEE 1471) as "a specification of the conventions for constructing and using a view.  A pattern or template from which to develop individual views by establishing the purposes and audience for a view and the techniques for its creation and analysis."  An alternative, but consistent, definition of 'viewpoint' is provided in RM-ODP, "a form of abstraction achieved using a selected set of architectural concepts and structuring rules, in order to focus on particular concerns within a system."^[3]  SBVR defines 'viewpoint' as a "perspective from which something is considered."

A viewpoint can be defined by a set of SBVR abstract languages, each of which provides a vocabulary to describe a particular thing being modeled from that viewpoint.  For example, RM-ODP provides a language for each of its five viewpoints.  A view comprises a set of conceptual models that describes some complex thing and that is based on the abstract languages of a particular viewpoint.  A view consists of one or more models, and a model can participate in one or more views.  The notion of composing a description of a thing as a series of views based on standard viewpoints can be applied to any kind of thing.  In particular, the notion can be applied recursively to each component of a complex thing such as a business or an information system, the components being obtained by recursive decomposition of the complex thing.  Thus, the specification of a view includes the viewpoint and a description of the scope of the thing that is the subject of the view.

The Zachman Framework, usually presented in the form of a matrix, defines six viewpoints, called 'perspectives' (or 'rows'):

1.	SCOPE.	Planner's perspective.	(Contextual)
2.	BUSINESS MODEL.	Owner's perspective	(Conceptual)
3.	SYSTEM MODEL.	Designer's perspective	(Logical)
4.	TECHNOLOGY MODEL.	Builder's perspective	(Physical)
5.	DETAILED REPRESENTATIONS.	Sub-contractor's perspective	(Out-of-Context)
6.	FUNCTIONING ENTERPRISE.	The actual enterprise, in operation

Other architecture frameworks define viewpoints somewhat differently.  For example, RM-ODP has five viewpoints:  Enterprise, Information, Computational, Engineering, and Distribution.  The DoDAF has four viewpoints, called 'views':  All View, Operational View, Systems View, and Technology View.  MDA formerly had three viewpoints:  Computational Independent Model (CIM), Platform Independent Model (PIM), and Platform Specific Model (PSM).  However, these MDA viewpoints are being deprecated, for reasons discussed in the previous article.  MDA is currently undergoing an architectural revision, and appears to be heading in the direction of leaving users to define viewpoints that best suit them, then modeling those viewpoints using MDA modeling languages.  Thus, although MDA recognizes the need for different viewpoints to compose a complete description of a system, MDA does not dictate any particular choice of viewpoints, but can be used with any of the architecture frameworks.  Viewpoint languages are being developed for MDA.  The OMG currently has a request for proposals for a UML Profile for DoDAF.  A group of RM-ODP users is developing a UML Profile for RM-ODP as an ISO standard.  SBVR can support each of these specifications with natural language vocabulary and rules and their logical formulations.

The notion that there must be well-defined relationships between the views of different viewpoints of a particular system is also an important part of enterprise architecture. This is equivalent to saying that the views must consistently describe the same thing, just like different plan, elevation, perspective, and construction detail views of the exterior and interior of a building each shows a different aspect of the building, consistent with the other views.  For example, RM-ODP specifies certain rules, or 'correspondences' that must appertain generally between its viewpoint models.  In MDA, this notion of correspondence is highly refined into the concept of model transformation and rules and procedures that relate a model of a system from one viewpoint to another model of the same system from a different viewpoint.  MDA transformations are addressed by OMG specifications such as the

MOF Query, View, and Transform (QVT)	general transformation between MOF models
Human Usable Textual Notation (HUTN)	transformation of UML to readable text
Ontology Definition Metamodel (ODM)	transformation between ontology languages
Semantics of Business Vocabulary & Business Rules (SBVR)	transformation between linguistic and logical formulations

Zachman defined a set of six primitives, called 'abstractions' (or 'columns'), that are asserted to be sufficient aspects to completely describe a viewpoint.  Each primitive addresses a particular question about the viewpoint.  The intersection of a row and a column -- a 'cell' -- defines the scope of models of the abstraction of the column from the perspective of the row:

1.	DATA.	What?	(Things)
2.	FUNCTION.	How?	(Process)
3.	NETWORK.	Where?	(Location
4.	PEOPLE.	Who?	(People)
5.	TIME.	When?	(Time)
6.	MOTIVATION.	Why?	(Motivation)

Other frameworks also address these same six primitives, although in different ways and to different degrees.  The DoDAF defines 24 different 'products' (kinds of models) -- analogous to Zachman’s cells -- that together cover the viewpoints and primitives of the Zachman Framework in a manner that is unique to DoDAF.  In MDA, UML has a set of diagrams that represent the different primitives, sometimes in combination.  UML Class Diagrams and Composite Structure Diagrams, including structural rules expressed using the Object Constraint Language (OCL), describe data and composite things (What?).  Activity Diagrams describe processes (How?).  Implementation Diagrams describe networks (Where?).  Use Case Diagrams describe roles of people (Who?).  Sequence Diagrams and State Diagrams describe time ordering and event-driven state transitions (When?).  New modeling languages are being developed by the OMG better to be able to describe the primitives.  The Business Process Definition Metamodel, the Business Process Modeling Notation, the Organization Structure Metamodel, and the Business Motivation Model each fit into this category.  It is vocabulary that ties all of these together when describing a particular business or information system.

SBVR is not an architecture framework, but supports architecture by providing mechanisms for modules.  The chief such mechanism in SBVR is vocabulary, which provides a language module that can be defined to support describing some viewpoint.  An SBVR vocabulary can be identified by a globally-unique Uniform Resource Identifier (URI) and rendered in XML for machine interchange.  An SBVR vocabulary is associated with a speech community, a group of people sharing a characteristic vocabulary.  An SBVR speech community can be associated with a particular audience or stakeholder group of a viewpoint (e.g., planner, owner, designer, builder, subcontractor) of a business or system being modeled.  SBVR also includes semantic community, which is a group of speech communities who share a set of concepts but who each use a different language or dialect.  An SBVR vocabulary can adopt definitions from other vocabularies.

SBVR vocabularies can include any of the primitive concepts.  An SBVR vocabulary can include concepts that are events, processes, time, or places but SBVR does not include 'event', 'process', 'time', or 'place' in its vocabulary, or temporal or spatial logics.  Thus, SBVR can be used directly to state facts and rules about events, processes, times, and places, and to describe them declaratively, but, to SBVR, these are just things like any other thing about which one states facts and rules.  SBVR does not include an ontology of time or space in its metamodel that would enable these to be recognized formally.  However, SBVR can be used to define and describe things that are temporal or spatial in nature.

The atemporal logics of SBVR apply to facts extant in a possible world (system state) and do not apply to circumstances between states, although causal facts can be included in any state, such as ‘if <event> happens, then <set of facts>’, or ‘at <event occurrence> <facts>’.  Asserting the consequent facts may change the system state, representing a different possible world of the system in which the conceptual schema of the system still holds, but nothing can be said about what transpired during the change of state.  The rules apply only in states, not between them, although they restrict allowable changes.  If inter-state details are relevant to the purpose of the model, they should be included in the model, reductio ad absurdum.  Since any event can be infinitely dissected, there is a practical limit on the granuality of an event needed for a particular purpose served by a model.  For example, it may be sufficient to talk about a baseball game as a unitary event, who played, who won.  For some other purpose, a video of the game may be needed, dissecting the game into some 250,000 video frames (still capturing only a miniscule description of everything that happended during the game).  Somewhere between, say giving the score at the end of each inning, may be an adequate dissection of the baseball event for some other purpose.

A similar situation applies to spatial and material things as to events, since space and matter is essentially infintely dissectable (to quantum limits).  SBVR provides for a thing to be considered as unitary or composite in different situations.  For example, in business, a person is usually considered to be a unitary thing.  However, in the health care field, people are considered highly composite in the role of patient, but unitary in the role of health care provider.  Sophisticated theories of mereology and topology are not included in SBVR, but could extend SBVR where they are needed.

SBVR supports the common linguistic function of objectification, by which a fact type can be related to a corresponding noun type, the instances of which represent actualities that are instances of the fact type.  In this way, facts using active verbs can  have a formally-defined corresponding event.  For example, the fact type 'person buys automobile' can be objectified to 'automobile sale'.  To each fact of the fact type (e.g., "the person named 'Joe' bought automobile 'XYZ 123'") there corresponds an automobile sale event.  For those familiar with UML, a UML Association Class is an objectification.  Objectifications in SBVR have implied fact types relating the objectification to the roles of the underlying fact type:  'automobile sale involves person' and 'automobile sale involves automobile'.  An objectification is used just like any other noun concept.  Other fact types can be predicated of an objectification, such as 'automobile sale occurred on date', 'automobile sale is reported to the Department of Motor Vehicles', etc.  There can be rules about objectifications:  'Each automobile sale must be reported to the Department of Motor Vehicles no later than 7 days after the date the automobile sale occurred.'  To talk about the date of the report to the DMV, 'automobile sale is reported to the DMV' can be objectified as 'report of automobile sale' and be given a date, which must not be more than 7 days after the date the automobile sale involved in the report of automobile sale occurred.

SBVR includes the fact type 'integer1 is less than integer2', so that any set of events that can be put into correspondence with the integers can be ordered formally.  The primitive mechanisms of objectification and ordering provide hooks to extend SBVR with temporal and spatial concepts and logics, and to relate SBVR models logically to process models, provided the process models use the SBVR vocabulary, or a suitable transformation of the SBVR vocabulary.

Conclusion

This  article and the previous article have introduced SBVR by describing MDA in terms of SBVR.  MDA concepts of models, modeling languages, and meta levels was explained using the concepts of SBVR.  It was also explained how enterprise architecture uses a composition of models to describe all aspects of a complex thing such as a business or an information system.  It was explained how MDA relates to enterprise architecture, and how MDA and enterprise architecture are each supported by SBVR.

SBVR is new, and SBVR tools and techniques are just beginning to emerge.  With approval of SBVR by the OMG, early adopters are now being sought to work with SBVR developers to launch this promising new technology.

To learn more about how you can use and benefit from SBVR, contact Stan Hendryx, stan@hendryxassoc.com or visit www.hendryxassoc.com.

References

[1]  Stan Hendryx, "SBVR and MDA," Business Rules Journal, Vol. 6, No. 10 (Oct. 2005), URL: http://www.BRCommunity.com/a2005/b253.html  

[2]  John A. Zachman, "A Framework for Information Systems Architecture," IBM Systems Journal, vol. 26, no. 3, 1987.  IBM Publication G321-5298.  See also http://www.zifa.com  

[3]  Note that the IEEE defines viewpoint in terms of its role, whereas RM-ODP defines it in terms of its structure.  These definitions are complementary.  It is not unusual to find both structure and role kinds of definitions of a concept.  Often roles are transitory, so are defined separately from the structure of a thing that can play that role.  

# # #