Closing the Gap between Business and IT by Ivar Jacobson

From almost the dawn of the age of software more than 50 years ago, there has been a communication gap between business and IT. For almost as long we have sought solutions, but they always seem to elude us.  Meanwhile, the gap has grown into a chasm that now needs a fairly substantial bridge.

From the business you may hear that ”we have no confidence in IT’s ability to deliver useful solutions”, or “we have limited visibility of progress, risks and problems”, and “we don’t know how we should measure the value of our investments in IT.”

From IT you may hear that ”they (the business) don’t fund the projects adequately”, or “they don’t know what they need”, or “they don’t know what is possible to develop”.  Each side feels the other is responsible for the problem.  And, you know, they both are right.

Over the years there have been many strategies to close the gap, sometimes going from the one extreme to the other.  Some have viewed the gap as a soft problem only:  if only business and IT could collaborate better and learn from one another the problem would be solved. Improvements in communication and sensitivity were tried, but still the gap remained.

At the other extreme people have tried to apply software technologies to describe the business process in the form of models. The result was usually a very detailed business models which could not be understood by anyone other than their creators, who were typically software people.  In reality not even these people really understood them because they usually had a flawed understanding of the business process itself.

The solution lies somewhere in between:

  • We need a common, but simple, language.  Spoken languages such as English would seem simple but they are too ambiguous and nuanced to help us with what needs to be done.  Nor should we become excited about any of the many modeling languages which are understood by only a small subset of IT people.  In my experience, just 10-20% of these languages is more that enough to describe business processes.  Moreover, we should focus on describing the essentials, usually less than 10% of all the details.  The rest the IT people can take care of on their own.  This is smart!
  • Of course, we need to work together but not just to learn to know one another, but to do something we can stand for together, e.g. executable code.  The era is over when one side prepares a document to an illusionary “final” status and then throws it over the wall to be implemented. We have ample proof that this does not produce good results.
  • We need to deliver results often and with high quality, on frequent intervals.  IT will have to accept that the business will change its mind about what it wants.  This is a natural part of seeing results more frequently, and the feedback obtained is valuable and important. Frequent demonstrations of progress creates confidence and increases productivity, quality and it gives quick results.

Thus we require a strengthening of the competencies on the part of the business. The people that work with IT people need to understand how software is built in many steps based on a farsighted map.  They must be able to contribute by defining the essentials of business processes and must be able to transform these essentials into requirements in the form of use cases, etc. There is just no way around this.  It is naïve to believe that the business can avoid these capabilities.  This does not mean that they need to be experts in writing requirements, but they need to know enough to actively participate in their definition.

Of course it is equally important that the IT people understand business goals, strategies and business processes.  Software has the ability to change and improve the business processes and find more efficient ways to perform this process, but an understanding of the process is the essential starting point.

This is smart!  However, it is just the beginning, please read my next blog.

  1. Pal | December 5, 2009 at 12:43 pm Reply


    You mentioned aspect-orientation and this leads me to my previous comment regarding usecases and aspects. Is this an idea that you still feel is a good one ? For those of us who have invested much time in this and argue for it, it would be nice to have a short comment as to where the concept stands today. Has SOA, for example, made the concept more “extreme” ? To many people, aspects are in themselves a radical approach and are generally not easily accepted exept for traditional approaches such as logging, transaction management, etc.

  2. Ivar Jacobson | December 5, 2009 at 12:18 pm Reply


    Admit there are some similarities. However, I have not expressed it that way. I would rather describe it as separation of concerns which is the idea behind aspect-orientation.

  3. Joe Wright | December 5, 2009 at 12:09 pm Reply


    Are you aiming to do for methodologies what the GoF did for object-technology?

  4. Philippe Back | December 3, 2009 at 9:25 am Reply


    What can bring a tremendous improvement to the communication is for IT to understand how a business works and also how people do work. That’s why investing in studying psychology will pay handsomely. There is a tad too many introverts on the IT side. Learning some dialectics (Check on Schopenhauer)to deal with very assertive business people helps in understanding their ways is also a worthwile investment.
    When it comes to technology, remember that business people are interested in getting holes and not drills. The outcome is what counts, not the tools, not the technology, nor the way of achieving it.

  5. Pal | November 22, 2009 at 9:18 pm Reply


    Ivar, I very much agree in your comments about software engineers using complex models which are difficult to understand and communicate.To me, the common language that you refer to, must be concentrated around usecases in their most consentrated form. Even
    business people can read simple use-case descriptions. However, these descriptions in my view seem to be even more concentrated when they are presented as usecase diagrams “decorated” with variation points and related variants as you described
    in the book “Software Reuse”. Further, if we add cross-cutting concerns (maybe implemented as aspects), I think we have a beautiful combination.

    So, simple usecase diagrams with some graphical notations for usecase dependency, variation points, variants and crosscutting concerns to me seem a natural consequence of your books ?

    However, I don’t see many people advocating this mix,so I would very much like you, Jacobsen, to comment on this : Do you agree that the lessons from “Aspects and usecases” are not much used ? If so, can you see any particular reason for it ? I strongly believe in reusable usecases and would like your comment about any statistics revealing their potential.

  6. Hildeberto | November 20, 2009 at 5:48 pm Reply


    I do agree with @Kerstin when he says that the communication problem between business and IT can be appropriately addressed with Domain-Driven Design (DDD). So, the problem now is how to increase the DDD adoption in order to avoid further discussions about the existence of this gap.

    Another point, maybe ambiguous, is that the firth paragraph, business processes are obscure even for those who created them. A statement clearly against BP. But, at the end, business processes seem to be essential to solve the communication gap by defining “the essentials of it and transforming these essentials into requirements” as well as emphasizing the importance “that the IT people understand business goals, strategies and business processes”. So, we can conclude that the problem is not with business processes, but how lazy IT people are to learn it well and use it appropriately.

    I think the problem about Business-IT alignment is that business and IT people don’t really worry about those people who really perform the process activities through systems. When we attend discussions on this alignment, all we can listen to is about business models and the IT infra-structure to support it, always in a low level perspective, like: what is the best framework, middleware, language, but nothing about ergonomy, simplicity, navigation, guidance and many other aspects that make people more productive when interacting with enterprise systems.

  7. Kerstin Jonsson | November 19, 2009 at 10:10 pm Reply


    Maybe we should consider the thought that there is no such thing as a Generic Business which could be opposed to (or in concert with) such a thing as a Generic IT. Every business resides in a domain specific context, where also the supporting IT-solution is to be be implemented.

    I think one of the best and most thorough approach so far to the problem with the perceived gap is taken by Eric Evans, the founder of DDD (domain driven design). In this view the context is everything, expressed in the terms of the Domain. Business (domain) experts and IT (software modeling) experts work together on the problems in this context, communicating in a domain specific “ubiquitous language” and progressing in an iterative process. This ubiquitous language permeates the domain all the way from the top of the business down into the written code.

    The use of UML is merely a tool to help in modelling the concepts of the domain under study. UML is not a language, but a set of symbols to represent concepts and associations between concepts in a form that is translatable into code. The real things of interest here are the concepts themselves, the domain objects, and the way they behave and interact in order to form the fully functioning business domain. All this can only be expressed and understood by humans (I base my reasoning on the notion that both business people and programmers are basically human) if we communicate using a language based on human principles for concept construction and perception, not a language constructed to generate instructions for machines.

  8. johanplatteau | November 19, 2009 at 8:54 pm Reply


    The gap between “business” and “IT” has been created by IT. Do you know of the gap between your local car dealership and you (the customer)!

    On the positive side, the creators of UML acknowledge their attempts for “formalization” have failed, on the negative side they insist on trying to bridge the gap between business and IT.

    If no gap exists, no need for a bridge. If we continue to think in that terms, the business will find other suppliers!

  9. Wagner Pinto | November 19, 2009 at 10:40 am Reply


    At the company we are working with, the called “Business Use Case” came to solve this problem. We are experiencing a change on the reaction of the user (client) on understanding the proposed solution coming from IT. The Business Analyst are a great tool, and they are making this happen.

  10. Skip Pletcher | November 18, 2009 at 3:38 pm Reply


    We may be closing the gap, but the future may look very different. Imagine that business staff have the ability to 1) define processes, rules, and interfaces on-the-fly employing graphic representations of services, 2) test the new features themselves and with robot suites, and 3) deploy them silently with a scheduled later activation datetime.

    The role of IT becomes one of maintaining, optimizing, and extending the capability to let the business staff automate business processes. Each specialization focuses on its own expertise. IT can be centralized or outsourced at little or no risk, because intelligence pertaining to the business domain never leaves the data center.

    Young people who learn “programming” from Scratch and maintain their own Google Sites may have very little tolerance working in an environment which limits the ability to write their own solutions. If we want them to create a graphic language representation of a business process, why not make it an executable representation?

    The new function of IT might be to turn networked mainframes into giant programmable business calculators.

  11. Neal Lester | November 17, 2009 at 10:00 pm Reply


    Perhaps a programming language or library (optimized for programmers) from which an English language description (optimized for business people) of the system’s behavior can be generated automatically would do the trick.

  12. Ivar Jacobson | December 11, 2009 at 7:48 am Reply


    Let’s make it clear, UML has not failed. UML is apart from its ancestor, the only viable modeling language alternative. However, there is room for improvement and that happens under very competent leadership.

  13. Ivar Jacobson | December 11, 2009 at 8:49 am Reply



    Yes, every business lives in a domain. A challenge in defining that domain is that it is very dependent on its “usage”. Take for example the domain object car. A car can live in many domains such as where it is produced, where it is on a map, where it is insured, etc. Thus, domain models tend to be large and unintelligible if people focus on finding objects only. Combining usage and domain makes the trick.

    Another phenomena is that we believe that our way to model things is good even for business people. IT people live and breath models (even code can be seen as a model). These models assumes an underlying machine. Business people have grown up with other kinds of models. Thus, we have to be very cautious in forcing software models onto the business side.

    Isn’t UML a language? There is a lot that can be said about UML, but it is much more than just a set of symbols. It has static semantics and operational semantics. Some people have extended it to become executable. UML was designed as a language to communicate about requirements, domains, architecture, designs, etc. UML was not specifically designed “to generate instructions for machines”. This is one way that UML can be used only. I have no clue where all these rumors come from ☺.

  14. Ivar Jacobson | December 11, 2009 at 9:36 am Reply


    As with everything that is presented as fashion, it sooner or later becomes unfashionable. Use cases have survived the fashion wave and are now considered motherhood. People use it without making any noise of it.

    When it comes to the term aspect-orientation, it is unfortunately more complicated. I have discussed this somewhere else, but right now I cannot find it. We never got a widely accepted aspect-oriented programming language. The computer scientists were fighting one another so it came to a halt. As a consequence, the term aspect-orientation is some circuits a bit passé. Thus, instead I talk about ‘separation of concerns, which is a wider concept and it has not become dirty by failure. It is an excellent technique to use for all kinds of things. Use cases are great examples of separation of concerns. Separating out practices from a methodology is another usage of the same idea.

    Thus use cases and aspects are still very much alive, but you may be better off if you talk about separation of concerns instead of talking about aspects.

  15. Kerstin Jonsson | December 12, 2009 at 10:48 pm Reply



    The specific “usage” of the doman defines its context. A car is not always a “car” – this depends on the context. I guess this is what you mean and I do agree.

    Maybe we should define the concept of “language”? In the somewhat rigorous world of system architecture UML might fill the basic criteria for a language – and I do think it is an excellent tool for our trade. But UML is also domain-context dependent. Try describing a piece of music in UML and see how far you get. Or a medical diagnosis. Describe a business or a system with UML – fine, but a true language – no. In my opinion still not. But this disconcert might be due to the fact that we – you and I – don´t share the same context as we speak of UML.