The funny thing about a lot of the people who claim to be ‘Enterprise Architects’ is that I’ve come to realize that they tend to seek complex solutions to relatively simple problems. How else do you explain the fact that web sites that serve millions of people a day and do billions of dollars in business a year like Amazon and Yahoo are using scripting languages like PHP and approaches based on REST to solve the problem of building distributed applications while you see these ‘enterprise architect’ telling us that you need complex WS-* technologies and expensive toolkits to build distributed applications for your business which has less issues to deal with than the Amazons and Yahoos of this world?
And Uche follows up;
I’ve recently had occasion to discuss my “enterprise” credentials with some mainstream-y CIO/CTO types. It always amazes me how many of that number gaze vacantly at simple architectural ideas, and find true comfort in endless, overlapping boxes with data arrows flying in all dizzying directions, so long as those boxes are labeled “Oracle”, “SAP” and such.
Indeedy-do. I could have sworn I wrote a blog post a while ago about this, but I can’t find it… but the gist was that complexity is actually desirable to many architects (enterprise or otherwise, but more prevalent in enterprise IME) because – at least as far as I can determine – it seems to validate the importance of the problem; the more important the task, the more complexity that’s “desirable”. Obviously this is the complete antithesis of principled design.
So forget open source, open standards, software-as-a-service … the wholesale simplification of inter and enter-prise architecture by putting it on the Web, is by far, the biggest disruptive force facing – and indeed, currently shaping – our industry today.
And Uche just followed up with a beaut (why can’t I come up with these?!);
My recent experiences, and Dare’s quote, bring me to mind of the old adage: “No one ever got fired for buying IBM”. Why is there no sign of a corresponding “No one ever got fired for designing like Google”?
Sweet Uche, very sweet. But have patience, it won’t be long before that’s mainstream thinking. As one of the Dare’s commentors said (in a very lesscode/Gandhi-esque style);
First they ignore you. Then they laugh at you. Then they just say 'Ok, well you can exist, but our problems are *much* more complicated, as distributing a two-phase transaction update between 15 business partners using 3 different security tokens types is /never/ a bad idea...'. Then you win.
Damn, I’ve been in a foul mood recently. Finally, Web services folks are admitting (not in so many words, of course) many of their mistakes – mistakes that I’ve been pointing out to them since 1999 – and I’m not able to celebrate. *sigh*
The job hunt hasn’t been going well. Interviews inevitably end up on the topic of Web services, where I’m basically given a couple of minutes to make my case… which, as you might expect given how long it’s taken the industry (or at least a particularly bright subset thereof) to come this far, doesn’t go well. Do I spend 40 seconds on software architecture, another 40 on desirable properties of multi-agency network-based systems, and wrap up with REST vs. SOA/WS? Or do I hazard a guess that the interviewer is familiar with the first two and commit all two minutes to the latter? Of course, it doesn’t matter either way, because there’s no chance in hell of successfully summarizing 7 years of arguments into 2 minutes. Couldn’t these companies at least have somebody interview me who’s familiar with this debate? Most of the ones I’ve talked with have people who were part of that debate, ferchrisakes! *sigh*
On the upside, I have managed to craft quite an elevator pitch involving getRealtimeStockQuote, getStockQuote, and GET. But even if I manage to get that point across (which does happen), nobody’s yet managed to convert that minor epiphany to a broad appreciation of the uniform interface. I watch their eyes, and you can see the exact moment where they give up trying to figure it out for themselves, and instead fallback to the familiarity of “conventional wisdom”. *sigh*
Anyhow, despite things not going well with most of the 14 companies I’ve interviewed with, it looks like my quest might finally be coming to an end (the good kind 8-). Stay tuned.
(Doh, I lost this one in my queue, hence its tardiness)
It’s too bad his comments are gone, because this “response” to his piece on microformats doesn’t exactly warrant a separate blog entry. But here it is anyway.
Regarding extensibility, I think the “middle name” issue Dave has is really with the vCard format, from whence hCard inherits its descriptive semantics (i.e. vCard has no concept of “middle name”, only “additional names” – hCard has support for this via the *-Name classes, though I admit it’s underspecified). IMO, the microformat approach in general, has a very good extensibility story; extension classes are ignored, while extended content is ignored by automata, but rendered to humans. Plus there’s also a nice hack for cases where machine-processability gets in the way of human-friendliness; “display: none” in CSS.
In fact, thinking about it some more now, I think the bulk of the innovation in (and coolness of) microformats is exactly that it works within the constraints of existing extensibility points in a pervasively deployed format. Anybody can invent a new format, but it takes genius to reuse an existing one.