Frontier Exclusive Leadership Interview for hardware, software, system related business and and academia



Frontier Journal (FJ): How did you come up with the idea of Use Case along with Sequence Diagram, which forms the foundation of Use Case driven analysis and design for Object-Oriented Software Engineering?

Ivar Jacobson (IJ): I felt we at Ericsson needed a unifying concept between functions (features) and traffic cases. That became use cases defined as a special kind of objects that only could interact with another kind of objects, actors, representing things outside the system. In particular use cases could not communicate with one another, because then we would get something similar to normal objects. Use cases could have class relationships such as specialization or include and extend. Sequence diagrams came up as a means to should how a use was realized as an interaction between objects inside the system.

FJ: In your co-authored book titled Object-Oriented Software Engineering, you stated any software system development consists of several tasks, namely Architecture (Modeling), Analysis, Construction and Testing. Which one among those four are the most important factor in tackling today’s development challenge due to system’s size and complexity explosion?

IJ: Architecture, but…

FJ: A system’s model to be built can be specified in different ways through the choice of specification languages. Any specification language has its syntax and semantics. in designing a language, how do we balance between the simplicity of syntax and richness of syntax for the success of refinement, from model to implementation?

IJ: We always have to start to design good models. For instance the use case model only cares about the user types and the interactions. It doesn’t care about the inner components of the system. It is intended for specification only. It is also intended to work as an input to test. Every use case is a great test case or group of test cases. The deign model shows all components and their interconnections. It also describes how each use case iis realized as a collaboration among the components of the system with required messaging between the components.

FJ: If you could take UML as an exmaple, that would be great (BTW, part of reasons why UML is more popular in well-established companies than that of those startups, is that beacuse the former has deeper management hierarchies?)

IJ: Small companies believe they can shortcut UML modeling, and they can do it better than large companies.

FJ: Theoretically anything manual except those creativity related can be automated, nowadays the goal of Executable UML, also the core of MDA (Model-Driven Architecture) is to generate executable codes right from UML specification automatically, how do we ensure both the efficiency of the generated code and the completeness of test cases?

IJ: This is big question. In theory executable UML could have been a very effective way to get from design to code with seamlessness all the way down. However, the big vendors would hate that. This would result in a standard platform with standard platforms and Microsoft and IBM would not be able to compete with different platforms as today. The .NET platform vs the Java platform. It would make the customers happy, but that can only happen if the two big vendors would like to work on this together. They both create differences of microscopic nature (but of course, they are not microscopic in their eyes and in their fans eyes).

FJ: Nowadays systems become more and more complicated in terms of complexity, and larger and larger in terms of size. To tackle the complexity, we have to model a system in great detail with less abstraction, to tackle the size, we have to model a system in less detail with more abstraction. So how shall we deal with such abstraction dilemma during system modeling?

IJ: Ideally we would have got the two worlds to standaradize on platform. That won’t happen until we find a dramatic new technology that force unification. Until then we will need to use great architectures as the mean to reduce complexity. We need to rely on SOA and PLA, but both of them are very hard to develop. The failure rate is too high. You need people more competent on building these systems than you can get. I have worked a lot in this space. You have to Think Big, Build Small.

FJ: Any successful software product, its core most likely is done just by 1 or several key architects. For large projects, we have UP (Unified Process, or one of its most notable versions is RUP), and for small projects, we have XP (eXtreme Programming), is there any suitable software process for those projects in-between to fit in? E.g., Linux nowadays is a huge system, however its kernel is still being controlled by only Linus and serveral of his followers, while thounsands of developers all over the world are working on drivers, applications etc.

IJ: Yes, we discovered that RUP is too big even for large organizations and XP is too small for even small projects. We developed the idea that you give up the idea of monolithic processes whether these are big like RUP or small like XP. Instead you use a practice-based approach. Practices are useful solutions to a particular aspect of software development. Examples of good practices are iterative development, use case driven development, architecture, components, etc. We also have minor useful ideas called patterns that you can apply in many different practices such as pair programming, war-rooms, stand-up meetings, self-organizing teams, etc. We get a much more practical approach for process improvement, starting with what yoyu and adding a practice or a pattern at a time. The monolithic process approach requested you to throw out what you have and to do all or nothing (of course they didn’t say so but it was what was requested in practice).

FJ: It seems both patterns (both at framework-level and design-level) and components (such as libraries) are not the solutions for serious software reuse, so are there any silver bullet there for the success of software reuse in industry scale?

IJ: No, no silver bullet! However, systematic reuse requires an architecture that grows gracefully as more and more projects grow it. You need some new practices on top of the practices you already have to build single applications.

FJ: Programming paradigm is under constantly shifting, from Procedual-Oriented Programming (POP), to Object-Oriented Programming (OOP), to Aspect-Oriented Programming (AOP), and now it is time for Service-Oriented Programming (SOP). What is your perspective on its potential impact on software architecture, specification language, software process and software reuse?

IJ: Again a big question. In reality we never got aspect-oriented programming because the academics could not agree on whether this was a good idea or bad idea. Personally I think it is a great idea, and combined with other great practices such as use cases and architecture, it would have improved the software industry significantly. The resistance came from academics that tried to make Aspects the silver bullet and from other academics that saw the consequences if aspects became a silver bullet. Yet a great idea that went down due to academia’s inability to work with other disciplines. Over all years since we introduced components at Ericsson we developed a programming language (Göran Hemdal) designed to program, code and test one component at a time. Our components were semantically what services are today. We did SOA in telecom in 1970, we even had a service message bus that allowed us to hang new services onto the bus without changing any other services as long as the messages on the service message bus could be reused.

FJ: Would that be possible for us to have a language, combining both specification and implemenation, that hits all of sweet spots of virtually every phase of software engineering, both vertically and horizontally?

IJ: Yes, there is no doubt about it, but that would require standardization of platform API. This is not a technical problem, this is a political, business problem. We would need to make it possible to change this API as soon as new technologies requested it. Why wouldn’t that be possible? We do that for all kinds of other complex protocols. FJ: Do you envision the possibility of the convergence of computation, data storage and communication nowadays? For example, SUN Microsystems recently acquired MySQL, and Oracle acquired BEA and PeopleSoft.

IJ: I don’t want to express an opinion here

FJ: You are already highly successful both technically and financially, what motivated you to start your own company, Ivar Jacobson International after leaving IBM years ago?

IJ: Many reasons. I liked the new trends on agile, but I also saw that they don’t have the whole solution. None of these great ideas is a silver bullet. Instead I saw that we need to find a platform on which we can integrate ideas such as practices and patterns coming from any source around the world. Every company is unique, every product group is unique, and every project team is unique. Each should be able to mix and match technologies from around the world with some light governance. I believe monolithic process (big or small) is out. Instead you create your way of working by composition of practices and patterns starting from what you have. You should not throw out the baby with the bathwater, but add a practice at a time as needed. Thus I saw a continuation of my work was out there. I also love working with clients and employees. I want to make them all successful as much as I can

FJ: When you architect a large software system, what are the top 3 key issues you have to take care of first typically?

IJ: 1. You need to understand the context of the software you architect. For business software it means you need to understand the business processes that the software will support. For products like telecom systems, defense systems, etc. you need to understand the mission that the software will be an integral part of. In practice it means you need to model the business or the mission.

2. You need to know what software you already have and what software you can acquire. In reality you will never build a large system without having anything existing to reuse.

3. You need to design a roadmap for where you want to get and then fill this roadmap with executable software project by project. No big bang. The roadmap is a scalable architectural drawing achieved by understanding what you have and what you want to get to. However, an architecture not anchored in executable code is a hallucination, so don’t drown in premature architectural work

FJ: When you manage a large software development team, what are the top 3 key issues you have to take care of first typically?

IJ: 1. Developing a large system is extremely difficult without a good architecture. Managing the development of a large system requires large number of developers. These people must be organized in groups that are directly mapable to the architecture of the system being managed. Each subsystem has an owner and the owner is the head of a group responsible for the subsystem. If you don’t have a good architecture you are in trouble…you need to get to one if you have a product that will survive. What I mean by a good architecture is a separate issue.

2. Almost all work must be done by project teams, none of which must be larger than say 10 people. Each team recruits people from the groups in the organization I just described. The team leader is responsible for the delivery of executable software. How you always can get teams with less than 10 people is a separate issue.

3. Each project team needs a way of working that they are comfortable with. No new process adoption (whether this is XP, Scrum, RUP or CMMI). Instead the team’s way of working is improved in small steps — practice by practice. This is what we have been working with the last five years with great success stories. Some light governance over all teams is needed, but that is a separate issue.

The reason I separate out some issues is because it would be too much to describe now. However, I have detailed answers to all these hard questions as well.

FJ: What are the top 3 key issues that determines productivity? How shall we build better software for software in boosting productivity to the next un-precedent level

IJ: 1. On the people side, there is nothing as important for productivity as competent and motivated people. Competence you can get by learning proven practices and having already competent people to help you. Motivation is what agile brings to the table that is new. The rest of agile is reuse of what already has worked for many years.

2. On the technical side, there is nothing as productive as reusing existing software. Thus Service-Oriented Architecture or Product-Line Architecture are important for large systems. Unfortunately, people fail miserably in using these techniques. You need to work very smart. You need to apply what we call smart-cases, otherwise you will drown in work and fail.

3. A great leader is a must for getting the above to work. A great leader can help the whole organization to be smart. S/he can strike the right balance between people, practices and tools as well as all that goes with it: training, mentoring, lightness, etc.

FJ: What do you think about the impact of change of business models on software process?

IJ: I am not sure what you mean.

FJ: Do you think innovation in software engeering is thriving or stagging?

IJ: We are moving forward, but very slowly. Unfortunately software engineering is too much of fashion. We are even more fashion-oriented than the fashion industry. We need a better base for what software engineering really is. I would be happy to discuss this separately, if you are interested.

FJ: I believe you are a believer of Weak AI, if software-based sed Intelligent Agent can automate those 80% of work in software developement, which are routine based, what about the remaining 20%

IJ: I would be happy if we at the least automated 50% of what is routine! The other 20% will still need traditional tool support. However, part of this can also be automated as we learn more. In particular for business related software.

FJ: What will be the frontier of software engineering in the next decade?

IJ: Let me take this separately as well. I need to have a conversation with you before I spend more time on this.


Back to Home Page