In my last post I talked about my recent trip to the Model-Based Enterprise Summit hosted by NIST. I had several discussions which answered many of my questions; however, the discussions created many more. One conversation took us in a direction about standards and how it was a key aspect of the MBE. This got me thinking about the future of standards and I want to share with you some of my thoughts.
I cannot say I like or dislike standards. However, I do really like the idea of seamlessly exchanging information no matter what end application or platform is on the other side.
Exchange of information has been a hot topic in virtually every industry for as long as I can remember. Using various different standard formats, either defined by standard bodies (IGES, STEP, etc.) or de facto vendors (DWG, PCF, etc.), was one of the ways we have exchanged information. However, I think we all have run into some limitations with using standards for numerous reasons.
The major issue I currently see with standards is that they do not iterate very fast. There is technically no reason why they cannot iterate much faster but because there are “many cooks in the kitchen” it does seem to take longer than what is needed in today’s fast paced environment.
How can Platformization Affect the Future of Standards?
All the conversations and information I received revolving around standards got me thinking of the future of standards. I got to a point where I think the direction many software vendors are taking in creating a platform can significantly shape the future of standards.
What is Driving Platformization?
We are finally at a point where vendors are admitting that there is no way they can expect their clients to only use products offered by a single organization. This change in thinking is one of the drivers of why many software providers are creating a platform. There are also many other reasons and benefits for creating a platform such as building a better ecosystem of 3rd party companies who provide solutions built on top of your platform technology.
Platform Openness Architecture
For any software solution provider to have a successful platform they will require it to be open at least to a certain extent. This open platform will allow other companies (including competition) to extend the platform to provide tools and products to end users. There are many examples of this with cloud solutions but it is just as pervasive in on-premise solutions.
I think that the openness characteristic of these platforms may significantly change the requirements or even the need for standards.
Before platformization, the systems we used were closed which made it very hard for anyone to pull information from these systems. This required 3rd party providers and the closed platforms’ competition to resort to using some sort of standard for exchanging information. These standard files would be generated from the closed source system and then used as an input into the destination system.
With platformization, the destination system would be able to automatically pull information from the other system (which could be a competitor’s) and there would be no need for any files. Neither would there be a need to follow a workflow recipe (Export standard file-> transfer file-> Import standard file). You can imagine how this would be a significant benefit for any solution provider since they would be able to seamlessly pull information from their competitor without any user intervention. It would reduce the complexity and the use of any type of recipe workflow.
So how does this effect standards? Well, I think it does in two possible ways:
1. Accessing the native information using the API’s provided by the open platform
For an open platform to be easily extended it would most likely have to provide an API to read and write data. This would allow the competitor’s system or any 3rd party software company to utilize this API to read data and translate the information from the source platform to the destination’s native format. This would mean that there would be no need to use standards since the information would be exchanged between the two native formats.
The disadvantages of this approach would be that the destination system would require different tools to exchange information for each system it was extending. Most solution providers would focus on their main competition but what would happen to the systems that they did not strategically determine to extend? Well, I think this is where 3rd party vendors would step in. If there was enough demand for this seamless integration, someone would be able to capitalize on it. The openness of the platform would allow anyone to extend the system with very little effort compared to a closed system.
2. Using standards to exchange information via API’s
Using the same strategy as above, but instead of converting data from the source native format to the destination native format, an intermediate step could be added. This would consist of converting data to a standard first. This intermediate step would be abstracted from the end user. This strategy would benefit the organization that was providing the solution since it would reduce the amount of effort and development required to extend multiple systems.
The disadvantage of this strategy would be that using a standard will not always get you all the information you require. This is the exact same issue we have with current standards. Additional information would still need to be pulled to supplement the standard file which would have to be combined prior to writing it to the destination system.
The question here is, if we are using standards this way, would it change what the industry requires of standards? Possibly not, but this is the question I am asking myself and you.
Closing Remarks
I am not sure about the future of standards. However, I do know that every industry will find a strategy to move information more efficiently. Using information across systems has been a problem since I could remember and since there is more emphasis on exchanging information in the last few years, it will continue to grow in importance with end users.
Platformization has already started and many companies have stated this in their overall strategy. This change in philosophy will redefine how software solution providers and their 3rd party partners handle the exchange of information with other systems.
Platformization has the possibility of removing the effort and requirement of transferring information between two distinct systems from the end user to the solution providers. This shift in responsibility will definitely shake things up.
Post Comments
Denis hi, I noticed we are both struggling to give standards a place in the multi-vendor space. For me with the focus on PLM. In my upcoming post I will ask for some assistance and feedback from my readers to understand which kind of practices exist in the field. I will compare four different practices: Platform, Backbone, Service Bus and Business Intelligence which I came across in my customer base.
For me, the standards play a major role in the data model definition. Having a common dictionary of any type of information object in the world is the ultimate dream. This aligns to your standards for exchange API’s – perhaps not the best in performance but unambiguous. Then vendors can implement it in their systems in the most efficient manner and add their own proprietary elements, providing access to the outside world in a neutral format and inside their platform, their system they can do what they want. Which means some of the vendor’s goodies are not part of the standards but that keeps them in business. More on this soon
Thanks for the comment @josvoskuil:disqus and I look forward to your up coming blog posts. I am sure it will initiate a lot of conversation which I think is good.