Specifically regarding the examples you mentioned, yes. The way I've tried to draw a line between infrastructure and applications is to look at the domain of the solution. If the domain of the solution can be applied somewhat universally across verticals, it's infrastructure. If the domain of the solution is aligned to a vertical domain or a small number of domains, it is an application. To point out the simple example that one might use to refute this, a human resources system would still be an application in my book. While all enterprises have HR departments, it's still a specialized vertical. You can't take HR software and apply it to a manufacturing problem. All of that being said, my view on the space is that it is a continuum, and not necessarily black and white. At one end of things is very general purpose, generic items that have high potential for use in multiple areas, and at the other end are things that are very specific to a particular domain that have low potential for use in multiple areas. Things at the first end are unlikely to be differentiators, while things at the other end are. These are generalities, however, not hard and fast rules.
-tb On Apr 2, 2007, at 12:05 PM, Bill Barr wrote: >> One thing I'll point out, however. My definition of >> "infrastructure" >> in my original email was the low level plumbing, i.e. >> physical servers, operating systems, networking appliances, >> etc., not >> applications. > > Should we consider firmware ESBs low level plumbing? I think we > should. > That's just one step away from considering software ESBs as low level > plumbing. Then again, there are lots of other things we should be > considering as low level plumbing: web servers, application servers, > databases, virtual machines ... Aren't they all just soft appliances? > > > -- > email: [EMAIL PROTECTED] > > > > Yahoo! Groups Links > > > [EMAIL PROTECTED] >
