(To people outside Europe who are unaware of “corridor
gossip” around here, I’d add that this is an article about views and not about
trademarks or persons; atop of his impressive workload, Dr. Ivar
Jacobson has become closely involved in an intelligent Swedish Alice-bot for UP-users by Jaczone AB, Kista — which is the kind of smart, one-stop
knowledge-delivery technologies stressed in this text).
A letter to the editor,
SIGS Application Development Advisor (June, 2002).
Having worked with methodologies for most of my 25 years of consulting
here —around Kista/Stockholm— I really enjoyed
reading Alan O'Callaghan’s column, What
comes UP must come down (remember Canadian D.C. Thomas singing Spinning
Wheel with BS&T and Swede George Wadenius on gt. — as can be seen,
Swedes often co-launch novel approaches, thus generating many new abbreviations
:-)
I agree on rather many points, although not on all. The roots of Objectory and the Unified Process were in Ericsson’s
AXE-project back in the 70-ies and 80-ies. It was the largest one in
Scandinavia's industrial R&D history, involving at peak 1 000+ skilled
technical engineers. Ahead of competitors, they developed a new large software
package replacing traditional hardware functionality (a starting point of what
Steve Ballmer later called “the most wired & wireless place on the
planet”). Completing a project like that with a population smaller than
London’s required subsystems with well-defined interfaces and a
specialization/industrialization of the development process. Also,
Furthermore, Swedish industrialism was triggered by "industrial
improvements" of creative inventions from outside (quite similar to
"Japan Inc., 1980"): safe cars - Volvo, modular lorries - Scania Trucks, usable
telephones - Lars M.Ericsson etc; the common
denominator: the industrial approach to new things was part of the invention. Consequently,
The Swedish Agency for Public Management —who sets the IT-agenda of Sweden’s
huge public sector— recommends UP without stressing (or sometimes, mentioning
at all) that UP relies on a good knowledge of UML (whereas UML works with any
up-to-date process). Roughly, that’s building the highway without mentioning
the word vehicle (no Bimbo-jokes, please). Without good OO
& UML skills in place, a UP project will most likely arrive at odd designs…
As UP steps downmarket, from 1000+ projects to
10+, most people might argue it's too heavyweight.
UP-people often point out the tradeoff between well-known/well-defined problems
(where sometimes XP might be enough) and poorly-known/hazy problems (where you
employ a more formal solving process).
Here, UP often wins since few problems are well-known upfront.
Nevertheless, wherever you are on that scale, the “engine” powering the
process is important, too; there’s thus another tradeoff between a formal,
externally managed, generalist process (powered by workflows, organizing the
steps) and a distributed, specialist process (powered by tools and a smart aid,
and —above all— by components). Also, most people agree that systems
development is “same as, except…” which boils down to CBD.
UP-users would argue that a “light” process puts less effort into the “excepts” (the small, poorly-known or hazy parts), but the
objective of CBD is to cut the size and the number of “excepts”.
Here, “light” processes often win by simplifying the creative work
without organizing its steps in detail.
As UP has both “light” and “heavy” ingredients, for those giving UP a
little thought there’s a scale between following UP point by point or using an
UP-book as just a new influence to the company’s current practice. In UML Xtra
Light - How to Specify Your SW Requirements (with Barry McGibbon),
we put forward a lightweight view and we suggest processes to become more
component driven ("a ready-served table" for the developer, making
things easier). UP’s idea of reusing some concepts from other sectors of
industry is a good one. However, rather than workflows and the risk of
mechanization/deskilling, one shall borrow knowledge technologies, automation
and Knowledge Management from R&D processes of other knowledge
industries. Components and configurators seem to be a
key tool of KM in this context. We also compare the current standardization
work (OMG etc.) to developments in the
knowledge industry of European history: the classical period in music where
readymade components were used in large divertimentos,
and common architectural templates such as a concerto or a symphony were used
throughout; nevertheless, the whole business still remained novel and extremely
creative! Therefore, standards and components shall be employed to boost creativity
and to switch focus from detail to architectures; I don't see any contradiction
here. On the other hand, a flow-driven, heavyweight process puts creativity at
risk; there’s also the risk of a perfect solution to the wrong problem (SW
resembles neither bakery nor simple consumer insurance)...
Also, if the OMG succeeds with the Model
Driven Architecture (Platform Independent Model in UML generated into Platform
Specific Model in a UML-profile generated into code) and with the UML 2.0
(action spec - whatever the final notation for that), the boundary between
models and code will become quite fuzzy (I wouldn't say in the 1980-ies that
the assembler or the .exe files were the code). Therefore, the “eXtreme view” of the code as the "real thing"
—and opposed to the model— might change over time, provided of course UML-tools
usable/smart enough. All things considered, the OMG’s
post-industrialist approach seems more appealing than both XP and the
industrial, mechanized approach implied in the UP of today; why not practice
the business automation and KM we’re preaching to our stakeholders?
Business-process pioneers Mike Hammer and Bjorn-Erik Willoch
both likened reorganizing a hierarchy to reshuffling the chairs aboard Titanic.
In most knowledge industries however, I’m afraid that an excessive emphasis on
workflows would be a rather thin
improvement when compared to reorganization...
Milan Kratochvil
Back, Kiseldalens
Top Page