Before I get into today’s thoughts, this video is a good lesson in ‘keeping your eye on the ball’.   Watch the white team and see if you can count every pass.

You may have seen that before (especially readers from the UK), but personally I went ‘What the????’ and backed the clip up to make sure it wasn’t a trick.  Besides being a good message about cyclists, it’s a great illustration of what happens you’re so focused on a particular task or set of functionality that you miss what else is going on around you.   Well and good, but how does this tie in to OPC and other standards?   I think it’s something to consider when choosing between a broad, adaptable standard like OPC/OPC UA or an industry specific standard such as oBIX or BACnet/WS.  (or maybe I was just really amused by the video and had to work it into a post)

With the world moving towards service based architectures, everyone and their dog is developing web service based systems.  (So much so that a new term JBoWS or ‘Just a Bunch of Web Services’ has emerged.)  You can easily see what is happening:  Companies, industry sectors and vendors all desperately need integration and interoperability.  That is what drove OPC adoption to where it is today.  Now that the focus is on the enterprise, they need the interoperability to reach there too, and web services is the most promising technology to get it there.  The result is many emerging industry specific service based or XML standards: oBIX and BACnet/WS in building automation, PRODML and WITSML in the oil and gas sector, WAMDAS in pharmaceutical, and many others.  Of course there is the other obvious option, OPC UA.

As an end user do you go with an industry specific implementation that may or may not evolve beyond JBoWS?  Or do you go with a broader standard like OPC UA that can meet the same needs, but may not be tailored exactly to your situation?  Let’s look at it in a slightly different way.   Do you focus on the white team and passing the ball between them?  Will you ever need to get the ball to the black team?  (network expansion, integration of other systems, business system integration…) If so, can you?  What happens when the moon walking bear shows up?  (Requiring new services, mandated security and/or redundancy requirements, schema changes…).  The player on the court has to keep an eye on the ball.  The coach on the side line has to follow the ball, both teams, the referees and the playing field.  Is your enterprise connectivity a player or the coach?

I can’t possibly go into a full match up of OPC UA and all the other industry specific web service initiatives.  What I will do is put OPC UA to the some key questions that determine whether or not an implementation is truly SOA or JBoWS.   (I’d love to say I came up with these questions, but I didn’t.  They come from various SOA blog sites I follow)

1.     Are the services a true representation of the core behaviors found in your key enterprise systems, as well as new services required to provide other critical behaviors?
The important word here is ‘enterprise’.  OPC UA covers real-time, historical and event based data regardless of its source.  OPC UA also provides for security, redundancy, communication robustness and a comprehensive and extensible information model.
2.     Have those services been abstracted for most foreseeable uses?
The base services sets are highly abstracted, with Functional specifications that provide implementations commonly used by OPC today.
3.     Are the services combinable into composites, and are those composites well defined?
The services sets are broken down into well defined, combinable composites that cover server management, address space, data management and subscriptions.
4.     Is there a plan for governance and security, managing the use the services?
The Profiles specification and the OPC Certification process is a clearly defined and measurable process
5.     Are both the information and services abstract-able to an orchestration/process layer for configuration-oriented agility of most of the IT assets?
The services sets and information model are abstracted for agility and flexibility.
6.     Is your information/data managed in such a way that you’re loosely coupled from the underlying physical schemas?
Being loosely coupled from the underlying physical schema has always been the key feature of OPC.  OPC UA follows the same principle.

To me, it’s clear that OPC UA is well on it’s way up the SOA maturity chain.   Take the industry specific set of web services of your choice and ask yourself the same questions.  I’m not saying that all other web service models are wrong.   The line between a general interface specification that is open, interoperable and flexible without sacrificing usability, to one that is specialized, rigidly defined and highly integrated is a tricky thing to define.   It may be the case that some specialization is needed.   However once there is duplication of effort, conflicting message structures or composites that don’t integrate, the ‘standards’ quickly degrade to a bunch of web services.   The OPC Foundation is fully aware of this possibility and so  OPC UA has the Access Type specifications and industry specific Companion specifications.   Collaborations with groups such as EDDL, MIMOSA, ISA and others are a good initial start.   The more standards bodies or user groups that contribute UA information models, the wider and more complete the specification adoption will be.

If the industry standard you are looking at doesn’t meet the criteria of the above questions, and is not actively collaborating with OPC UA, then the next question you should be asking is ‘Why not?’