Lately when talking with colleagues over lunch, sooner or later we end up on the same topic – What ever happened to the promised simplification within eBusiness Standards?
It is rather interesting that this question is not going away, it’s a constant repeating Déjà vu discussion. Therefore, I decided to use my blog to post a few articles that summarize what I have seen happened over the last 25 years to the various attempts to simplify eBusiness Standards, and why they, in my view, have failed. Maybe, just maybe, it will help provide enough background for others in the eBusiness Standardization area to advance the quest for simplification.
Before getting deeper into the topic let me clarify what I understand when talking about Simplification. It is the act of reducing complexity, or as Albert Einstein said:
Things should be made as simple as possible, but not any simpler.
Simplification can be applied everywhere these days. We should be all familiar with the complexity of our remote controls for our TV, Satellite/Cable set-top box, and Home Entertainment Center (Tuner/CD-DVD Player-Recorder/Audio/etc). I have yet to find a Universal remote control that is simply to use. Let’s not forget about the complexity in programming your VCR/DVR. Yes, there have been improvements, but the average user is still challenged to deal with the implementation.
When it comes to computer applications, the problem is trying to balance the rich set of features with the ease of use. Take Microsoft’s Word application, with every release we get more features and little improvements regarding ease of use. Most Word users only use the basic features that are well hidden within the user interface (UI). More upsetting is when a new release of Word changes the user interface of those basic features. Word is not the only application with that fault, there are too many to list.
Apple, well known for its great detail to functional UIs, upset upset some years ago, iCal power users with the new release as part of the new OS X. The problem was that Apple introduced a totally new UI that required more keystrokes for creating and editing calendar events, let alone allowing users to view quickly the details of events. Why is it that application vendors fail to meet the users expectations for ease of use?
For starters, most applications are designed without the involvement of users. Yes, some developers include users in their public beta test programs, but developers are interested in finding bugs during that phase, not looking for feedback about usability. I started with software design in the early ‘70th making sure that the UI was what the user wanted, not what I thought was the best solution. Today, back at software design, this is still my guiding light. I drifted away from software design with the start of the ’90th, but still got involved as the Directory of Human Factors at Premenos/Harbinger. Sadly Premenos and Harbinger were the only two software companies I got involved with that had dedicated departments that address UI requirements as part of the product development, all others depended on the developers to do what they thought might be what the end users wants.
I got involved in eBusiness standards during the mid ‘80th, a time when most participants were users, not vendors. One would think that this would have resulted in standards that truly are what users wanted. The answer is not that simple.
Yes, EDI standards reflect users requirements, to be more precise, every user’s requirements. Let me explain.
Take the data requirement to exchange the date for the delivery of goods. One user may call it just that, but another calls it drop-off date, and yet another user calls it arrival date. Instead of finding and agreeing to a common name, all three date elements end up within the standard. UN/EDIFACT, a newly created EDI standard ran into that problem from the start, and thanks to some arguing by some techies agreed to clean its directory from such duplicates. In addition, the clean up process resulted in moving away from specific data elements by using generic data elements with a qualifier.
In the beginning, it looked like that users agreed to find common acceptable names for data elements, but soon it became easier to fall back to just adding a qualifier for every variation of that same data concept simply because it is what the user wanted.
The end result, UN/EDIFACT (as well as X12) have become too complex to be implemented by the average user (small and medium sized companies/organizations). Sorting through the many qualifier values to map to their in-house data, or trying to understand why their trading partner is using drop-off date and not arrival date, and is it the same, just takes too much time.
There is nothing the software developers can do to overcome that problem, it is a user induced complexity thanks to the flexibility built into the standard by the users. So what does it take to create standards that help in reducing implementation complexity? I will try to answer that question with my next posts, starting with the outlining the attempts by the standards community in the mid ‘90th.
