Doug Engelbart's    Colloquium at Stanford

An In-Depth Look at "The Unfinished Revolution"

Good Afternoon. Let me just tell you the Open Group is a non-profit consortion. It brings large supplies of IT products and services face to face with a large number of major user  organizations. If we want to talk about grand challenges, the grand challenge is enabling the  suppliers to deliver products to their users. Interoperability is really the grand challenge in IT.  I am going to start out by what it is not. In IT we hadn't got as far as the railroad industry, I  think it is fair to say.

In the railroad industry what they discovered long ago is that if all of the tracks were the same gauge, all of the couplings worked the same way you got a lot further. In IT, it is difficult  to do that. What you do in the railroads, is if you want to go from a to b and a to c. Once upon a  time if the tracks didn't join up you had to get off of the train, get on to another train and move  along. That still happens a heck of a lot of time now. You might be comforted to know that the  department of the defense, when they were looking at ways in which they could have end to end  service when they were looking at the ways to deliver the information to the war fighter in the U.S.  That they found that some where between issuing the command the instruction arriving at the point of  delivery, there was someone in the middle transcribing information from one machine to another. It  is not quite there. The reason is the customers don't buy the platforms. They don't buy the  underling stuff so much. They buy a solution to a problem, and the solution drives the decision of  the application, and the decision of the application drives the decision of the platform. The  suppliers would all want to be your number one solution provider. So, they would like very much to  differentiate their products. Not only on quality, speed, and service, but also on features that  gives you better service, but also give you an issue of lack of interoperability. So, I say with the  train example. If you would like to get from A to B, if that is problem B and you would like to get  from B to C and it was problem C, you would think that you could add them together and you would get  the whole journey. So, you would think that solution A is solution B+C. In the IT world,  unfortunately in order to get from there to there it obviously doesn't work. So, you get people  called system integrators, who actually make quite a good living at fixing the problem. What you  have with integrating competing solutions in IT is a lot of work to make it work. 
 

Now for a large organization. If you think of a user organization like a bank or retailer, or aircraft manufacture, there are certain barriers that this causes them. The time barrier, for any  organization, the time to market new products and services is a big issue. They all want to provide,  all user organizations, their IT departments, all want to provide better products, services, and  tools to their end users. Either to make them more productive, or to make them more competitive.  Time is a big issue. There is time in instillation, there is time in training, and if you are  dealing with multiple different operating systems, interoperability with a human is an issue that  you have to address as well. Obviously integration, if you are going to have to make two things work  together that were not designed to work together, you have an implementation problem. If you have  two different technologies that need to be supported, you need two different skills in the work  force to support them for the rest of their natural life. Risk in terms of the operational risk,  what I mean by that is if you are trying to run a business, but things don't work together but you  have got to implement them and make them work, when you make things join together you have some  custom built parts in the middle. There is a risk that you may not be able to provide service as you  would want to. Obviously although many of the products individually have superb security devices,  when you have to join them together, what you find in the joins is this is the gap where people can  get in.

What I wanted to do with this matrix is look at some of the economics behind interoperability and where it comes from. I would suggest to you that anything on the right hand side of this matrix  is not a particularly high profit area to play in for any of the suppliers. They don't want to do a  lot of innovation if there is low interoperability. There is not an awful lot of issue of being in  the fragmented box. Although initially, there may be profits of products that don't interoperate,  sooner or later you get found out. For example, there are standards around today where products all  allegedly conform to the standard, and yet they don't interoperate. There is a big issue on market  take up there. What we have got things that have been around for a while in the generic sense, we  have high interoperability. Everyone can use it, it is easy and put in, but the innovation is low is  relatively stable, it can move on. There is not a lot of profit in generic commodity type products.  If you get into a monopoly type situation. There is reason that you are going to profit because you  own that space, but the innovation is low. Where you get a lot of activity and competitors all  fighting out, there are huge opportunities for profit is when the innovation is high and the  interoperability is high. The railroad business discovered that by having interoperability, the  market expanded and therefore they could all make more money. The telecom sectors have discovered  this. So, by having greater interoperability, everyone can make more money, and the market grows. It  is where the market is being constrained, either by low interoperability or though the monopoly  cases that you hold things back. So we are very much looking for enabling dramatic and dynamic  market growth through the combination of high innovation and high interoperability. That, of course,  is a very big challenge.

Now how do we get the communication between the customers and the suppliers? The customers know the problem that they are trying to fix, so they know that in their organization there is an  integration issue. The suppliers know that if they are going to change their products, rather than  their competitors changing their products, someone has got to pay for it. What happens out there is  most of the big customers, whether it is the banks or the defense department, can get any of the big  suppliers to come to them any time that they want. In fact, some of them have a problem keeping them  away. When you have a one on one discussion, between a customer and supplier, the conversation is  very much on the product benefits and specific features of a specific product. It is not on how it  interoperates with their competitor's products. So the focus in one on one discussion is very much  on improving a product with in it's own boundaries. In order to have discussion on interoperability,  you have to have a many to many relationship. You need many suppliers that the customers are talking  to at the same time; some of the focus is not on the individual products, but on the joins. On the  integration, on the interoperability. You need many customers. If there is not, perhaps there is no  market. So, you have to have both. Now if you go through all of that, and you have a large number of  customers, and a large number of suppliers, to come together and agree on a standard. You can  specify a product and the suppliers will say we are ok, we have a market position here we can move  on. Others will swallow hard, spend some money, and get there. The point of getting a standard where  everyone agrees on a specification isn't necessarily the end of the line. First of all, you can  agree on a standard, but there may not be any products that arrive, at least for a long time. 
 

If you look back at the drivers of the web, some of the underlying standards were around for an awful long time before products came out that started driving the market forward. Sometimes we  will get to an issue of a standard there, and then we will wait for the market to decide. There are  two issues with that. The market can't decide if there is nothing to buy. The other is the market  isn't always that smart. I think if the market was smart we might have Beta-max, not VHS, or we  might have Apple rather than something else. That is one issue. The next one is that if we spend a  long time getting to the standard, perhaps the market has moved on anyways and there are other  alternatives. So the one concern that suppliers legitimately have is that if they have gone through  all the time troubling expense of finding ways to interoperate with their competitors, does anyone  care when they have got there? 

In some areas we find that everyone can claim to conform to the standard. Many of them sincerely believe that they do. Unfortunately they can claim to conform to the standard, but still not  interoperate. The reason for that is just like legislation. No law maker can write something that is  sufficiently clear that everyone can get it straight off without some case study, with out it being  tested in the courts. It is similarly difficult for everyone to go and implement a standard or a  specification in exactly the same way, and know that it is going to interoperate when they come out  and meet their competitors. How do you know that it conforms? As a buyer there are a number of ways  you can do it. You can either trust the guy that says my products conform, you can trust me I'm the  salesman. Or you could ask for proof of tests, or you can ask for a guarantee. What we prefer is  that it is tested to give the suppliers and indication that products conform, but that they  guarantee that they interoperate. That is a challenge. Supposing that you got that far, how can you  tell that they interoperate, until you have got a problem. So how do they get fixed? The last one is  that there are lots of standards out there, and maybe the standards don't interoperate. Let's have a  look at some of the process. What we try and do is reflect some of the customers need with the  supplier desire.

All the customer need is very simple. They need products from their suppliers that interoperate. All the suppliers need to do is agree. That is not too straightforward. We have a  sense of a requirement coming from the customers to the suppliers. In normal product development  that wouldn't be a direct one to one relationship. You would go through some type of product  management. The suppliers would work diligently on getting a specification delivered. Once they got  a specification they would look for how we assure that the products will conform. There is some  testing. The testing only serves to give the supplier an indicator that their products conform, so  that they have the confidence to step up to a market that says we guarantee that our products  conform. We will stand by that guarantee and fix it if there is a problem. Finally, we are concerned  with procurement, to make sure that if we have gone all the way through that loop, people are  actually going to buy the products at the end of the day.

This is how consortia comes together in the learning process if you will to try and get to this. Very often suppliers create and promote consortia. Very few consortia like the Open Group have  customer members, so the consortia go out to advise, inform, and instruct the customers. At the end  of the day we see that there is a loop between the suppliers that provide the products and the  customers that buy them. There has got to be a process in the middle. Whether it is us as a  consortia or a partner as a consortia, what happens is there is an outsourcing between the  management and the certification process to an organization, such as ourselves. Who would also deal  with bringing together the customer requirements and build the test software so that at the end of  the day, you can certify that the products conform and provide the guarantee that the customers are  looking for. 
 

Finally just let me just leave you with these thoughts. The pay off for interoperability for the customers are overcoming the barriers that I talked about earlier. There is a time, cost, and  the risk. What the suppliers get out of it is greater market growth. To be able to position  themselves for that Makita growth in being involved at every stage of the development process.  Rather than differentiating market, they differentiate in ways that can benefit the customer, by  providing better quality, faster service, better price, or features and benefits above the basic  level that we have agreed on the standard. Thanks.

[  principal lecture]

 ---