Open Standards - Open Source. The Business, Legal & Technical Challenges Ahead. - What The Open Group Does (Page 4 of 13 )
That takes us to some of the things that The Open Group does. Business scenarios (I’ve already mentioned the Interoperable Enterprise), Architecture Framework, Challenges, Specifications, Certification, Best Practices, Open Source. The reason we have to deal with all of these things is that in order to help industry get to Boundaryless Information Flow, we can’t just have one tool in the toolbox. We can’t just go round with a hammer thinking that every problem is a nail. We’ve got to have the appropriate tool for the job.
There are a couple of Business Scenarios that our members have done in addition to the “Interoperable Enterprise”, we have Identity Management, and the “Executive on the Move” on the web site. They are freely available.
With “Challenges”, members come together and say, “We’ve got a specific problem with existing products that we need to get fixed now. Are there ways of configuring products to do that?” The latest example was concerned with the need for security of messages using e-mail clients within and between organizations. This resulted in the Secure Messaging Toolkit. The Mobile Directory Challenge is next.
Open Source is another tool. And Open Source is not just about the platform. An example of how we use this tool is OpenPegasus.
Over the years, we have had a real problem with management systems. Management systems did not interoperate and we had working group after working group of vendors sit down together to try to figure out how their products could interoperate. They never arrived at a solution. Every couple of years they’d come up with a plan and say, “We’ve come up with a great idea on how this is going to interoperate.” And after the initial enthusiasm died down, they’d realize that it was one particular vendor’s solution and it would cost a fortune to re-engineer. What happened with OpenPegasus is that the vendors came together and agreed upon a Common Information Model (CIM) that needed an implementation for which we had one sources. This gives us a translation layer—a layer that will enable us to communicate from different management systems. So what we’ve achieved with Open Source in this case is to overcome an intransigent problem that specifications alone couldn’t achieve. We couldn’t reach consensus any other way.
In the future, as this is going back into product, we want to make sure that it goes back into product in a consistent way so we do need a consistent standard or specification. And then at some stage customers are going to want to know that the products they’re buying are conformant with that specification. So then we would want to see a certification program.
Turning to specifications and standards, let me offer a couple of examples of implementations that The Open Group has been developing. You may have seen s press release from Seibel talking about ARM, Application Response Management, going into their products right now. Our Enterprise Management Forum worked on ARM. We also have a key role in the Single UNIX® Specification. Some of the questions in this area include: Is a specification a standard? Who sets standards? Are standards only done by formal standards organizations or do consortia do them? Do consortia do recommendations, do they do certification, what do they do? These are related issues we deal with constantly. Our position is that mostly what we do are specifications and the formal standards bodies do standards. So if you look at the Single UNIX Specification, although that is regarded as the standard in the industry, in actual fact, it is a profile and a whole list of specifications.
Next: Does Open Source Equal Open Standards? >>
More Administration Articles
More By The Open Group
