When building software components and services for reuse across applications it is more important to strive for consistency rather than to comply with a standard. Why do I say that? Because you can always switch your implementation to be standards compliant. If a bulk of your applications use a particular reusable component you can always treat the existing interface as an adapter that in turns invokes a industry standard API behind the scenes. Note however I am not advocating blindly creating wrappers for components for which mature standards already exist (e.g. If you are trying to use a logging API for java you should evaluate Log4j instead of building a new logging implementation).
This is specifically related to horizontal business capabilities that you want to reuse. For instance, say you need the ability to process credit card payments from several applications and there wasn’t an industry standard at the time you needed this functionality. It is important to have a payment API that your apps utilize rather than wait for a standard to magically appear. Day two, if and when a standard appears you can change the existing implementation without any impact to your existing applications. Okay I am oversimplifying – you might need minor code changes and regression testing. But the bottom line is that you will be in a significantly better position rather than having to change code across your codebase.