Tell me again... what's a requirement for being "Enterprise"?



  • I've been a regular reader for a while -- in fact, this site is a major inspiration for my enterprise software decision making.

    However, I still haven't quite managed to pin down the exact definition for "enterprisey".

    For something to be enterprisey, does it need:
    1) more support personnel than any non-enterprisey system
    2) more moving parts than a comparable system that's not enterprisey
    3) a very large number of users being inconvenienced when it fails
    4) a high price tag
    5) something else
    or
    6) all of the above?

    Honestly, I'd like to know. I'm working with a horizontally scalable database system, but given that it's based on free databases in the bottom and just a single C++ process on top, I'm afraid our system might not qualify for "enterprisey, " so I need to know what we're missing.



  • @Jon W said:

    I've been a regular reader for a while -- in fact, this site is a major inspiration for my enterprise software decision making.

    However, I still haven't quite managed to pin down the exact definition for "enterprisey".

    For something to be enterprisey, does it need:
    1) more support personnel than any non-enterprisey system
    2) more moving parts than a comparable system that's not enterprisey
    3) a very large number of users being inconvenienced when it fails
    4) a high price tag
    5) something else
    or
    6) all of the above?

    Honestly, I'd like to know. I'm working with a horizontally scalable database system, but given that it's based on free databases in the bottom and just a single C++ process on top, I'm afraid our system might not qualify for "enterprisey, " so I need to know what we're missing.


    <FONT face=Tahoma color=#000000>You can add: uses XML database... :)



    </FONT>



  • 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".


  • Thanks for the definition; this helps a lot. I'm glad to report that we already comply with at least 50% of these requirements.



  • @Oscar L said:

      • 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.


    When using Oracle, it's of course important to require the Enterprise Edition of Oracle, although the application uses absolutely no EE-specific features, since Enterprisey Applications do not use any advanced features of any database at all. Instead, they use database systems like they were odd file systems. If someone asks "isn't it possible to use the standard edition", the (almost obvious) answer is: "Only the Enterprise Edition has been certified for our product."
    The same goes, of course, for any other database systems - only the advanced edition is good enough, "standard" isn't.



  • @ammoQ said:


    When using Oracle, it's of course important to require the Enterprise Edition of Oracle, although the application uses absolutely no EE-specific features, since Enterprisey Applications do not use any advanced features of any database at all. Instead, they use database systems like they were odd file systems. If someone asks "isn't it possible to use the standard edition", the (almost obvious) answer is: "Only the Enterprise Edition has been certified for our product."
    The same goes, of course, for any other database systems - only the advanced edition is good enough, "standard" isn't.


    Hell, there are "Enterprise" solutions that don't even use the features of the Standard version of the database.  For example, I'm working with an "Enterprise" document management system right now running on top of Oracle Standard.  Very few of the primary keys are managed by the database via sequences, there is a separate table the stores them and the application manages them. Also there are no persistent stored procedures other than the ones I wrote.  I did a string dump of the executable and the data access component dynamically creates procs, executes them and then drops them.  Don't even get me started on their web interface (a beefy webserver can only handle 10 users before CPU utilization goes above 80%).  And my fellow employees wonder why performance is an issue and want me to come up with "Solutions".  They don't like my solution - buy another product.

    The problem really exists on the customer side of the equation.  What I call the "used car salesman" of technology companies exist only because customers allow themselves to be duped by buzzwords rather than doing a robust comparison of competing products.  If these type of customers didn't exist, then the so called "Enterprisey" solutions wouldn't either.  When choosing a product, one should compare competing products under your expected workload and not only talk to existing customers, but visit them as well.  The problem is a lot of companies don't do a robust evaluation and don't understand the concept of "go slow upfront to go fast later", so they end up with a product that only does 50% of what they actually need.



  • @lpope187 said:


    the data access component dynamically creates procs, executes them and then drops them


    It does what? How are they going to handle concurrency issues with that method? Not to mention the performance penalty.



  • I'm absolutely serious that the product creates store procs on the fly.  When I came on board, I jumped into the middle of the implementation of the product, so I started digging into the internals.  I looked at the database via Toad and saw no stored procs or packages and maybe two or three sequences.  I thought this was odd, so I used SysInternals Process Explorer to do a string dump of the data access layer executable and something like this was in the output (forgive my parameter syntax, doing this from memory).

    Create or Replace Procedure Blah ......

    Execute Blah @1, @2 ...

    Drop Procedure Blah ....

    I'm not the greatest in terms of Oracle, so I don't know what the implication of dynamic proc creation is across sessions.  I really wouldn't know the answer in any database for that matter, since this is a braindead approach. 

    I think the concurrency issues are mostly resolved by versioning all the documents, so you never update an existing record - it just creates a new record with an increased version no and all the new values.  The only place where I can see concurrency issues is in the Check-Out table, but we haven't seen any issues with that so far.  Since all the SQL is inside the executable, the only way I can really determine what's going on is via a trace and that just kills performance.

    From the database perspective, performance isn't that bad.  I've hit it pretty hard with an extremely high load test script and Oracle performed very well despite the poor design.  That is of course after I optimized the vendor's install (tweak memory settings, actually building maintenance plans, etc). 

    The rest of the layers are another issue.  I can't wait until we rollout globally and get thousands of concurrent users on the system.  I see many a long hours of me fixing this product. 



  • Now this is a real WTF. First, it's completely unnecessary - there is a thing called "anonymous PL/SQL block" for those programs which want to run PL/SQL on the fly (without creating a procedure).
    Second, what happens if two users run that part of the program that tries to create the procedure at the same time? Weird things are likely to happen.



  • @ammoQ said:

    @lpope187 said:

    the data access component dynamically creates procs, executes them and then drops them


    It does what? How are they going to handle concurrency issues with that method? Not to mention the performance penalty.

    Somewhere, someone is laughing all the way to the bank as he counts out the fat wad of cash he earned producing that product.  Hard-coded dynamically generated procedures, most likely varying only by input parameters.  What's that called again?  Paramteriz-what?

    Who wants to bet that the source code is generated by a master application after being customized by the twiddling of knobs and flipping of switches, compiled, and then handed off to the client as if a lot of work went into it?

    I can see the sales pitch now.  "All you need is an instance of Oracle running somewhere - no complicated install scripts!"



  • @Oscar L said:

    Somewhere, someone is laughing all the way to the bank as he counts out the fat wad of cash he earned producing that product.  Hard-coded dynamically generated procedures, most likely varying only by input parameters.  What's that called again?  Paramteriz-what?

    I found this little gem in the string dump file.  Apparently they know how to do variable value replacements in C/C++ with printf, sprintf, fprintf. But that concept is lost when it comes to SQL.  Is it just me, or does this scream stored procedure or at the very least parameter binding? 

    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 1
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 2
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 3
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 4
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 5
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 6
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 7
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 8
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 9
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 10
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 11
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 12
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 13
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 14
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 15
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 16
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 17
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 18
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 19
    UPDATE REPORT_DEF SET %s = '%s', %s = '%s' WHERE REPORT_ID = 20



  • in all seriousness.  enterprise just means that it's an enormous program that a large company paid lots of money for (often in the hundreds of millions) that is built specifically for that company and operates as a major component in the everyday working of the company. 


  • BINNED

    From my quotes file:

    What does that mean that something is "more enterprise-oriented" than something else?!?

    It means someone actually wrote the code to check for error conditions.
    If you log the error, it moves you up to "enterprise ready".
    If you actually do behavior based upon the error you get the rarefied
    echelon of "enterprise class".



  • @lpope187 said in Tell me again... what's a requirement for being "Enterprise"?:

    I think the concurrency issues are mostly resolved by versioning all the documents

    That only keeps you from modifying the same "version".

    It doesn't stop concurrency in the versioning of the version. Unless the version number are guids.


  • Notification Spam Recipient

    Holy crud!How do you manage to necro a thread in NodeBB????

    @antiquarian said in Tell me again... what's a requirement for being "Enterprise"?:

    From my quotes file:

    Oh, nvm, do carry on.


Log in to reply