SOA for PLM applications (and others?) – Is it really a good idea? Part 1

Charles DarwinIn IT domain, a new trend is hunting the previous one, because it is not possible to support/analyze several trends for companies in parallel, each of them having its own life(cycle?), and transformations, while companies/vendors/integrators are adopting/rejecting them.

The current trend is with cloud computing and SaaS (Software as a Service), while the previous trends was web 2.0, SOA and process orchestration. I would like today to come back to one of them, which is SOA, or a more technical view of it, which implements the so-called web-services. It’s an old one, but I was surprised to see it ranked number one as “Tools that count” in the last McKinsey Quaterly.

The web-services concept, introduced about 10 years ago, was based on defining standard based data exchanges between the new internet based applications, mostly applying pre-defined xml grammar, and as well defining a standard protocol to support the data flow. This approach was mostly inspired, in my opinion, by the lesson learned by the IT community, for decades of trying to implement point to point relations between applications, and having struggled to simply maintain the different interfaces, implemented to connect a given set of applications, i.e. defining test scenarios, and each time one of the application was modified, check that the application network was not damaged by a localized change (in the IT landscape sense). This was costing a lot of money, while the business need to maintain such connections was really needed.

So, web-services arrived, supported by a massive adoption of a new standard for everything, the xml format. The xml format added to flat files format the capability which consists in describing a node-relation data model, meaning the capability to represent a N-M cardinality between objects, which was not possible to easily describe in a csv format, which can basically describe a 1-1 cardinality between objects (a table).

But one thing inside web services, which is underrated, was to introduce a standard protocol to support the data flow, meaning defining standardized connections point for applications, and publishing those services into a services dictionary. It was WSDL, SOAP, and UDDI… It provides to a developer the ability to “discover” a web service, simply sending a standardized request to the application, in order to “understand” the service prior using it, and without having to change anything to the application providing the service.

So, people took the opportunity to build interfaces between systems, using this new technology, simply because it was cheaper than to define a proprietary language between two applications. But I think that using web-services to make point to point interfaces is not using the technology at its maximum. That’s the question I have today, which is: why web-services are really interesting to use, ten years after their introduction?

The definition of a web-service is not to define an interface between 2 points, meaning a start, an end and the relation, but to define simply a point, the connector. And so, simply using the underlying standards, other applications can use or not the service you defined.

Let’s take the example of a number generator, which is a basic building block of our PLM applications, but of many other applications as well, like ERP, CRM, and more. If you build an independent application, which objective is to generate a number for business objects, you need to:

  • define the different objects for which someone may need a number
  • define the numbering scheme for those objects
  • define the way other applications will use to get a number for the business object it is managing

The third point is where you need to define the data exchange protocol, and where a web-service can be used. Why, in this example, a web-service is usefull? Because you can build you connector alone, without the requesting application(s). Simply using web-services standards, you can simulate the requesting application(s). The day where the requesting application(s) will be ready to request a number, your application will be ready, and you will have not to change a single line of code, simply because you prepared the connection. The work which is requested afterwards is to officialize the connector and to maintain the connector, and not to maintain an interface with a well known requester.

This will push a mindset change from IT departments, which is to focus on connection points only, and not on the full data transfer process. This capability provides a great flexibility inside IT organizations where you can focus teams on their technology domain, only taking care that they use the web standards, and plan for connections with other technologies. This is SOA.

In the current world, where cost saving is a continuous challenge, there are few companies still having a system architect team, defining corporate business data model, maintaining complex data model diagrams that nobody understand except themselves, simply because it is now impossible to justify internally. So the current organizations come back to a list of silos, because there are no transversal connections between those teams, which were previously organizing the corporate IT strategy. So a new trend appears recently, to “kill silos”, proposing methods and tools to help people working together, without adding new costs for that requested communication. And that’s where SOA can help, simply requesting silos to define their potential requests to other silos. By the way, it should push people to better evaluate the services they will possibly provide to others, compared to existing services. Taking care of who will need/be happy with your information, your application, and its users, should benefit of a better support of business process, and so you will increase the ROI of it.

What does it means for our PLM applications? It means we should design an additional topic when we specify implantation of a given business object:

  • Numbering scheme of the object
  • Properties on the object
  • Relations with other objects
  • Lifecycle of the object
  • Methods of the object
  • Reporting on the objects
  • Need to send this object to another data source?

Technical implementation should then take care of the last topic, defining the needed web-services, for current and future needs.

Because there is a rule: all the things that may happen in the future, for sure, will happen. In today’s world, if we are waiting that someone comes to us with a request, to start designing the solution, it is simply too late.

What do you think?