The Aspects Framework:
Expressing community intentions
Paul S Prueitt, Founder BCNGroup and Ontology Stream Inc
The Challenge
In
the following presentation a point of view is expressed about the nature of
difficulties that are commonly found with enterprise software systems such as
accounting systems for school, colleges or universities. We hold that the dysfunction of school
accounting systems has a root cause related to the difference between
computational systems such as web service systems and the natural processes
occurring in the school system. After
this point of view is developed, we present a business opportunity based on a
human in the loop solution. Process
mapping plays a central role in this solution.
Ideally the faculty, staff and administrators of schools should see computational systems mirror intention directly. This ideal is empowered when a software interface and operating system is developed in a fashion that provides transparency.
Without transparency into “how” information systems work, an external process often shapes the expectations of the user. In education, the mission and governance statements of universities, colleges and school districts define goals that are not exactly simple. Up to now, however, the design of information systems has been left to outside consultants and software vendors.
The historical context is changing. Subtle issues related to modeling natural reality has become clear and new tools for modeling processes have been supplemented by tools for tracking and monitoring the influence of real world processes.
Is American education ready for a transformation event, an event that brings renewal and re-alignment to traditional views about education? This question has many parts and the answers are tentative and conditional.
Why software systems are non-complex
As in the classical Business Process Re-engineering activities, the transformation event starts with an AS-IS model of the current situation in education. The core issue is complexity and complicatedness and the confusion of the two.
Academic scholarship has produced a computational paradigm that is a bit confused about the nature of complexity, complicatedness, and computational science. The result is the use of a confusing language in the marketing of software products and consulting services. The simple result is that most software system remains non-agile and complicated.
Traditionally, J2EE developers have had two
choices for transaction management: to use global or local
transactions. Global transactions are managed by the application server, using
JTA. Local transactions are resource-specific: for example, a transaction
associated with a JDBC connection. This choice had profound implications.
Global transactions provide the ability to work with multiple transactional
resources. (It's worth noting that most applications use a single transaction
resource) With local transactions, the application server is not involved in
transaction management, and cannot help ensure correctness across multiple
resources.
There is complicatedness as local transactions are asked to perform in ways that are data-interoperable even when exposed to other process that are designed by different groups and from different perspectives.
In the programming literatures, the concept of openness to new facts is treated as if this openness to new information structure, which XML provides, is the same as axiomatic openness. Complicatedness found when data systems are not data-interoperable is a completely different phenomenon than complexity. Complicatedness due to data not being interoperable is something that does not lead to a richness of choice, but simply to dysfunction that has to be fixed.
How might this current situation undergo a transformation? A mature understanding of the natural complexity involved in shifting a viewpoint, or merging two or more viewpoints is required.
What the markets need is software that recognizes complexity. What the market is getting is data-non-interoperability. The confusion does not yet allow public acknowledgement of a de facto replacement of one need with another need. However, there are clear signs that the public is prepared for a transformational event related to all software products and services.
Our society is becoming more and more aware that software development has a transparency problem. Without clear scholarship on foundational issues, presented in a simple fashion; the public does not have the facts needed to understand why software has become so expensive and controlling. Great progress is made on some fronts but not on others. For example, the OASIS SOA Reference Model touches on the nature of interaction and consequences.
Visibility,
interaction, and effect are key concepts for describing the SOA paradigm. Visibility refers to the capacity for those
with needs and those with capabilities to be able to see each other. This is typically done by providing
descriptions for such aspects as functions and technical requirements, related
constraints and policies, and mechanisms for access or response. The descriptions need to be in a form (or
can be transformed to a form) in which their syntax and semantics are widely
accessible and understandable.
Whereas
visibility introduces the possibilities for matching needs to capabilities (and
vice versa), interaction is the activity of using a capability. Typically mediated by the exchange of
messages, an interaction proceeds through a series of information exchanges and
invoked actions. There are many
facets of interaction; but they are all grounded in a particular execution
context – the set of technical and business elements that form a path between
those with needs and those with capabilities.
This permits service providers and consumers to interact and provides
a decision point for any policies and contracts that may be in
force.
The
purpose of using a capability is to realize one of more real world
effects. At its core, an interaction is
“an act” as opposed to “an object” and the result of an interaction is an
effect (or a set/series of effects). We
are careful to distinguish between public actions and private actions; private
actions are inherently unknowable by other parties. On the other hand, public actions result in
changes to the state that is shared at least between those involved in the
current execution context and possibly shared by others. Real world effects are, then, couched in
terms of changes to this shared world.
The
expected real world effects form an important part of the decision on whether a
given capability matches similarly described needs. At the interaction stage, the description of real world effects
establishes the expectations of those using the capability. Note, it is not possible to describe
every effect from using a capability, a cornerstone of SOA is that we can use
capabilities without needing to know al the details. (Italics made for emphasis.)
Lines 211 – 222
[2]
Our critic of the OASIS SOA Reference Model is made in a context of strong approval of the reference model. The OASIS document properly identifies issues such as the difference between and act (in the natural world) and the performance of an object.
The consequences of using a capability needs transparency and without this transparency the provision of services is blind. So why is the reference model claiming the following?
“a cornerstone of SOA is that we can use capabilities without needing to know all the details”
The answer is due to the software industry’s need to hide how the service is accomplished in the software, and perhaps also by whom the service is to be completed. Historically the IT viewpoint has come to be the only viewpoint considered. The viewpoint is that no one other that software designers need to understand how the software works. This historical context shapes the business opportunity to be proposed by shifting focus from lines of business to process models.
High-level explanation of the aspect framework
Due to the maturity of the software paradigms, we may move from the high level aspect of software development and lines of business to the aspects of process models and topic models.
An aspect is a part of something that seems essential.
The use of the term “aspects” has two separate meaning, both correct. First, the construction we outline here, and then develop in detail elsewhere, has four high level aspects:
· Software development,
· lines of business,
· process models, and
· topic models.
This first sense of “aspect” is that these four aspects are aspects of the real world. The complete aspect framework models how these real world elements may interact in an optimal and transparent fashion.
Drawing of the High-level Aspects Framework
The second meaning is contextual within each of these four high level aspects; and changes from one to another. Within each context, the high level aspect is to be seen as having three levels; (1) a substructure level – corresponding to the common notions of “aspect” and “facet”, (2) an object/line-of-business/process-model/topic level, and (3) environmental interface. The details about these three levels within each high-level aspect changes but details have corresponding commonalities that are important to understanding and using the aspects framework.
The issue of merge and control
The aspect framework is designed to measure and objectify a larger social and cultural interaction, resulting in a computational imprint of formally separated processes.
An operational understanding is possible that is easily understood by educators. This understanding is also philosophical in nature and yet the literatures supporting a conceptual linkage between operational issues and philosophical issues have been identified. Scholarship clearly demonstrates that the natural world is not fully amenable to simulation, and that computational models of many natural systems have to be open at the most foundational level, as well as in a surface level.
A renewed authority over IT procurement will be given by the aspect framework standards to be developed.
Our operational orientation asserts that XML gives to the relational data model an openness that is surface, but not at a foundational level. The meaning of “open at the foundational level” has not been easy to discuss because scholars must refer to the induction of abstract systems, such as everyday natural language use, and the situational meaning that these symbols have. However, education in this century must start with an understanding of the limitations and properties of computational systems. These are issues that leading scholars are raising and describing, and is of interest to those in the education community, K-12, colleges and universities.
One cannot start this discussion based on theory. One must start with observation. The aspect framework standard will specify a
requirement that faculty and administrators, as well as selected parts of the
staff shall be informed by a perceptive history of computer science. However, as a business process we understand
that the theoretical underpinnings of the standard is currently inaccessible.
When one has a full grounding in the history of computer science,
one observes that in spite of the formal separation, a merge of viewpoints must
occur. Merging of viewpoints has proved
to be very difficult when using the current software. To support viewpoint merging, the aspect framework has four
service interfaces. Each service
interface provides a structural mechanism that supports human-to-machine or
machine-to-machine transactions.
Reconciliation mechanisms are also in place.
Any mechanism that is developed to handle the merge of formalized
viewpoints must depend on the assumption that individual viewpoints are
resolved and represented formally. If
the viewpoint is actually not the same and formalized, then movement back and
forth may not be simulated completely. [3]
Thus the transaction spaces must evolve towards an offering of the control of
state changes up to humans acting in real time. The SOA standards that have begun to talk about this are referred
to as SOA blueprint and SOA human choice point standards.
In architectural specification by OntologyStream Inc, for US
Customs and other agencies, small well-defined and transparent ontological
models, implemented in OWL DL, control the merge function. [4]
The structures of these small ontological models were worked out by several
groups of knowledge engineers and are available in a non-proprietary form. However, the level of technical knowledge
about web ontology and inference required to use these models is significant,
not so much intrinsically but due to a, required, shift in underlying
assertions from the mainstream software development paradigms. [5]
The Optimality Argument
The argument is made in various technical committees that, in the abstract, the service exchanges should not depend on who and how. However, the technical aspects of “how” a service is accomplished, when optimal, may be objectively known.
We conjecture that transparency over “how” software accomplishes services will drive the software development frameworks into a minimal level of complicated-ness. This minimal level of complicated-ness has not been available up to just recently due to specific mistakes made by academic computer science and re-enforced by the business of software development. However, this past systemic behavior can be seen as being part of the past. Business Process Management development systems have developed a new sense of transparency.
The trade off is in the economic value of proprietary knowledge. When this issue of transparency no longer has a veil we see more clearly the larger issue of consequences in the world due to actions taken.
We are allowed to shift the focus from the technical issues of how data is exchanged. We then are allowed to see, more clearly, short term and long-term consequences of actions taken. The actions are facilitated using service-oriented architectures where the data objects are well specified in public standards.