(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...
Back, Kiseldalens Top Page