September 25, 2004

Coming back after many years to a place where you previously have lived is a special feeling. I spent a year at MIT 1983-84 as a visiting scientist. I was awarded a grant from the Marcus Wallenberg Foundation in Sweden to study abroad for one year, and I spent this year with my whole family in Boston. This was one of my most important years from a career point of view. I learnt to know a lot of people, some of them were professors at MIT. They were important references for me when I started my company Objectory in 1987.

Thus, this week when I attended the Software Development Best Practices conference in Boston, I also decided to visit MIT and see if I would find any of my old colleagues. I went to the new computer science labs which are located in a new building with a very impressive and advanced architecture. I will not attempt to describe it. I looked for names from my year at MIT. And I went to their offices to say hello, but most of them were out. I found Hal Abelson, who was one of the two teachers of the famous class: Structure and Interpretation of Computer Programs. That was and still is the best class I ever have taken. It was so great that I actually brought it back to Sweden as VCR tapes and it was taught at two universities in Sweden for some years. We were chatting for a while, he recognized me very well. “You were working with usability, right”, probably thinking about use cases. Anyway, I didn’t dig deeper into that.

At the SD Best Practices conference, I gave a keynote on Active Software. The last couple of years I have promoted this new idea as one of the biggest mega-trends on the horizon. A book is underway, and I have also devoted some previous postcards to this idea.

However, I am not going to talk about my keynote in this postcard. Instead I will devote this postcard to agile methods. These have become so popular for interesting reasons which I can’t resist reflect on.

Many talks had the term agile in the heading. Many old talks have been modified to motivate the term. Every author and presenter needs to make clear they are agile. So they join the club. I have joined the club too. I wrote a paper at the end of 2001 with the title: A resounding Yes to agile processes – but also to more. Of course we should be agile, there is absolutely no conflict. For me this has always been the goal of everything I have been fighting for. However, we have different ways of getting there.

Before getting there, let us look at the values of the Agile Alliance:

1. Individuals and interactions over process
2. Working software over comprehensive documentation
3. Customer Collaboration over contract negotiation
4. Responding to change over following a plan

Who can disagree with that?

1. Of course, people are more important than any book, even if it is a big book on the web. Books don’t produce software. However, knowledge is important to make people successful.
2. Of course, with working code your customer is happy, even if the design and architecture is expressed in UML. However, working code needs to be understood and maintained after the initial team developed it.
3. Of course, software requirements can’t be specified upfront. They grow as people work on growing and experiencing the software iteration by iteration.
4. Of course, detailed planning at the outset of the project is cheating the customer. Software development is a change process and the project should be smart about accommodating changes.

Of course, we all agree with that. So what is then the difference? There is a huge difference, but before answering that question I will give my opinion on why agile methods have become so popular? There are several reasons:

1. UP (in particular RUP which is the IBM Rational version of Unified Process) has become too large and complex. This is true, but it also leads to a misunderstanding. It is true that UP is large and comprehensive, but the intention was never that everyone should learn everything about UP. Instead, a small subset of UP relevant for a project is selected, and this is what the project members will be trained in. Thanks to a new class of tools based on intelligent agents, the problem of UP being overwhelming will soon be history. WayPointer is such a tool.
2. No really good tools from major vendors. We tend to forget that the modern software tool industry is less than ten years old. We have not really yet seen a tool environment with seamlessly integrated tools. My old Objectory tool from 1994 had a lot of features and great integration between different models not yet seen in any other tools. The problem was that the tool was developed in Smalltalk and that never became a commercial platform. However, we will very soon see a new generation of tools coming to our market place.

This was of course a very natural basis to grow discontent and there was room for something new. That new had to be something else than technology, because UP had that pretty well covered. The truth is that Agile methods have not contributed anything exciting and original from a technology point of view. Test first design is maybe the most interesting new idea, but it is similar to use case driven tests. From a technology perspective most ideas in agile methods are 20-30 years old.

So again, the new had to be about something else than technology for it to be missing in RUP (or rather perceived as missing as much of the debate is a matter of perception).

1. Agile methods have added something new.
   They have added best practices on the so called soft factors in software development, such as pair programming, on-site customer, 40 hours work week and so on. We programmers have been drowning in technology and our work environment has had low priority. We like this new interest for the soft factors.

However, this in it self wouldn’t have made agile methods popular. I believe that the most important reasons for the popularity of agile methods are two:

1. Many experienced developers felt side-stepped by the success of UP. They felt that their hard earned experience became less valued by management. This is of course a management mistake as a successful process adoption requires both knowledge (UP) and experience (people). Successful adoption typically happens when the most experienced architects in an organization are part of the change effort. Leaving them on the side-line is begging for problems.
2. Another reason that these methods have become so popular is that they don’t require any specific or defined knowledge. Agile methods stand for "tacit knowledge". For experienced people this is of course exactly what they want, no one can tell them what to do. They can accept some general principles but no detailed suggestions are popular. For the inexperienced people, this is of course wonderful. They can also do it with whatever knowledge they have. One uses what one knows, quite simple.

In reality agile methods require very competent programmers to become successful. This is clearly expressed by its originators. In fact they require more knowledge than what a project using the UP requires. The problem is of course that there are not enough good programmers around the world. And those who are that good are very attractive, so they move around quite extensively. This is very different with UP. Usually once people have used UP for a project, the project is less dependent on any individuals (still individuals are important). The UP provides a lot of explicit knowledge, and it doesn’t rely on tacit knowledge only. We can educate in UP to a deep degree, but you can’t educate in tacit knowledge.

In a way I think these methods that now have introduced a concept for tacit, unknown, unstructured or undefined knowledge, takes us back 25-30 years. Let me explain what I mean more explicitly.

1. In the beginning there was chaos.
2. UP was meant to solve/control 1. Unfortunately it has had some negative side-effects as we discussed earlier.
3. Agile methods are removing the side effects by moving back towards 1.
4. We think that we instead should remove the side-effects by moving forward to third generation processes/active processes., i.e., instead of going back to generation 1.5.

Thus so far the software industry can be described as based on tacit knowledge. As a result we have got a poor reputation for quality of software. This distinguishes the software industry from other modern engineering disciplines. And those are not based on tacit knowledge! We too can’t continue base our future on tacit knowledge.

By now you know why I think agile methods have become popular. It has happened because we didn’t do a good job with UP and tools. This created discontent and was a good ground for making excellent programmers raise there voice and for young people to feel that they could do it without a lot of knowledge. Thus I view agile methods as populist methods. In my next postcard, I will describe how these approaches if not changed dramatically will again loose in popularity because a new class of tools will make them anti-agile in comparison with what will come. What will come will be agility in many more dimensions than today. I will talk about what will come next. Beyond Agile!  

July 23, 2004

Another Rational User Conference has just been concluded. Since 1997 I have attended every one of them, now eight conferences. There were many good talks, but I had no time to attend more than the opening keynote by Mike Devlin. Instead my days were filled by meeting people. Many had heard about my recent adventures in Singapore and Korea and wanted to understand where I am heading. Basically, I see a huge need to help people around the world to apply best practices of software development. Even if we have developed the RUP, we have not been successful in getting people to adopt it and apply it. One of the consequences of this “failure” is that agile methods like XP have become popular. I want to change that, and since RUP not yet has penetrated East Asia, this is a good place to start.

My keynote this year was titled “What you didn’t know about RUP”. So this talk was about the secrets of RUP. Actually a lot of people, including RUP evangelists, don’t know about these secrets. One of the secrets is that RUP or the Unified Process in general, is agile and is in fact becoming increasingly agile as time goes by. I feel that we have not succeeded in explaining why it is so. I took it as my mission to do so.

First I developed some vocabulary to explain why RUP already is agile. When people talk about a process being light or heavy, they actually mean that the process definition (the “book”) is light or heavy. They don’t talk about the process in the meaning of what actually is done and created when you run a project. So we actually have two concepts to discuss, the process definition (PD) and the executing process (P). What we really care about is that the P is agile and not really that the PD is agile.

Thus we can have a light PD (a book) but since it doesn’t explain much it is not of much support to the team that runs a project. They will have to invent the particulars of the process as they go. This may slow down the project substantially, something I have experienced in many projects. Thus a light PD frequently result in a heavy P.

Also, although a rich PD may require that people spend time upfront to learn what to do; it may result in that the P works very smoothly. Everyone in the team knows what to do, when to do it and how to do it. Thus a rich PD frequently results in an agile P. I have seen this happen many times in serious commercial software development.

So far most people agree with me. So let us now talk about the executing P and how to make it agile. Today, to get a PD like RUP to be used in a project, it takes three things:

1. A subset of the PD has to be chosen and maybe some additional process steps will be added. There are good tools to do so, but still this slows down the project. To be able to select what to use you need to know all that can be used. Most companies don’t have the luxury of time and competence to do that. Makes the P heavy!
2. Once a proper PD has been created, it has to be adopted. This means that people have to learn it, they need to get it into their heads. This requires training which takes time. Makes the P heavy.
3. Finally, while running a project, the PD must be applied consistently and effectively. This means that people need to know what to do, when and how. Usually, people can’t do this by themselves, it is a far too big step to go directly from the classroom to your office and do useful things in a productive manner. Thus projects need mentors. Makes the P heavy.

Why would people take on all this work (to define and learn a PD) to develop software? There is only one good reason. We know that people will develop better software, better software from all perspectives.

What have we done to make RUP implementations overcome these difficulties?

1. Now and even more in the years to come, I believe we will see a number of predefined variants of RUP become available. We will have ready-made light PDs, and we will have heavy PDs for product-line developments. This makes RUP more agile. You start using the PD that works for you.
2. With RUP comes a lot of training material. RUP comes with a set of very systematic models, enforcing traceability and consistency between them. This makes it very systematic compared to the light methods, and consequently we can train developers in a systematic way to understand good software development practices. We can train people to become competent. Still, yet training needs to be done in a more agile way.
3. Good software and software developed in an agile way can only be created by smart people. You can only be smart if you are competent. Since RUP helps you to become competent, you also have the preconditions to become smart which helps you to become more agile in applying best practices.

However, we won’t stop here. Already when I started the development of what became RUP back in 1987, I knew we need to take one step more. We need to make the process active and executable, not just a dead book. We need to support the developer with “intelligent” tools. This is why we started Jaczone and developed WayPointer. WayPointer will help us make a big step forward in agility:

1. One day I believe WayPointer will help configure the PD while you are working. WayPointer will recognize what the team is doing and present a PD that is just enough of process. For a small project it will be a light version of RUP. For a larger project a richer version of RUP will be provided. This will happen as you go, without having a heavy upfront configuration activity. Isn’t this agile?
2. With WayPointer, training doesn’t happen in classrooms but while you work. Thus no heavy training before starting, instead “train as you work”. Very agile, right?
3. Finally, WayPointer will help you to also apply the PD. It is very context sensitive, so it can give proposals of what to do in every micro step as you work. It can facilitate the doing of many activities which today have to be done manually, but which should follow one another in a natural way. It speeds up the whole project in a substantial way. This is what I would call agile, and it far exceeds what you can do with what is called agile methods.

To summarize, agility can only be delivered by people, people that are smart. People can only be smart if they have knowledge. Knowledge needs to be shared between the members of the team; otherwise it will slow down the team. Most of the knowledge they need are rules about best practices and implementation technologies. Most of these rules can be captured in a “tool” like RUP, but to achieve substantial agility, these rules should be manifest in another more intelligent tool, making the process active. In that way there is no limit to how agile we will be developing software in the years to come. 

July 3, 2004

After three days in St. Petersburg I am now on my way to the city where I grew up and graduated from high school. The city is Ystad located in the very south of Sweden at the Baltic Sea. Every year I spend a week in Ystad to meet old friends, friends I have had since I was 7-18 years old.

To my surprise there are not yet any major software conferences in Russia. Conferences are organized by universities or by international companies like SUN, Microsoft, etc. I gave a talk at the 5th international scientific and technical conference and got a good impression of what people worked with and what was presented. Then I met with academic leaders with a strong network in the software industry. I spent a day at St. Petersburg State University as a guest of Professor Andrey Terekhov.

That day turned out to be very interesting. For many years I have been wanting to develop process and tools to reengineer old software systems to become modern component based software, modeled with UML and implemented on modern platforms such as J2EE or .NET. Andrey told me that he had been working with a company in the US that sells tools and services to reengineer from the bottom and up. I know the company very well. In fact, a few years ago, they offered me to become a member of their advisory board. And now I met the guy who developed their tools.

The reason I didn’t accept the offer was that I didn’t see that their design would be generic enough. They had their own modelling technique, their own process and their own tools. My approach is the one I wrote about 1991 in my OOPSLA’91 paper on Reengineering Old Systems to an Object-Oriented Architecture. However, I liked their low level reverse engineering tools. And these tools were developed by Andrey and his company. I think there is a huge demand to reengineer legacy systems, particularly those written in COBOL or PL/1. I have many customers that would be willing to invest in such tools. I am now thinking about if and how to do this. Thus, the meeting with Professor Andrey Terekhov and his team was really refreshing.

During my stay in St. Petersburg, I enjoyed sightseeing and good restaurants. Elena Ivanova arranged my whole visit and she and her son were great guides. Of course, the Ermitage was very interesting. Also just walking around in the city during the beautiful White Nights and along the Neva River was very relaxing and romantic. And I love Beluga caviar. I had caviar with small vodka every night, and carried home as much as you are allowed. The price for 213 g top quality caviar was just 50 USD. At home I would have had to pay more than 1,000 USD. Maybe we are in the wrong business?  

June 6, 2004

Often I am asked which my favourite country is. In addition to Sweden, where I grew up and have family, I have many favourite countries. Most countries have something that makes me feel happy and at home. Singapore is certainly one of them.

Last Thursday I held a seminar in Singapore for more than 200 persons and launched my latest adventure – the forming of a new company, Ivar Jacobson Pte Ltd. We will help organizations to implement the best practices of the unified process. We will also expand the set of best practices, not just help with the existing ones. For instance we will train and mentor organizations in aspect-oriented software development and active software development (using intelligent agents).

One of the best practices is about aspects. The first time I heard the term aspect-oriented programming was back in 1997. I immediately saw it as an interesting technology, but at the time I couldn’t take a serious look at. I was working on the first version of UML, I was working on getting RUP right and I was initiating an effort on active software processes – actually what now has resulted in Jaczone WayPointer. When I finally had time to take a good look at aspects it was in September 2002. I downloaded a lot of papers and studied them for a couple of days. After that I contacted Harold Ossher at IBM Research and Karl Lieberherr at North Eastern University in Boston. They are two of the leaders in this space. The most well-known guy on aspects is Gregor Kizcales. I tried to get his attention as well, but he was too busy at the moment.

In November 2002, I visited the IBM folks and spent a day with them understanding their work. After the meeting I was very impressed and excited about what they had done. I left their office, rushed to Newark airport; I had to run to the gate. This is normal. I was on my way to Stockholm. When I was seated in the plane, I ordered some champagne and began to relax and think a little. Suddenly, it struck me. Didn’t I do something similar before? Didn’t I write a paper on the same subject at OOPSLA’86 – the very first OOPSLA conference?

When I came to Stockholm, I started to hunt for the paper. It was a paper that discussed a topic that I mentioned as future work in my Ph. D. thesis from 1985. However, I got no interest for the ideas in the paper, so I decided to leave the subject. I felt it was too early to push those ideas. So I just forgot about it. My work on component-based development with objects and use cases was so successful so there was no room for new inventions. However, now I wanted to find the paper, I went to the publisher’s web site. I found the paper. I had to pay $95 to download it! My own paper!!!

The title of the paper is “Language Support for Changeable Large Real Time Systems”. In that paper I introduced several concepts – existion which represents a base, extension which represents separate functionality which you want to add to the existion. Instead of modifying the existion to invoke an extension, we used a mechanism to allow the extension to add behaviour into the existion. Thus from the perspective of the existion, no modification was needed. This means that you can add extensions after extensions without breaking the existion. The key idea is this: by keeping extensions separate from the base from the developer’s perspective, the system is much easier to understand, maintain and extend.

The basic idea sounded very much like what aspect orientation research is trying to achieve. But I needed confirmation. Two hours after I downloaded the paper I sent it to Karl Lieberherr. He responded: “Wow Ivar, this is an early paper on aspect-orientation”. He asked me if I had anything more. Since, I throw away everything I don’t work with; my first thought was that there was nothing more. However, I was excited, and my thoughts went back to the time before the paper. My memory asked me, “Didn’t you file a patent for a similar work?”

The patent was filed in 1981 and I made it as an employee of Ericsson. I called the Ericsson patent department and asked if they had saved the application. After a week they came back. I got a copy of the application – in Swedish. The application used typical patent language, so I had actually never understood it. It was written by a patent engineer. However, attached to the application was an internal Ericsson paper that described the whole idea in a couple of pages. It was a quite detailed paper with a practical example. This paper was also in Swedish. I had both documents translated by a professional translator into English, and you can find them on www.ivarjacobson.com (look for published papers and aspect-oriented software development).

The patent was about what we called a sequence variator. It works at the micro-program instruction level. The highlight of the design is this: A program has a list of instructions. To each instruction, I added a flag. If this flag is turned on, it means that there is an extension that needs to be executed at this point. The sequence variator will fetch instructions from the extension, and thereafter resume at the next instruction. This branching is taken care of by the sequence variator. The developer of the original instructions do not need to code branch statements.

Alright, to make a long story short, Karl Lieberherr and Harold Ossher liked my early work. Karl wrote an email where he compared my early work with modern aspect-orientation: Extension ˜ Aspect, extension point ˜ join point, etc. I then wrote a couple of papers on aspects and use cases (see www.jaczone.com/papers) , and I was a result invited to give keynote talks at international conferences on aspect orientation. I was very happy being recognized for my early work. Now I am working on a book on aspects and use cases together with my colleague Pan-Wei Ng from Singapore. You will soon see this book in bookstores. I will be very happy if you buy it :-). I will be even happier if you read it (because this is not the same) :-). You can also ask me for a presentation. After all, I am in the business of promoting best practices in software development.

April 12, 2004:  Happy Easter! 

I hope you have had a great Easter holiday.  I spent my holiday in Verbier, Switzerland.  This is the place I call home.  It is a small village with just a few thousand residents, high up in the Alps.  During the skiing season the village is filled with people from all around the world.  I love it here as I am a passionate skier and hiker.  In the summertime this place is a paradise for hikers.  Moreover, at the end of July every year one of the greatest music festivals in the world takes place here.  The village has lots of activities and it offers great food and wine. And it has great connections to the rest of world, both in transportation and telecommunication.

I have nothing serious for you today.  I can’t think about serious things this wonderful day.  Instead I have been skiing all day.  The weather has been fantastic, sunny and clear skies. The snow perfect, not wet as is quite normal for this time of the year.  After a full week of skiing I went to the ski-rental to return my skis.  I will go on my next trip (to Seoul) the day after tomorrow, and I know I won’t be able to ski anymore.

I enter the ski-rental, greet the people happily and tell them I want to return my skis.  They look happy but a bit surprised. “But those skis are not our skis”, the renter says.  “What?” I scream. I look at the skis and immediately realize that I have someone else’s skis.  I feel awful.  What have I done?  When did it happen?  

-- “Oh, I know, it must have happened after lunch, 3 hours ago, when I went out from the restaurant at the top.  I must have taken the wrong skis, they look very similar.” 

After some discussion we agree that I should go up to the restaurant and see if my skis are still there.  Thus I take a long walk in ski boots carrying someone else’s skis.  Every skier knows how fun that is.  After a two hundred meter walk I take the cable car up to the mid-mountain -- Ruinette.  It takes about 12 minutes.  Then I take another cable car to the top – Les Attiles – this takes another 10 minutes.

With high expectations I walk over to the restaurant.  I look for my skis.  There are less skis now but still some 20-30 pairs.  I walk up to the spot where I had put my skis…and there in the snow, lying down -- are my skis!  I become happy as a bird.  I found my skis!  

Now, what should I do with the other skis? The ones I had involuntarily stolen.  It was more than 3 hours since the mix-up.  Would the owner expect the skis to come back?  After some thinking I decides to leave the skis where I first took them and go to the police in the village and tell them my story.  After all it was just a pair of skis.  Well, I know how I would have felt if I came out from a restaurant and my skis were stolen.  I could only hope for that the owner was smaller than me. J

Thus, I decide to put on my original rental skis and ski all the way down.  I try step into them, but it doesn’t work well at all.  After a couple of attempts, I understand that these skis are not mine.  They belong to someone else.  The skis are of exactly the same type as mine, and they come from the same ski-rental.  Unbelievable!  Slowly, I start to understand the situation.  There must be three ski owners involved.  The guy, who owned the skis I just found in the snow, had of course taken my skis.  The third owner is the poor guy whose skis I took.

However, to be sure to not make another mistake, I take one of the skis that I, a few minutes ago, thought were mine and walk into the restaurant.  I go from table to table and ask every guest, if he or she is the owner of the skis that were similar to mine.  Can you imagine what it takes to do that?  I felt like an idiot asking everyone: “Is this your ski?”  People start to make jokes.  They are laughing and smiling.  After having asked everyone without anyone recognizing the ski, I feel certain that my theory about three owners is right.  I take the skis that were similar to mine, but not mine, on my shoulders and go to the cable car to go down.

On my way a really big guy stops me and says “Hey buddy, where are you going with my skis?”  I am chocked.  I start to tell my story.  As you can imagine, it is not easy to know where to start.  However, I think I succeeded in convincing him that I was not trying to steal his skis.  I apologize so much and give him his skis.

So, I am back at square one.  Someone has taken my skis and I have taken his skis.  Now I take a bold decision.  I will go back with the wrong skis to the ski-rental and hope that my original skis are returned – and the guy who returned my skis will get his skis back.  Maybe I will see an end to this story.

Thus I go all the way down using the cable cars, first to Ruinette and then down to the village.  I walk the two hundred meters down to the ski-rental.  Halfway, I meet a young lady who looks at me with an interested look.  When I come close I understand she doesn’t look at me but at my stolen skis.  And she says:

-- You have…hmm…you have my skis!-- Well, yes, do you have mine?-- Why on earth would I have your skis? she says.

-- Good question!, was the best answer I could come up with.

Well, I explain the whole story to her.  Then she says:

-- I was waiting for an hour to see if you would come back.  I saw a pair of skis similar to the ones you have.  They were still there when I left.-- Well, I was just up there to see if they were there, I said.  But they were gone.-- Did you really look carefully? I am asking because I saw them just half an hour ago.-- OK, I will go up to Attilla and look once more.

-- Attilla?, she said.  Attilla, no!  They were at Ruinette!!!

Suddenly the whole picture becomes clear to me.  I didn’t loose my skis outside the restaurant, but at the mid station where I did some stretching before going down the last slope.  Thus I took off my skis to stretch.  After having stretched I took the wrong skis.  It is hard to understand that I could make such a mistake.

The young lady was at first angry like a bee.  Then I told her that I thought my mistake was made on the top.  I also told her about the other skis I was about to steal.  At this time she started to laugh.  I tell her that I want to compensate her for her suffering.  I ask her if I can offer her a glass of wine or two.  She says, yes, that would be great… 

 I then went up to Ruinette again.  I find my skis where I had left them one and a half hour ago.  And that is the end of the story.  However, I can’t resist thinking how different this story could have ended.  Suppose, that I had “succeeded” in taking the other pair of skis at the top.  Then I would have “stolen” two pair of skis (in the same day) and probably been known as a ski thief in Verbier, a reputation I can do without.  And, I wouldn’t have been able to offer the young lady a couple of glasses of Pinot Noir! 

March 30, 2004

Before being invited to Tallahassee, I had never heard about it. I flew in to the city in the morning and back in the evening. I spent a day with the State of Florida. Bill Lucas did a wonderful job in making me feel very welcome and everyone I met was very friendly and interested in my work. I enjoyed my day very much. One of the questions we discussed was web services. The last couple of years services have become important elements for describing and building software. As with everything new, the software world has a tendency to believe that something fundamentally different has surfaced and that a new way of thinking is required. As a consequence we have got a whole arsenal of new concepts around the concept of services. We have got “service-oriented architectures”, “on demand”, “utility computing”...you name it. However, there is nothing fundamentally new with services. To organize software in services is an old practice.

Services were once a very important construct in RUP, actually in the version of RUP that we called 3.8. (It was the version prior to Rational buying my company, so it was called Objectory 3.8.) Unfortunately, the RUP team thought that downplaying services in RUP would make it significantly simpler. I disagreed with this opinion, but accepted it because almost everything else was adopted. It was very hard to argue for service-oriented design when the concept hadn’t hit the software industry. With Service-Oriented Architecture (SOA) on the table, the need is there.

In 1998, I wrote about services in the Unified Software Development Process book: Apart from providing use cases to its users, every system also provides a set of services to its customers. I made a distinction between end-users of the system and the customer who purchases a system for its users. For instance, a bank system has users which may be clients of the bank, and the bank itself is a customer of the system (maybe buying it from some system integrator). A customer acquires a suitable mix of services. Through these services the system will provide the necessary use cases for the users to do their business:

• A use case specifies a sequence of actions: a thread is initiated by an actor, followed by interactions between the actor and the system, and completed and stopped after having returned a value to the actor. Usually, use cases don’t exist in isolation. For instance, the Withdraw Money use case assumes that another use case has created a user account and that the user’s address and other user data are accessible.
• A service represents a coherent set of functionally related actions - a package of functionality - that is employed in several use cases. A customer of a system usually buys a mix of services to give its users the necessary use cases. A service is indivisible in the sense that the system needs to provide it completely or not at all.
• Use cases are for users, and services are for customers. Use cases cross services, that is, a use case requires actions from several services. A service usually provides several use cases or parts of several use cases.

In the Unified Process, the service concept is in analysis (platform independent modelling) supported by service packages. The following can be noted about service packages:

• A service package contains a set of functionally related classes.
• A service package is indivisible. Each customer gets either all classes in the service package or none at all. Thus a service package is a configuration unit.
• When a use case is realized, one or more service packages may be participants in the realization. Moreover, it is common for a specific service package to participate in several different use-case realizations.
• A service package often has very limited dependencies toward other service packages.
• A service package is usually of relevance to only one or a few actors.
• The functionality defined by a service package can when designed and implemented be managed as a separate delivery unit. A service package can thus represent some “add-in” functionality of the system. When a service package is excluded, so is every use case whose realization requires the service package.
• Service packages may be mutually exclusive, or they may represent different aspects or variants of the same service. For example, “spell checking for British English” and “spell checking for American English” may be two different service packages provided by a system. You configure the system with one or the other, but maybe not with both.
• The service packages constitute an essential input to subsequent design and implementation activities, in that they will help structure the design and implementation models in terms of service subsystems. In particular, the service subsystems have a major impact on the system’s decomposition into binary and executable components. This is of course only true if the development is going top-down with no reuse of existing components: legacy systems, packaged solutions, web services. And fact is, we develop more and more with reusable components.

By structuring the system according to the services it provides, we prepare for changes in individual services, since such changes are likely to be localized to the corresponding service package. This yields a robust system that is resilient to change.  

Given that most software of today is developed with ready made components, why would you like to design an analysis model (a platform independent model) with service packages. There is one good reason: we still need to understand what we are doing. Building software is about understanding, understanding components developed by different vendors, divisions, teams. An analysis model - maybe even just a partial model - used as a start help you overcome these difficulties.  

March 17, 2004

Today I gave a keynote at the Software Development West conference in Santa Clara. Today is also a very special day that I have been looking forward to for a long time. The reason is that the Jolt award judges announced their result today at the conference. WayPointer is one of the products that made it all the way to the finals. Given that WayPointer is so different compared to other tools, I was not sure that the judges would have time to penetrate it enough to see its many values.

I gave my keynote on Aspects and Use Cases working together. The audience seemed to like it and I enjoyed talking about it. After all, it is work that I started more than 25 years ago - that thanks to the work of Gregor Kizcales, Harold Ossher and other friends - now finally can be harvested. As you can understand, I was quite passionate.

Directly after my keynote the Jolt awards were announced. There were a number of different categories and WayPointer competed in the category for Analysis and Design tools. I had to wait for quite some time before the decision was announced. To my great joy and pride, WayPointer won a Jolt Productivity Award.

The Jaczone team has really done an incredible job. They have implemented a tool using concepts and technologies that not yet are widely supported by commercial platforms. They have done it in a very effective way and perhaps most importantly in a way that is accessible but yet non-intrusive to users.

I am very proud of them. Hope you all understand why this tool is so important.  

February 8, 2004

Many organizations are trying to achieve software reuse. Many of them think that they will achieve reuse if they just put their components in some sort of repository. Then they just expect others to reuse their valuable assets. I never cease to be surprised that people still do that. We have said for at least a decade that you don’t get any substantial reuse by just posting components. It seems as if people, instead of learning from others experience, always have to make the same mistakes as others over and over again.

The book I wrote with Martin Griss and Patrik Jonsson on Software Reuse is very explicit about how to achieve reuse. The subtitle of the book is: Architecture, Process and Organization for business success.

It all starts with Architecture. You design an architecture which identifies which components are reusable and which are not, thus a layered architecture. Usually two layers on top of middleware are enough. The top layer contains application components, which are not designed to be reusable. The second layer contains the domain components intended for reuse by several applications in the top layer. The only practical way to get a domain component is by designing an architecture in which the component has a clear role. Without this architectural setting, a component will never really be reused.

Process comes next. The way you develop the domain components is different from how you develop application components. They are documented for reuse. We suggested in our book that you design a façade for each domain component. This façade contains an extract of the models of the component, an extract defining how the component can be reused. In case the domain is big enough (e.g. banking, telecom, airline), the façades can through careful design evolve into a more powerful tool – a domain-specific language (DSL). Instead of designing on top of the interfaces of the domain components, expressed through their façades, you will design using a domain specific language.

Domain components also come with a kit containing tools for its reuse, examples of how to reuse it, and other things that help in getting it reused.

Developing application components is different. Application components don’t require to be documented for reuse. Instead they are designed using domain components and through interaction with other application components.

Finally Organization. In order to get successful reuse, you also need to develop an organization which maps 1:1 to the architecture. This means that for each component in the architecture there is a corresponding responsibility in the organization. Higher level components are the responsibility of a subsystem-owner. Lower level components are the responsibility of an individual developer. Without such a simple mapping between architecture and organization it will be practically impossible to get good reuse. Such an organization will become an expert organization – people will become experts in a subject matter. It grows people that want to create quality products. I call such an organization an architecture-based organization as opposed to a project-based organization. A project-based organization has a line manager for each project. The manager should only care about his own project. Such an organization is counterproductive to reuse.

In an architecture-based organization, the project managers are not line managers. Instead they own the budget for their project. Using this budget they can buy resources from the line organization (that is the subsystem-owners with domain expert developers) to get their projects done in time. The line organization can work with several projects concurrently and they have to prioritize them based on delivery dates. Yes, there may be conflicts, but these are usually not large. The total costs are substantially lower because the domain components are developed and maintained by experts. Thus in the case of conflicts, more resources can be added to remove the conflict, and still the costs are much lower than with a project-based organization.  

The approach I just presented also has the advantage that you grow the reusable components as you work with real projects. You will start with an empty architecture, but you fill it as you go. You don’t sit there and speculate about what might be reusable; instead you design the components in the architecture that are first needed. They have probably not stabilized for the first project, so they may have to grow through several projects before they really become reusable without redesign.

To achieve reuse is not easy. People have tried simple solutions like class libraries and component libraries into which component designers post their components hoping that other people will reuse them. We have seen very little reuse coming this way. Managers have thought it was the lack of incentives so they have stimulated all kinds of initiatives to get reuse. This is ignorant. You will get reuse, but only by standing on top of an integration of A, P and O, that is Architecture, Process and Organization. In another postcard I will tell you how you can move to an architecture-based organization from a project-based organization without revolution. It is really fascinating to see how easy it can be done, given that you are smart. However, that is not a problem, since you are smart, aren’t you?  

February 1, 2004

Singapore is one of my favourite cities in the world. I like it for its people, for its various kinds of delicious food and for its advanced software companies. Singapore is also the cleanest city in the world.

I have just finished a week of intense work, meeting customers in rather small but competent groups. Basically all customers have expressed that the week was very important and they are now looking into how to move forward. Thus I feel happy with my work. I will soon take a flight to Seoul in South Korea, but before doing so I will reflect on one of my concerns with RUP.

In my earlier email I said that I often get the following question? “Is there nothing in RUP you don’t like?” I responded:

“Of course, there are many things I don’t like. However, they are in comparison with what I like rather small.” I said that one of them is “The way RUP describes architecture is unnecessarily complex and confusing.” In this postcard I will elaborate on this concern.

The single most important determinant of the quality of a software system is its architecture. A good architecture is an understandable architecture, it allows a system to grow gracefully for years to come, and it forms a system that is built out of reusable assets or that has harvested such assets.

Develop architecture first
Developing the architecture should therefore be done as early as possible. Even in theory it is very difficult to change a poor architecture into a good one with incremental techniques such as refactoring. In practice it is close to impossible. The costs are too high for any business-oriented manager to accept and he/she will typically opt for quick fixes instead. A good architecture needs to be created when the cost of creating it is small or even non-existent. Prioritization of architectural work has a very good return on investment. It will reduce the need for redesign and minimize throw-away work during the remainder of the project.

Architecture is captured by a skinny executable system
However, architecture is not just a paper product. The architecture must be verified and validated. We do that by first building what I call the “skinny system”, a system that includes a backbone with enough muscles to be able to exercise it. It is a system in its own right. It has everything a system has, but only things that are significant. Thus, it has all significant paths through the use cases (or scenarios); it has all significant subsystems, components, classes, nodes. Usually this skinny system only includes 5-15% of the final code, but enough to demonstrate that the significant elements work. And most important, we know that this skinny system can grow to become the complete system. This is so because we have scrutinized all features and use cases and selected to implement (part of) those that carry the largest risk, have the highest priority, or are unique in some other way. The remaining parts of the system can then be added incrementally without disruption. This skinny system is accompanied by a paper product called the architecture description. But now, this paper product is verified and validated. The architecture is actually working.

The architecture descriptions are views of the models.
The models are the models that we have in RUP. Thus it is the use case model, the analysis model, the design model, the implementation model and the deployment model. Well nowadays we have more models. We have a user experience model, we have a domain model and when we work with asset based systems (software reuse) we have even more models.

So far there is no major difference in what RUP describes as an architecture description and how I think it should be presented. The problem comes now when we start to look at these views of models. In RUP each view has been given a name. They are the use case view, the logical view, the process view, the implementation view, and they don’t map exactly to the models. It means that the developers have to deal both with names of views and with names of models. It is just confusing. I have yet to meet one developer or one tech rep at Rational that understands both this view structure and the model structure. Even some top experts at Rational could never really explain how these structures were related to one another. Most people either understood the view structure or the model structure.

And it could have been made so simple.
Since the final product is described by its set of models, and architecture is about an extract of these models, there is no reason for having separate names for views. Instead just call them simply the architectural view of the use case model, the architectural view of the analysis model, the architectural view of the design model, etc. Most people I talked to agreed that this was a simplification, but I could not convince the key people…and I didn’t get a reason for their hesitation. The only reason, I was told, for keeping view names separate from model names was that for architecture we needed a process view and there was no process model. That is an argument that I don’t accept. If we need an architectural view, we most certainly need a model as well, since the models are the complete description of the system.

Thus the most natural way to deal with architecture is to describe it as an extract of the model structure and call this extract for the architectural views of the models.

This is the right approach for other reasons as well:

• There are more models than the original 4+1. The more we get the harder it becomes to give names for views that are different from the names of the models.
• With asset based development we get many more models; it becomes almost ridiculous to name its architectural views different than the models.
• The user experience model is as important as other models from an architectural viewpoint, something the advocators of separate names originally didn’t agree with. Would we give the architectural view of that model a separate name? No!
• Finally, test is nowadays not a separate model, but instead each of the other models has a view for testing (verification and validation). Thus we have test views of basically every model…are we going to give these separate names as well? No!  

Thus, this is my proposal for you RUP developers. It is my hope that you take the chance to simplify the presentation of one of the most important artefacts in the software industry. Make the architecture description what it ought to be – an extract of the complete set of system models and remove it from being a creature living side by side with the system. The most important reason is to make RUP easier to understand. RUP is complex enough without making it unnecessarily complex.  

January 15, 2004 

Let me first wish you a very happy new year 2004. I hope it will be an exciting year both personally and professionally. A lot of things are happening in my life right now, so my expectations are very high. My work on aspect-oriented software development is going very well and Jaczone is in a very thrilling growth period. My passion has never been higher.

Yesterday, I gave five talks here in Jacksonville, of which the talk to the Rational User Group in Florida had most attendees. I spoke about Use Cases and Aspects and about "What you didn't know about RUP". It is always demanding, but also fun, to speak to people who have followed my work for many years.

My talk about RUP is of course very positive to RUP. As most of you know, RUP was originally created in Sweden but at that time it was called Objectory. When Rational acquired my company in 1995, we changed the name to Rational Objectory Process and later in 1998, when UML was adopted; we again changed the name to Rational Unified Process. We wanted to surf on our success with UML.

To tell you the truth, I have never been happy with putting Rational in front of the Unified Process. It is OK to have the company branding in front of product names, but to put it in front of intellectual work is different. Personally, I don't like to have to use a company name every time I utter my approach of thinking. However, working for Rational made it not so hard for me, but all my friends out there working with customers don't want to use our brand every time they mention our approach. I can't see that the standard approach of software development should be branded by one single company, even if this company is large.

Since I express myself so positively about RUP, I often get the following question? Is there nothing in RUP you don't like?

Of course, there are many things I don't like. However, they are in comparison with what I like rather small. They are still in absolute terms very important. In this postcard I will just list them. In later postcards, I will explain what I mean.

These are the three top issues in RUP that I don't like:

The way RUP recommends us to do analysis is a compromise that won't help customers succeed.

• The way RUP describes architecture is unnecessarily complex and confusing. I agree with what architecture is, but not with its presentation. Very few people understand what the architectural views are and how it is related to the different models being advocated.
• RUP has grown and become to complex. Too complex for users of course, but even more complex for the poor people that will have to maintain and develop it further.

Of course, I have recipes for how to solve these problems … and many more. The user complexity will be eliminated with the help of tools such as WayPointer from IJI.