One of the reasons you're having trouble pinning down a definition for enterpriseyness is that you're assuming it's a static, definable concept. This is a very 1.0 way of understanding enterpriseyness. Enterpriseyness is not something you "define", and such attempts belong in academics, government, law, and other old economy establishments.
A better way to approach enterpriseyness is to look at it as a fluid, ever-changing non-entity, or in more 2.0 terms, it is agile and dynamic. You and your product do not "define" enterpriseyness, and your product cannot "become" enterprisey. You must realize that you and your product are enterprisey. Here is a snapshot of modern enterpriseyness that will hopefully help you better understand. Please make sure to read it quickly, as it will probably expire sometime in the next fifteen minutes or so.
Oscar L's preliminary guide to enterpriseyness
- Holistic concerns
- Use of the word "holistic" - you will often see this word appering near the term "self-healing"
- Powerpoint presentation to accompany the product
- A "subscription model"
- Glossy brochures and pdf versions available on your website
- No mention of price in marketing materials or any online documentation
- Copious use of the word "Enterprise" and variations such as "Enterprise Class", "Enterprise Scale" (compare: Internet scale)
- Please note that attention to the holistic concerns is at least as important as the technical concerns listed below
- Also note that understanding any terms in this document is unnecessary to the enterpriseyness of an application, so long as something in your product consistently adopts all of the monikers here somewhere
- "Technical" concerns
- Message Queues. Lots and lots of Message Queues. You can't have enough message queues
- The above spelling of "queue" is required
- Things called "repositories". For instance, the XML database xrT mentioned should be referred to as a repository in all glossy brochures
- Your product must be compatible with something called an "Enterprise Service Bus". The buzzword you use to refer to this concept varies by client bias for various major vendors
- Your product must expose services and implement a service oriented architecture
- Until recently your system would require Oracle databases. DB2 also commands some respect, especially with clients where it is appropriate to use the "Enterprise Service Bus" term mentioned above. SQL Server is gaining acceptance, but any free database is woefully inadequate.
- Your "architecture" must require a bare minimum of one mainframe or full rack of machines to operate
A few things that would help increase the enterpriseyness of your application are actually possible simply by changing some of your wording. Here are some recommendations:
- "horizontally scalable" - This is a "scale-out" architecture, not a horizontally scalable architecture. Compare to "scale-up"
- "free databases on the bottom and just a single c++ proces..." - This is your "stack", and you should only refer to your system as a whole with the term "enterprise service stack", being careful to note the additional injection of the word "enterprise" and the implication that it implements a service oriented architecture.
- "free databases" - You will want to drop "databases" and replace "free" with "Open Source" if you're set on keeping your piddly free database. This is the "foundation" of your "stack".