Driving towards interoperability
Allen Brown. 1.*
- unedited transcript -
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
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.
Above space serves to put hyperlinked targets at the top of the window