UMM is based in UML, which means it's about modeling the information aspects of businesses. This Wikipedia entry seems underdeveloped, so the description should taken with a grain of salt. It does point out that UMM attempts to decouple from implementation technologies such as Web Services and ebXML.
UN/CEFACT's Modeling Methodology, commonly known as UMM is a modeling methodology which is developed by UN/CEFACT - United Nations Center for Trade Facilitation and Electronic Business.
Goal of UMM
The primary goal of UMM is to caputure business requirements of inter-organizational business processes. These requirements result in a platform independent UMM model. The UMM model can then be used to derive deployment artifacts for the IT systems of the participating business partners.
UMM at a glance
UMM enables to capture business knowledge independent of the underlying implementation technology, like Web Services or ebXML. The goal is to specify a global choreography of a business collaboration serving as an "agreement" between the participating partners in the respective collaboration. Each business partner derives in turn its local choreography, enabling the configuration of the business partner's system for the use within a service oriented architecture ( SOA).
daviding says: If software engineering is engineering, then we should also think about service engineering as engineering. This article also helps to draw some lines between engineering as applied science, and more theoretical forms of science, both in the domain of services systems and human systems.
Gerald Weinberg once wrote, "If software engineering truly is engineering, then it ought to be able to learn from the evolution of other engineering disciplines." Robert Glass and his colleagues provocatively evaluated how often software engineering literature does this.4 They concluded that the literature relies heavily on software anecdotes and draws very lightly from other engineering fields. Walter Tichy found that fewer than 50% of the published software engineering papers tested their hypotheses, compared to 90% in most other fields.
So software engineering may suffer from our habit of paying too little attention to how other engineers do engineering. In a recent extensive study of practices engineers expect explicitly or tacitly, Riehle found six we do not do well.
Predictable outcomes (principle of least surprise). [....]
Design metrics, including design to tolerances. [....]
Failure tolerance. [....]
Separation of design from implementation. [....]
Reconciliation of conflicting forces and constraints. [....]
Adapting to changing environments. [....]
Group items tagged 
