Unified Process

Essential Unified Process by Ivar Jacobson

After two very intense days in Ottawa I am on my way to China, Taiwan and Korea. Two intense but very memorable days. In Ottawa I gave two talks on the Essential Unified Process, the first to Statistics Canada while the second was a public seminar arranged by IBM Rational Canada.

The welcome I got at Statistics Canada was mind-blowing. Andrew Konecny who organized the event compared it to when Rolling Stones visited Ottawa in the summer of 2005: Sold Out. Around 250 persons attended the seminar and the introduction that Andrew gave was most memorable and made me feel very welcome. Every attendant got a black T-shirt with the logos of Jaczone, IBM Rational and Ivar Jacobson Consulting on the front and a listing of all my postcards on the back. It was really fun.

I presented the Essential Unified Process. So what is it?

The Essential Unified Process stands on the shoulders of modern software development practices. It is a fresh start integrating successful practices from three camps: the unified process camp, the agile methods camp and the process maturity camp. Each of them contributes different capabilities: structure, agility and process improvement.

The Essential Unified Process is very different from other processes or methods in how it is presented. It relies in many ways on a new idea: Separation of Concerns (SOC or aspect-oriented thinking). When you apply this general idea it will be dramatically simpler to work. It will be much easier and much more pleasant to select your tailor-made software process. Most important, it will be more natural and intuitive to plan and execute a software project. To make this concrete let me describe a number of situation where we have applied the idea of SOC:

  1. The Essential Unified Process separates the essentials from the non-essentials. This allows us to create a core lightweight process with unprecedented growth potential. We have learnt over the years that very few people really read process materials whether it is in a book or on the web. Therefore it doesn’t make sense to give them a lot. Instead, provide the real essence and let them learn the rest the way they want. Some may want to learn it by studying and there are a lot of articles and books available to do that. Some will learn by working with people who have already gained the knowledge. The effect of this separation is that the process will be very light and easy to adopt and change.
  2. Each practice is kept separate from other practices. The Essential Unified Process comes with the essentials of our five foundation practices:
    1. Component Based Development,
    2. Model-Driven Development,
    3. Iterative and Incremental Development,
    4. Architecture-Centric Development and
    5. Use-Case Driven Development.

These practices have been used in 1000s of projects and proved to be very successful. By keeping them separate, we can simplify the process description dramatically. The process description is presented as a set of individual practices. Each such practice can be developed, adopted and applied separately from the other practices. This is a significant difference compared to the Unified Process where all practices are intertwined. Moreover, you can easily select only the practices you need without having to deselect activities and artefacts. You just select the practices you want and compose them with your already existing process.

  1. You can easily separate elements from your existing process from the elements of the Essential Unified Process. This allows you to improve what you already have, one practice at a time in an evolutionary way. You start from a generic platform and describe your own process using a very simple technique inspired by the game industry. Based on this we can add our practices without requiring a revolutionary adoption of all our practices. You take what you need and what you think your organization can adopt without taking any severe risks.
  2. It separates two different views of the process: the process authors’ view and the software developers’ view. In the past processes have almost entirely focused on the authors’ needs. The Essential Unified Process prioritizes the developers’ perspective. It uses techniques from the game industry to develop, teach, apply and use the process to make it lightweight and agile. And, I promise, much more fun.
  3. It separates explicit knowledge from tacit knowledge in a balanced way. Tacit knowledge is knowledge you acquired one way or the other – you have it in your “head”. Explicit knowledge exists in the form of descriptions made available to you. In the past the Unified Process tried to capture all knowledge in explicit form. Though this is a good ambition, it makes the process heavy. The Essential Unified Process makes only the essentials explicit. The rest is either tacit or referenced from the essentials. However, the most elegant form of dealing with knowledge is to deliver it through intelligent agents when needed – this is what we call a smart process. As you all know, WayPointer is the first commercial product that makes smart process available.
  4. It is prepared to separate creative work from no-brain work. This will allow developers to spend their time on what humans are good at – being creative – and leave the no-brain work to intelligent agents. Once again, this is made possible with WayPointer.

Our long term vision for the Essential Unified Process and WayPointer is to move from a ‘process’ era when everyone is forced to think about process to an ‘invisible process’ era, a time when we don’t talk specifically about process but take it as a given.

Now you may wonder: Does WayPointer support the Essential Unified Process? The answer is indisputably; YES! WayPointer already today supports the core of the foundation practices. Over time as the Essential Unified Process grows WayPointer support will grow too. As an example, the first released practice, “Use Case Driven development” is fully supported in the upcoming release of WayPointer. 

Complexity and Unified Process by Ivar Jacobson

September 30, 2004 

Minneapolis was the very first city on the US main land that I visited. In 1981 a delegation from Ericsson went here to evaluate some technology from Sperry-Univac. I don’t remember more than that I got very bad flu on the flight over, and that I stayed in bed for most of my visit. Well, not entirely, because one evening our host took us out to a dancing-place. For a couple of hours my flu was gone, and I had fun.

This time I came to Minneapolis to meet a customer that is deploying UP broadly. I was also invited to speak at the Rational User Group in the Twin Cities. This was a nice event with quite a large number of people. After my presentation, some people took me out for dinner. During the dinner I told them about my dancing experience 23 years ago. I asked: “How is it today, do you still have good dancing places?” “Sure, let’s show you.”

Thus we left the restaurant, and spent the next hour walking from place to place to check out the dancing scene. Place after place was either closed or there was a big guy in front of the entrance, saying: “You are not going to like it!” We were not young enough.

However, eventually we found a place. The dancing hadn’t started yet, so we watched a show with pretty girls. A tall, big woman with a mike came up to us and interviewed us. At the end she asked “Are you all straight? Or, do you want to try something new?” We were at a gay bar. The pretty girls were boys. The only place open for dancing was a gay bar. Well, we didn’t feel uncomfortable. People had fun, and everyone respected each other so we enjoyed the music and the drinks. However, it is no overstatement that we didn’t dance much.

- o -

In my latest postcard from Boston, I explained why I think agile methods have become popular. It has happened because we didn’t do a good job with UP (or other defined processes) and tools. This created discontent and we got agile methods -- or populistic methods. Agile methods don’t provide any defined knowledge. Instead they rely on "tacit knowledge". You can do it with whatever knowledge you have. This was of course also very popular.

However, the basis for this discontent will soon be gone. It is just a question of time, at the most two years, before we will have substantially better tools from leading tool vendors, and they will be better integrated. On top of them we will get intelligent tools (WayPointer is such a tool) that remove a lot of the no-brain work that programmers spend their time on today. These tools will make it impossible for ‘tacit knowledge’-based methods (read agile methods) to compete in terms of agility. They will be even less competitive when it comes to quality in measures such as productivity, quality, time-to-market. Quality includes good architecture and design.

Moreover, the complexity of the UP will be eliminated through these intelligent tools. Let me take you through this in smaller steps:

  • Why is UP complex today?
    One reason is that UP is a rich knowledgebase. This knowledgebase defines a set of best practices, and their interrelation. The goal is to have all the best practices that a team may need available easily.
  • What is the problem with this knowledgebase?
    The problem is that it can be overwhelming. This was never a surprise to me. I have known for many years that this is how people perceive the UP. I have been crystal clear for all these years that the only way to really implement UP is through substantial training and mentoring. My assumption was that only a small fraction of the software developers would be able to adopt UP properly. I have been clear when talking to people interested in UP that if they are NOT willing to do these investments, they shouldn’t even bother to think about UP.

Another problem is that even if UP is rich it is not rich enough. This may sound as a paradox, but it is not. I believe that one of the major problems with UP is that it is generic. Since UP is a book, it can’t be specific to a particular application or domain. Special cases or exceptions have to be treated very superficially. Otherwise no one would read it. This means that the process is explained generically and that examples and such probably come from a problem space of no interest to a particular reader. Examples and advice must be particular and context sensitive to be useful. However, this problem can also be solved.

  • Why did we then develop this rich knowledgebase?
    The goal has all the time been to achieve agility + more. My belief is that the more people know about software best practices, the more agile they will be able to work. However, I also wanted more as I will tell in a minute.
  • How can we help people adopt and apply this rich knowledgebase easily?
    Through a completely new class of tools, based on intelligent agents, the knowledgebase in UP can be served in very small chunks. The minimum knowledge needed in a particular detailed context will be served. Not only so, it is presented in context of the actual system that the user works with, instead of generically. The rules in UP may trigger and defects may be found, reuse may be suggested, next steps proposed, solutions carried out. The tools will serve as a motor for each individual and for the team as a whole. WayPointer is for the time being the only such tool. With such tools, the programmer can use his or her time to what is creative instead of doing "no-brain work". Today 80% of the programmer’s time is spent on doing no-brain work. This number is based on projects using agile-like (or code centric) methods. With WayPointer this time is reduced dramatically.

We all want agility. The goal is the same for all of us. However we have different ways of getting there. The biggest difference (and maybe the only really important reason) is that agile methods assume tacit knowledge, whereas UP assumes explicit (defined) knowledge served through intelligent tools to make the software process active.

Why is explicit knowledge so important?
Moreover, I strongly believe that good software is developed by people being smart, and that you can only be smart by having critical knowledge – and of course having this knowledge turned into experience and skills. In our world the critical knowledge is on best practices in software development. This requires explicit knowledge available to the whole team; tacit, unstructured knowledge which only is in the heads of individuals is not sufficient. This is why UP serves a very important role; it includes much of the critical knowledge you need and intelligent tools can serve this knowledge when you need it.

I believe that it is not enough to be agile. The term agile doesn’t imply anything about whether the software is good or not. I have always worked to get good software (good in terms of all measures including good architecture, good test cases, good interfaces, good components, etc.). Furthermore, it has all the time been my belief that if you know how to make good software, you can always figure out how to make it fast or agile. This is what we have been doing with UP + intelligent tools. Thus instead of talking about being agile or about agile methods, I would rather talk about being smart and smart methods. Smart means agile, but also much more. It means all the things we need to get good software. UP with intelligent tools helps you to become smart.

Next year, the world will be looking for a new buzzword. Maybe I should launch the term Smart Methods. Maybe I should give a keynote with the subject: "Beyond Agile: Smart". Trust that Smart Methods are building on top of defined knowledge with smart agents.

What do you think?  

Page 2 of 212