 Monday, January 10, 2005
|
|
|
|
The Entrepreneurial Mind, via Carnival of the Capitalists and Jeff Nolan:
It is good to be smart. It is even better to be lucky. But, it is critical to know the difference. I have seen too many entrepreneurs confuse luck with brilliance only to come crashing down to earth when their luck runs out.
Yeah, seen a few of these myself. And some of those crashes were mighty loud, too.
|
|
|
|
|
Over the last few days I've had a number of interesting discussions, most notably with my pal Satish Thatte, on the role of an integration broker in a service-oriented world.
Here's the conundrum (or at least thought experiment): today, integration servers largely serve the purpose of normalizing, or at least putting a facade upon, a wide variety of heterogeneous API's, protocols, data formats, security models, transaction models, and so on.
Now, let's posit a world in which all legacy protocols and formats melt away in favor of SOAP, XML, and WS-*. We all know that this transition won't happen overnight -- it may take decades, but that the transition over some period of time is inevitable is our assumption. So, if all these messy issues are going away, then does the integration broker go with them?
Put a different way: if every business application in your computing ecosystem exposes rich, standards-compliant services, then does the traditional hub-and-spoke model of integration still have value?
Yes! It unquestionably does, and for many reasons. First, think about semantic normalization. Big words, but they have lots and lots of implications. If you want to build an enterprise application, you need a common vocabulary: what's your definition of a "customer," a "SKU," an "order" and so on. Every enterprise app has its own set of proprietary, idiosyncratic definitions. In the old days of silo'd applications this was fine; but today, we want a "whole is greater than the sum of the parts" effect. Bringing this distributed information together to form a consistent and rich vocabulary, tailored for the enterprise in question (you call them "customers," I call them "households") is a key value prop for integration brokers.
Second, how do we link business applications together in an orderly, structured, and manageable way in order to build the meta-applications (or composite applications) of the future? We need a refined notion of sequencing of services, of process, and we need a hosting environment where those processes can run, can be monitored, can be tracked. In the bad old days it was easy to do quick and dirty integration applications by writing a little VB here, a little Java there, and getting the data from one system to another in a point to point way. But as we learned, this didn't scale; it was completely unmanageable. Today we recognize we want a server that provides the process execution environment.
Now, while all this sounds generically good, as you might expect there are some vested interests here. Some ERP vendors see SOA as a way to make external applications appear part of their fabric, thus further entrenching them. That is to say, you take external apps, and using services you make them appear to be part of the ERP system you already have. This might appear to be precisely the opposite of SOA's stated goal of abstracting underlying system functionality, but for these ERP vendors, that objective has little appeal.
On the other hand are the horizontal vendors whose goal is provide a programming environment for next-generation distributed business applications. The goal here is not so much to extend an existing deployment, but rather to realize all the goals of SOA: to provide a semantically rich, powerful foundation for composite business applications. The horizontal approach gives maximum flexibility to business owners by positing a fabric of services generated top-down by business requirements, and not bottom-up by rationalizing and deeply entrenching existing systems.
|
|
|
|
|
Sorry for the somewhat protracted hiatus. My typing fingers are itchy, so stand by!
|
|
|
|
January 2005 |
Sun |
Mon |
Tue |
Wed |
Thu |
Fri |
Sat |
| |
1 |
2 |
3 |
|
5 |
6 |
7 |
8 |
9 |
10 |
|
|
|
|
15 |
|
17 |
|
|
20 |
|
22 |
23 |
24 |
|
|
27 |
|
|
30 |
31 |
|
Dec Feb
|
