Jim,
As much as I may like to think so, I have little real power to ensure
anything in the world of global standards development.
However, the next generation OO-edi standards will not be data centric.
Rather, they will be based on process models. Inserted below are excepts
from the X12 SITG Report to the X12 Steering Committee on the next gen
standards from November 1998. As you can see, they are clearly based on
process models. How these are technical implemented are in the domain of the
functional services providers, i.e., the solution providers. That means that
they could be implemented using XML, distributed objects, and so on. You
should also know that the UN/CEFACT has imposed upon itself the requirement
that all new standards as well as changes to existing standards be based on
modeling, using the UML.
This documents and others can all be obtained via the X12 web site at
http://www.x12.org or the DISA web site at http://www.disa.org. Look for the
SITG pages. Work is already in process (and has been for years) in UN/CEFACT
on all of this OO-edi effort. And all of the effort, both at the UN and X12
are focused on enabling the ISO IS14662 Open-EDI Framework.
Please note that the text below is "excepted" from the complete SITG Report
to the X12 Steering Committee on the Next Generation EDI standards. I trust
it will provide some insights and perspective into what's been going on
within both the national and international EDI standards development
organizations over the last 5 or so years.
Rachel
"THE ROLE OF MODELING TO OPEN-EDI
As SITG assessed its fundamental goals to expand the use of electronic
commerce (EC) throughout the national and international business community,
the essence of success appeared to depend upon the availability of
affordable, interoperable, �plug and play� software packages that met the
functional needs of the business community. An examination of the
marketplace highlighted that the primary inhibitor to such products was the
range of potential buyers for any given software package through which a
software developer could recover costs and make a profit. Further analysis
indicated that these limitations derived primarily from the fact that
businesses do not all follow the same set of business processes, or at least
the semantics of describing those processes.
Modeling eliminates the semantic differences of processes. When the
semantic differences of business procedures (i.e., proprietary differences
that distinguish one trading partner�s application from another�s) are
stripped away, considerable commonalties are found with respect to process.
Within an Open-edi environment, modeling permits the decomposition of
business processes into smaller, standard reusable parts. In turn, this
permits the rationalization and harmonization of processes, the elimination
of �non-value added� steps, and the identification of essential data
requirements.
THE NEXT EDI STANDARD - PART I
SITG will recommend that one of the next generation of EDI standards be a
repository of business process and information models that identify these
processes, their activities, and data requirements. Through the use of use
case models, activity diagrams, sequence diagrams, collaboration diagrams,
class diagrams, etc., we can clearly articulate the full content of domain
business processes. In turn these models can be accessed by software
providers that, with some additional degree of assurance, can design and
market software (that successfully emulates the business process within a
variable level of detail) to satisfy both large and small applications.
SITG is also sensitive to a number of issues present today regarding the use
of alternative technologies as the basis for development, e.g., the use of
Extensible Markup Language (XML). In the current view of both SITG and
TMWG, the use of XML is not pertinent to the modeling decision. Further,
the use of XML is a relevant issue with regard to �how� to transport data,
not �what� to transport.
THE MODELING METHODOLOGY CHOICE
In examining the choices for a modeling methodology, SITG had to assess
several issues related to whether or not a single methodology should be
selected, the robustness of available methodologies, and the nature of the
data requirements that had to be supported by the model.
SITG chose a single modeling language because of the logistics and costs
associated with supporting a modeled environment, e.g., support tools,
repositories, training and education, comparable assessment and validation,
and reusability, all of which suggest that a single language is necessary.
There are several languages that are very robust, e.g., IDEF, UML, and
EXPRESS G. However, the final decision was driven more toward the
alternative that has been widely used in the software development community.
In the case at hand, SITG selected Unified Modeling Language (UML) as the
language of choice. As we will discuss below, SITG felt that UML provided a
more robust capability in support of an object oriented approach and was an
existing Object Management Group standard. While it may not be the most
robust modeling language, it is the de facto standard and also supports the
interactive behavior and data requirements for EC.
Object Oriented EDI (OO-edi)
If we accept the premise that �plug and play� software is the only viable
solution, then we must examine the potential for the software developing
community to rise to the occasion. As we assessed this subject, it quickly
became obvious that software was easily the limiting factor in any
opportunity for success. While hardware was the true benefactor in the
technology explosion, software could clearly not maintain the same pace of
advancement. As information systems attain strategic importance
representing the key to success in the marketplace, application
implementation costs, delayed implementations, and ineffective or inaccurate
software all too often results in increasingly complex and unacceptable
application based solutions.
THE ROLE OF OBJECTS
Industry is now turning to the use of object technology as the most viable
solution to the software development problem. Through the use of common
business objects we see the real opportunity to lower costs and hasten the
introduction of new software applications. Objects provide the ability to
encapsulate data and methods within a representation of program components.
They represent the use of a concept of reusable components that, in turn,
permit faster application development, easier maintenance, and reduced
program complexity. As a result, the use of object oriented architectures
permit applications acquired from different sources and installed on
different platforms to freely exchange information.
As quickly as industry is turning to the use of object technology we see it
just as quickly evolving to be a discriminator in the positioning of
application software in the marketplace. We see very little
interoperability between common business applications because the basis for
information exchange, e.g., business objects, are predominantly proprietary
in nature. If we are to affect this situation, we must think in terms of a
common source for object development.
THE NEXT EDI STANDARD - PART II
SITG will recommend that the second next generation EDI standard be object
classes that support the data requirements of the underlying business
process and information models.
SITG believes that a number of issues are resolved by developing and
attributing national (and international) standards body status to the object
class libraries. Objects provide the capability to encapsulate much of the
knowledge we now store in implementation guides. This facilitates the focus
we maintain on the BOV by documenting our knowledge and expertise related to
the business process. Interoperability objectives are satisfied in that
software developers do not require the development of proprietary objects to
support the business models. Cost objectives are met because software
developers are not required to develop the business process knowledge needed
to develop software applications. Lastly, software developers can focus on
product variations (e.g., look and feel) as the means to differentiate
themselves in the marketplace rather than focusing on the underlying
business process and data requirements.
In a nutshell, OO-edi is a �process-driven approach�, i.e., when a trading
partner looks at another trading partner, what is seen is a common (subset)
process, and potentially �extensions� that are unique to a trading partner
that are spelled out in a published �scenario�. These extensions become
easier to implement than the data driven approach, and perhaps are needed
for internal or competitive reasons.
VIABILITY OF OBJECT ORIENTED BUSINESS MODELS
The issue of whether or not object oriented business models was the correct
�technical solution� has been raised since the onset of SITG�s work.
Certainly, there are a number of alternatives which could conceivably meet
some portion of the needs of some businesses. Over time there have also
been suggestions that �technology� is not the answer to what we perceive to
be today�s problems. We totally agree with this comment. However, SITG
does feel that our approach is solely a �technology� approach. SITG feels
that we must deal with the fundamental business processes, remove the
semantics from the process, and leverage technology in such a way as to
maximize what we see to be the critical requirements of any new process.
There is no question that business modeling brings a discipline and level of
definition to process that facilitates the removal of �semantic barriers�.
Likewise, there is no question that the use of objects can greatly
facilitate the openness and interoperability of information exchange. When
combined, SITG believes that there is an unprecedented opportunity to
facilitate software development and establish a basis for an expanded open
dialog across the global business environment.
What remains is the requirement to instantiate these recommendations. A
level of comfort can come from what we see in today�s business environment.
A further level will have to come from time and experience.
Are We On The Right Track?
Obviously, there are no absolutes with respect to this question. However,
SITG is confident that industry is moving in this direction and that it does
represent a viable path for ASC X12 to follow. Some indicators include:
u A recent Gartner Group study confirms that application vendors are
generally just beginning to restructure their applications to keep up with
EC-enabled changes to business processes. Their work further confirms that
these vendors have not developed an electronic marketplace view of
information or processes. However, the move has started. To facilitate
this probable change ASC X12 could play a dramatic role on the evolution
process for both application development and business process refinement.
u As companies jettison inefficient and archaic ways of doing business, they
are likewise streamlining business computing systems. Big and centralized
in no longer beautiful. From a financial perspective information technology
departments can no longer spend 80 percent of their time maintaining
existing systems. Instead, business economics are quickly equating existing
legacy systems as barriers to change, and IT departments are moving rapidly
toward breakthrough computing productivity alternatives. As a surprisingly
large alternative, the business community, as confirmed by the business
press, is aggressively moving toward distributed object computing.
u We see that the Internet, and its variants, the intranet and extranet,
have eliminated virtually all of the remaining barriers that previously
forced business to retain its �proprietary islands of computing�.
Consequently, we will see entire networks acting as the computing engine
rather than stand alone platforms.
u The Internet will enable complex interactions among multiple trading
partners in the exchange of business-to-business and consumer-to-business
transactions. (Isn�t this what we now call EDI?)
u Industry is rapidly turning to object data base management systems (OBDMS)
as the replacement for legacy systems.
u Industry focus is on integrated, extended enterprise business solutions,
e.g., supply chain management, industry association adoption of modeling and
object technology, etc. Consider the work of ACORD Corporation, AIAG, UCC,
etc. to look toward improvement opportunities. All offer tremendous
opportunities to utilize reusable components, streamline processes, and
integrate functions across an enterprise.
REQUIREMENTS
The requirements phase is the first step towards building a standard, and is
concerned with building a precise and understandable view of the problem
domain. It brings together business experts, and modeling experts if
modeling is applied to existing standards development. The deliverable is a
problem statement (plus a requirements model if modeling techniques are
applied).
ANALYSIS
The analysis phase brings together the same team of experts. Here the
problem statement (and requirements model, as applicable) is reviewed, and a
greater level of detail is added. This leads to the development of data
requirements (and an analysis model, if applicable). The distinction
between these first two phases is essentially the level of detail that is
applied, and whether or not modeling techniques are used. Note also that
the Requirements and Analysis phases are iterative and will likely be
repeated multiple times until all business and data requirements are
satisfied.
DESIGN
Once the analysis phase has been completed, the key activity in the design
phase is to convert the previously obtained information into an EDI
transaction. The transaction set, then, is the deliverable out of this
process.
IMPLEMENTATION
This phase involves the delivery of the EDI solution to the end user and is
beyond the scope of the ASC X12 standards development process. "
------ XML/edi Group Discussion List ------
Homepage http://www.XMLedi-Group.org
Unsubscribe send email to: [EMAIL PROTECTED]
Leave the subject and body of the message blank
Questions/requests: [EMAIL PROTECTED]
To receive only one message per day (digest format)
send the following message to [EMAIL PROTECTED],
(leave the subject line blank)
digest xmledi-group your-email-address
To join the XML/edi Group complete the form located at:
http://www.xmledi-group.org/xmledigroup/mail1.htm
