Years ago I was a member of the Data Interchange Standards Association (DISA), involved in electronic data interchange (EDI). This body provided message interface specifications for common business transactions, and because of that you could say it was a very early (and widely successful) example of M2M. I was thinking about EDI yesterday, and I wondered whether there were things about EDI, M2M, IoT, and even NFV that might be useful to connect.
In the old days, people used to send purchase orders and other commercial paper by express mail, largely because electronic copies would 1) be subject to arbitrary changes by any party and 2) because without some format standards, nobody would be able to interpret an electronic document except a human. That kind of defeats the purpose of the exchange, or at the minimum limits its benefits. EDI came about largely to address these two points.
One of the founding principles of EDI was a guarantee of authenticity and non-reputability. Somehow, you had to be sure that if you sent an electronic something, your recipient didn’t diddle the fields to suit their business purposes. The recipient had to be sure that their copy would hold up as well as a real document as a representation of your own intent. EDI achieved this by using a trusted intermediary, a network service that received and distributed electronic commercial transactions and was always available as a source of the authentic message exchange if there was a dispute.
Message authenticity is critical in just about everything today. Commercial EDI is still lively (more than ever, in fact) but we’re now looking for other mechanisms for guaranteeing authenticity. The most popular of the emerging concept is the blockchain mechanism popularized by Bitcoin. One of the things that could make blockchain useful is that it can be visualized as a kind of self-driving activity log, a message whose history, actions, and issues follow it and can always be retrieved.
If we start to visualize applications as loose chains of microservices, a worthy cloud vision for sure, we have to ask how we’d know that anyone was who they said they were and whether any request/response could actually be trusted in a commercial sense. For services like SDN and NFV there’s the problem of making sure that transactions designed to commit or alter resources are authentic and that changes made to services that impact price can actually be traced back to somebody who’s responsible for paying.
I think we see the future of IT and networking too much through the lens of past imperfections. IT’s history is one of moving the computer closer to the activity, culminating in my view in what I’ve called “point-of-activity empowerment”. I’ve lived through punch-card and batch processing, and one thing I can see easily by looking back is that the difference between past and future, in application terms, is really one of dynamism. I have to connect services to workers as needed, not expect workers to build their practices around IT support or (worse) bring their results to IT for recording.
The problem is that dynamism means loose coupling, widely ranging information flows, many-to-many relationships, and a lot of issues in authentication. We’ve looked at cloud security largely in traditional terms, but traditional applications won’t make the cloud truly successful. We need those point-of-activity, dynamic, applications and we need to solve their security problems in terms appropriate to a dynamic, high-performance, loosely coupled future.
The issue of formatting rules, what we’d call APIs today, was also important because it was always assumed that EDI linked software applications and not people. You had to provide not only a common structure for an electronic transaction, you had to be sure that field codings were compatible. The classic example from some old DISA meetings was someone who ordered 100 watermelons and had it interpreted as 100 truckloads!
One thing that tends to get overlooked here is that microservices can be a substitute for structured information. If we think of a purchase order, for example, we think of a zillion different fields, most of which will have specific formatting requirements that we need to encode to support properly. If we viewed a PO as a series of microservices, we’d have only a couple fields per service. The biggest difference, though, is that it’s common to think of web service results in a format-agile way, so we have practices and tools to deal with the problems.
The web, JSON, XML, and similar related stuff also provide us guidance on how to deal with data exchanges so that structure and content are delivered in parallel. There are also older approaches to the same goal in SOA, but one thing that seems to me to be lagging behind is a way of providing access to information in a less structured way. It’s not as simple as “unstructured data” or even “unstructured data analytics”. The less structure you have in information, the more free form and contextual your application if it to users/workers has to be.
The only logical way to disconnect from this level of complexity is to abstract it away. If we have to provide workers with information about stuff to support a decision, we have to be able to facilitate the worker’s ability to interpret a wide variety of information in many different formats. If, on the other hand, we simply supply the worker with the answer we’re looking for, then the structural issues are all buried inside the application.
This might sound like we’re limiting what workers can know by saying that “answer services” will hide basic data, but remember that if we stay with the notion of microservices we can define many different answer services that use many different information resources. And answer services, since they provide (no surprise!) answers and not data, are inherently less complex in terms of formats and structures.
There used to be EDI networks, networks that charged enormous multiples over pure transport cost just to supply security, authentication/repudiation management, and structure. Imagine how efficient our EDI processes would be today had we applied our technology changes simply to changing how we do those things, rather than to whether we now need to do them. Modernizing networking, modernizing IT, means breaking out of the old molds, not just pouring new stuff into them.