balance between expressiveness and simplicity. Too simple a language would limit the breadth of
problems that could be solved; too complex a language would overwhelm the mortal developer. In the case
of unifying existing methods, we also had to be sensitive to the installed base. Make too many changes,
and we would confuse existing users; resist advancing the language, and we would miss the opportunity of
engaging a much broader set of users and of making the language simpler. The UML definition strives to
make the best trade-offs in each of these areas.
The UML effort started officially in October 1994, when Rumbaugh joined Booch at Rational. Our
project's initial focus was the unification of the Booch and OMT methods. The version 0.8 draft of the
Unified Method (as it was then called) was released in October 1995. Around the same time, Jacobson
joined Rational and the scope of the UML project was expanded to incorporate OOSE. Our efforts
resulted in the release of the UML version 0.9 documents in June 1996. Throughout 1996, we invited and
received feedback from the general software engineering community. During this time, it also became
clear that many software organizations saw the UML as strategic to their business. We established a UML
consortium, with several organizations willing to dedicate resources to work toward a strong and complete
UML definition. Those partners contributing to the UML 1.0 definition included Digital Equipment
Corporation, Hewlett-Packard, I-Logix, Intellicorp, IBM, ICON Computing, MCI Systemhouse,
Microsoft, Oracle, Rational, Texas Instruments, and Unisys. This collaboration resulted in the UML 1.0, a
modeling language that was well-defined, expressive, powerful, and applicable to a wide spectrum of
problem domains. UML 1.0 was offered for standardization to the Object Management Group (OMG) in
January 1997, in response to their request for proposal for a standard modeling language.
Between January 1997 and July 1997, the original group of partners was expanded to include virtually all
of the other submitters and contributors of the original OMG response, including Andersen Consulting,
Ericsson, ObjecTime Limited, Platinum Technology, PTech, Reich Technologies, Softeam, Sterling
Software, and Taskon. A semantics task force was formed, led by CrisKobryn of MCI Systemhouse and
administered by Ed Eykholt of Rational, to formalize the UML specification and to integrate the UML
with other standardization efforts. A revised version of the UML (version 1.1) was offered to the OMG for
standardization in July 1997. In September 1997, this version was accepted by the OMG Analysis and
Design Task Force (ADTF) and the OMG Architecture Board and then put up for vote by the entire OMG
membership. UML 1.1 was adopted by the OMG on November 14, 1997.
A successful software organization is one that consistently deploys quality software that meets the needs of
its users. An organization that can develop such software in a timely and predictable fashion, with an
efficient and effective use of resources, both human and material, is one that has a sustainable business.
There's an important implication in this message: The primary product of a development team is not
beautiful documents, world-class meetings, great slogans, or Pulitzer prize— winning lines of
source code. Rather, it is good software that satisfies the evolving needs of its users and the business.
Everything else is secondary.
Unfortunately, many software organizations confuse "secondary" with "irrelevant." To deploy software
that satisfies its intended purpose, you have to meet and engage users in a disciplined fashion, to expose
the real requirements of your system. To develop software of lasting quality, you have to craft a solid
architectural foundation that's resilient to change. To develop software rapidly, efficiently, and
effectively, with a minimum of software scrap and rework, you have to have the right people, the right
tools, and the right focus. To do all this consistently and predictably, with an appreciation for the lifetime
costs of the system, you must have a sound development process that can adapt to the changing needs of
your business and technology.
Modeling is a central part of all the activities that lead up to the deployment of good software. We build
models to communicate the desired structure and behavior of our system. We build models to visualize
and control the system's architecture. We build models to better understand the system we are building,
often exposing opportunities for simplification and reuse. We build models to manage risk.