As I sat on the couch for the second consecutive day fighting a miserable cold, two of my favorite blog postings of the year popped into my inbox (thanks, Attensa).
First was Muli Koppel's blog. Are you reading this yet? He writes what is positively the most intelligent blog I've ever read. He doesn't get the attention that some other bloggers do (because he doesn't write about Web 2.0) but believe it or not: there are really smart people writing things that aren't Web 2.0. Muli is one of them. Every post is well thought out and well written, and I read each several times. He has more content per word than anyone blogging.
Anyway, Muli's post today was called Meant for Each Other: Enterprise Architecture and SOA. He begins with the most practical definition for Enterprise Architecture that I've ever read:
Enterprise Architecture is an infrastructure and a set of Machines constructed in order to manage a chaotic, dynamic, unpredictable, complex, organic, prone to error, frustrating, Enterprise IT, which has to support an ever increasing, dynamic portfolio of products and services, through constant "ASAP, Now, Right-Away" modifications of business processes.He goes on to talk about the discussions that are happening in the industry about EA and SOA, and he sums it up thusly:
EA will shake off its image as a "documentation, procedures and guidelines" body, repositioning itself as a practical, implementation-oriented discipline aimed at the creation of an Enterprise Management Infrastructure, while SOA will be repositioned, no longer as an Integration/Interoperability architecture, but rather as an Enterprise Management architecture.One of Muli's gifts (both as he blogs and, I surmise, in his career) is to make sense of the buzzwords of the day in practical terms. Seriously, stop reading here, and go read his post. Then come back.
Of course, now that you've read it, you know my favorite quote from the post. I'll quote it here:
There are, clearly, other infrastructures and machines to add to this picture. For instance, grid/utility computing is an essential part in the real-time Enterprise...Ok, enough stealing Muli's material. The other post that fell into my inbox today was from Greg Nawrocki's Grid Meter: today's SOA developers .... tomorrow's Grid developers.
Greg wants to know why, while SOA and grid have been hyped for a few years now, SOA is gaining much more traction.
As reasons for SOA's success, he notes that there are a wide range of languages available (I was glad to see him include the .NET languages along with Java), but notes that the real reason is "that you can actually take relatively mainstream enterprise applications and write to a service with a simple API." He's right of course. While as many people (including Muli have pointed out), SOA ≠ Web services, SOA is certainly enabled by web services.
Greg notes that the Globus Tookit 4.0 embraces WSRF and he points to an IBM paper that details building a grid and implementing Globus.
Greg is right on in noting that there is a real convergence between grid and SOA. SOA cries out for a scalable architecture, and a Web service enabled grid is perfect for building that architecture. But as long as an implementation requires a lengthy consulting contract (which, after all, is why IBM is writing papers about it), grid can't really take off.
People need tools that are easier to use and grid systems that are easier to implement. Globus is the pre-eminent standard toolset for building a multi-organizational grid, but its implementation is too difficult for a small to medium sized venture to undertake.
In the meantime, of course, there are vendors who are making the tools to make these types of architectures available today. (We're not the only ones, but we're the only ones doing it on .NET). Anyone who wants a grid right now (not in the future) should be looking to these toolsets to help them build that grid today.