Most of our customers come back from an ERP since

1/ their ERP contains too much functionality, much more then they need, and complicates their processes.
2/ their ERP contains not enough functionality in very specific aspects (those are the aspects that are specific to their situation/business/size/…). Logic, since ERP is targetting every business (and hence, no business at all).
3/ they want to differentiate from competition by doing things differently (deviate from the standard), and standard ERP supports commodities. Differentiation can only via custom software.

- They realize that custom software, only solving what they really need, no more no less, is a better investment at the end of the day.
- Moreover, this custom soft can follow their needs as their business evolves over time. A standard ERP package is never as flexible as custom software.
- And last, we see a trend that writing custom software is becoming less and less expensive, given the great development tools, tons of open source projects, and new methodologies that the ICT industry has adopted over the past years.

It’s the customer request on the one hand, and SI and vendor supply on the other that cause this situation to perpetuate. Yet, any package out there is so flat that it at least needs some customisation – but one can always overdue it, or “get overdone” if you catch my drift

Your point wrt humans is very valid as well. I use the same distinction in my socbiz book where I use an MQ on product and humans, driven and facing. Foxconn would be indeed most boring, and unfit for social, as it is product-driven as well as product-facing: rules rule!

And yes, ask a CEO what makes his business so special and he’ll answer “we distinguish ourselves from the competition by…” – meaning “we’re in the same biz and support the same boring stuff, but we just support a few exceptions that they don’t”

nice post, I agree with most points, with 2 remarks:

First “So how come ERP is where it’s at? Well, only because it’s customised to death.”

But it is quite often not ERP vendors fault, but customers who want to have “THEIR UNIQUE” processes built into the solution and don’t think around the corner to have a standardized solution with the same outcome (i rather guess a lot of those companies are afraid of change management internally..)

Second regarding the point “The IT exception and rules”:

In my opinion there is a bias in analysts and blogosphere opinion. Yes there is the other
“very end, humans, the opposite takes place: we encounter complex, dynamic stuff that changes all the time,”

But this is most in Service Industry (or broader named “knowledge based industries” and service departments of companies), where we as IT and consulting people come from. There are still so many manufacturing companies out there, where the other “very end” consists of work processes with “simple, static stuff that doesn’t change”
Hardcore example: Look at Foxconn building Iphones, you see dynamic workers & knowledge flows? But I am still sure, if you speak to a Foxconn manager he would not like to have a standard IT-supported process, as in their opinion Foxconn is “special”.

So it is a transition. There are a lot of companies where a proper “classic” ERP systems as “foundation” helps to manage the business and make the right decision (Still there are even in the US and other “saturated” markets a lot of companies who don’t even have ERP). As their business models evolve, those companies have to think about where to adapt the front-end, and there are the SaaS offerings quite a (more or less) perfect fit to be more agile.
Integration of those solutions is another topic..

Cheers…..Steve

Thanks for the question.

What I am saying is that, by adopting a message-based approach to expressing the API (instead of using URIs and object-based payloads), we can use features of AWS or any other interface in a compatible way; allowing both consumers and producers to optimize the interactions over time.

The _details_ of AWS API are not of much concern to me; the notion that the community is attempting to decided on *just one* static interface is what I see as the problem.

Mike – I’m confused on what you’re proposing. I understand your concerns around the AWS SOAP/WSDL API… but are you suggesting that the AWS Query style won’t work for your needs?
Thanks,
Jeff

While this may have some short-term advantages, I don’t think this approach works in the long term. We are at a point where the innovation on the public clouds is starting to happen with more and more vendors announcing public clouds. Given this, if we go with adopting AWS APIs, how does one go about adding new functionality to that ? Should we wait for Amazon to add that functionality. If not, what prevents each vendor taking a different tangent for each additional functionality not offered by AWS today. And what would happen to the “AWS Standards” then?

As long as the underlying models are similar, other open source projects like DeltaCloud can fill in the API syntax gap. When we talk about standards, let us get the models (or as Mike said, Media Types) right first.

As I mentioned in a comment to Mark’s post some time ago [2], this is, IMO, the wrong conversation to have. Certainly ten years of WS-* has provided enough evidence that a single static set of “function-style” APIs is not only unworkable in a distributed network that spans both space (the planet) and time (many years of required inter-operability); this attempt at a static API is also inadequate.

Efforts should be focused on designing an “Open Stack” media type; one that exposes all the functionality available today *and* allows for supporting new funcitonality as it comes online; including allowing vendors to add support for “custom extensions” w/o upsetting the rest of the community or breaking existing implementations.

I would hope a decade of wandering through the weeds, attempting to mimic the design of local network APIs and forcing on the Internet would have convinced us all that there *could* be another way. But alas, it seems the folks with the power to “make this happen” are unable to make the next step; to move on to building a system that actually *works* at planet scale.

Instead, this is devolving into a strong-arm match to see “who’s API wins.”

bummer.

[1] https://twitter.com/#!/mamund/status/26403488642
[2] http://www.markshuttleworth.com/archives/765#comment-368536

The argument of ‘should they or shouldn’t they’ is irrelevant. The only question is, which companies will be participating in taking it to a standards body. And those discussions are already underway…

Jeff

That is a fantastic perspective you’ve brought. The Samsung product manager is just the latest in a long line of people who either:
– Couldn’t figure out how to look beyond their current products
– Had no interest in doing so

But their customers certainly had no problem looking beyond the company’s existing products. Plugging into the emerging, dynamic thinking of customers is going to be needed to avoid the “typical” company fate,.

Hutch

They don’t. They know users from a certain narrow perspective (customer purchasing behavior). But this simply isn’t enough to drive product development.

So I often find myself trying to get everyone to focus not on what customers say, but what users do; not on what we think users need but what we observe their actual pains to be; not through the frame of legacy products but through users’ real experiences.

Its a heard sell though, and there is always a ton of resistance. Most people in product development simply refuse to see the world outside the lens of their legacy products. And so we have companies like Kodak, BlackBerry, Nintendo, Yahoo, etc…

(And yes, instead of buying a new camera, I bought a new iPhone. The phone and app features are fine, but I really wanted a good still/video camera to capture moments as they happen. The iPhone solved my problem. The average digital camera simply didn’t.)

http://hometechnologyintegration.org/node/52

…so far, there are not many answers!

2 cents,
@k0ws1k