I was prompted to write this blog when I read Jeff Nolan’s blog about the Culture of Complexity [1] that permeates enterprise software (Jeff used to work in SAP Ventures). Now Enterprise Software may not be simple, but the reasons he gives for the complexity are, I think, plain wrong.
His first argument is that the Internet and XML have made integration simple and therefore removes the need for much of the complexity. This is just not true. Here’s the first quote from Jeff’s blog …
“The Internet originally accomplished something very meaningful, a standardization of communication protocols that enabled systems to communicate with one another”.
I fundamentally disagree with this. The Internet standardized protocols that allowed people to communicate with systems. Communication does not occur unless there is understanding. A system cannot understand HTML. Instead, it needs a person who can read a page, like this one, and work out the meaning of the information on the page.
Second quote…
“By dumbing down data integration [because of XML] to text ... the web is able to seamlessly move data from one application to another without the need for a broker in between”.
Well OK, maybe you can move data between two systems using Web services without too much difficulty, but unless the system that receives the data knows what to do with it, it won’t work. For example take the following snippet of XML …
2006-12-10
What would the system that received this information need to know to process this information? How about the date; is it October 12th or December 10th? Is it a planned, scheduled, or actual delivery date – if you don’t know, the system won’t know what to do with it? If a scheduled delivery date is unacceptable, can it be changed and if so how?
XML, per se, cannot provide answers to these questions. XML is really more like an alphabet. English, French and German largely share the same alphabet, but knowing the alphabet doesn’t mean you can talk the language and understand what the other person is saying. It’s the same with XML, a system may know it’s XML, but it won’t necessarily know what it means (and therefore what to do with it) unless the logic has been built into the solution.
Third quote …
“The irony in our current market is that the big SOA platforms end up driving not a technology shift that fuels a new wave of growth, but a business model shift as a result of the decoupling of a tightly integrated suite of applications into a loosely coupled repository of services.”
I completely agree with this, in that having a loosely coupled repository of services such as the Enterprise Services that SAP is building into its Enterprise Services Repository should make it much easier to deliver novel technology solutions to support your business by recombining: functionality in existing solutions; services you’ve newly created; with, services operated by your partners.
… but he then goes on to say …
“Customers will be able to substitute services and drive their own solutions offerings “at the edge” in a way that is reminiscent of, and I can’t believe I’m going to write this, best of breed.”
… now this is where he’s wrong. Substitution of services can only occur if you have standardized interfaces. You can’t just plug a US hair dryer into a European socket because it would blow up because of the voltage difference. Even if you had a dual voltage hair dryer, you would still need an adapter to convert from the flat US to the round European pins. The point is that, unless the interface is identical, you can’t just substitute one service for another and expect it to work … and as I said earlier, XML does not solve the problem.
So what does this mean for a Business Process Expert?
- Understand what your data means. If you are using an Enterprise Service, you really need to know what each piece of data in the interface for the service means so that you can use it correctly.
- Know what your service does. Understanding what the data means is not enough. You also need to know: what the service does with the data; how it processes it; and how it uses it to generate additional data, e.g. a response.
- Anticipate and manage complexity. Many of the services needed to build the applications you need will, over time, become available from SAP and its partners. But many won’t. Instead, they’ll be services operated by your business partners and third parties. These services will often require adapters because the services are not yet standardized. Creating adapters is time consuming. So anticipate the need for them early to make sure you can identify/acquire ones that are already built or build the ones that aren’t.
So what is SAP doing?
Reducing complexity requires standardized services. SAP is working hard to achieve this by leading the development of standards in organizations such as UN/CEFACT. This should mean that, over time, the need for adapters should gradually go away. Only then will much of the complexity in enterprise software be able to decrease.
[1] I found Jeff Nolan’s blog by looking at the ZDNet blogs from Dan Farber and David Berlind. I recommend them to help keep track of what’s going on in the software/technology industry. In early December they attended the SAP Analyst Summit in Las Vegas and produced an interesting series of blogs about SAP that led me to this one by Jeff Nolan.
