Beefy Boxes and Bandwidth Generously Provided by pair Networks
Syntactic Confectionery Delight

What is Enterprise Software?

by brian_d_foy (Abbot)
on Oct 30, 2005 at 21:22 UTC ( [id://504043]=perlmeditation: print w/replies, xml ) Need Help??

What is "enterprise software"? Maybe you think you know what it is, but can you put that into a simple sentence? Can you put it into a sentence that doesn't use "enterprise", or "software"? Let's say that you could do that. I'm sure that many of the readers have been able to do that. Now, how many of those definitions agree with other?

I've recently become interested in "enterprise software" as a Perl advocacy topic, but to talk about it, I need to figure out what it is. I thought I knew what it was, but when I tried to define it, and by that I mean including that things that I think are and excluding those things I think aren't, I didn't find it so easy. Maybe the Monastery can help me.

I went to Google to see what I can find. If you wanted the quick answer, you're reading the wrong essay. I don't have the quick answer, or even an answer, much less the answer. Google has the quick answers, and no end to them either: just pick the first one you like.

Besides that, I found the usual glib statements from frustrated techies who confused the general ineptness of big business with "enterprise software". Their definitions revolved around the cost, the code quality, and the project management type.

Look again at that middle quote. Does anyone recognize that? It's from the Perl 5 Enterprise Environment (p5ee) documentation. I didn't realize its source as I was reading it. Curiously, p5ee actually laid out a definition of what it considers "enterprise software" to be.

  • Availability - the assurance that a service/resource is always accessible
  • Scalability - the ability to support the required quality of service as the load increases
  • Reliability - the assurance of the integrity and consistency of the application and all of its transactions. The ability to provide a required reliability service level depends on the close coordination of the hardware, networking, operating system, storage subsystem, application framework, and application software.
  • Security - the ability to allow access to application functions and data to some users and deny them to others
  • Interoperability - the ability of the system to share data with external systems and interface to external systems.
  • Leveragability - the ability that stored data, programmed logic, and other system resources available anywhere in the enterprise should be accessible from everywhere in the enterprise
  • Maintainability - the ability to correct flaws in the existing functionality without impacting other components/systems
  • Extensibility - the ability to add/modify functionality without impacting existing functionality
  • Manageability - the ability to manage the system in order to ensure the continued health of a system with respect to scalability, reliability, availability, performance, and security.
  • Portability - the ability of the software to run on a variety of hardware and operating system configurations
  • Accessibility - the ability to access system functions through different user agents and in different human languages

The p5ee page cites this definition from the Gartner Group:

Software products designed to integrate computer systems that run all phases of a businesses' operations to increase internal coordination of work and cooperation across an enterprise. These products facilitate the integration of core business operations and processes, including sales, accounting, finance, human resources, inventory and manufacturing. An implementation might involve a single application, or portions of a single application, or an enterprise system could control all major business processes in real time, via a single software architecture on a client/server platform. In the future, enterprise software will also play an important role in external linkages with suppliers, business partners and customers. A subset of enterprise applications, enterprise resource planning (ERP), software was developed for manufacturers as the next generation of manufacturing business systems and manufacturing resource planning software.

I don't have much to disagree with there, but I don't think that quite gets to it either. I think most of those things apply to whatever "enterprise software" isn't, too. Most of those things depend on quality and design. For instance, why should interoperability or portability matter? Those things are nice to have, certainly, but why should they limit what can be in the enterprise club? I still haven't defined anything, and I still really don't know what I'm talking about.

Instead of delving into it, I want to fly above it for a moment. Never mind that no one can really define "enterprise", what is an "enterprise foo"? How does something get the "enterprise" in front of it? No, scratch that. Why should anything be qualified as "enterprise"?

I started to make a list of things that I think belong in "enterprise resources". I listed seemingly banal things, not but by design. Somewhere in my head there must be an internal definition:

  • Water
  • Electricity
  • Network connection
  • Information
  • ....

When I think about "enterprise", I don't think about who is involved or what they are doing. Are they using that water to wash their hands, make coffee, cool a nuclear reactor? Are they techies, sales people, or janitors? In my mind it doesn't matter who they are and what they do. The "enterprise" needs the resource for everyone.

Does that apply to software too? Is "enterprise software" something that everyone needs? Is Microsoft Word "enterprise software"? How about Oracle? More interestingly for me, is perl "enterprise sofftware"?

According to the list I just made, enterprise resources are things that come from a common source and that everyone shares. I don't think I can hammer the square peg of locally installed software into that round hole. (I can't really keep it out, though either, so you might rightfully disagree since no one can agree on things). So, I'm going to rule out Microsoft Word. Indeed, I think some people can safely get rid of Word, perhaps using OpenOffice or something else, and no one would be the wiser. Oracle, on the other hand, tends to be installed in one big place and people share it. I'll include that as enterprise software.

The common source also implies that a failure at the source affects everyone. Put a backhoe into the water main and the city shuts off the water (depriving everyone) until they fix it. If someone's desktop computer crashes, it sucks to be him, and maybe the people next to him who have to listen to the screams. The reaching effects of failure are the center of the p5ee definition, by the way.

Perl is decentralized though, so if it blows up in one place, it might be fine in another. Additionally, even though its installation is decentralized, it's source is not. What if some IT guy forgets to pay the license fees for Microsoft Word (or whatever) and they turn off system wide simultaneously? Yep, this is quite the sticky wicket.

These things are intangibles though. Most people (and that includes the population of the universe) don't really use Perl, although they use things that use Perl. Most people directly use the water, electricity, and other things I included in my list. The same goes for Oracle, or SAP, or whatever. They probably use things built on top of those things though. Maybe enterprise software isn't the building blocks, but the buildings themselves, such as the online phone directory or the accounting software.

This is where things get really murky for me. I started this little journey thinking that people must just be really stupid to not be able to pin this down, but I haven't been as successful as I think I should have been. I'm one of the dummies, apparently.

At the moment I've ruled out the components of a system, such as the programming language and the database server, and written in the things created with them. Things bifurcate from here: there is stuff that you can buy and there is stuff that you can make. Does it matter where it comes from or who makes it? If you believe the glib comments you can find on Google, it matters because enterprise software is expensive and built by teams of hundreds. I think, however, that a couple of interns who throw together a CGI::Prototype implementation of the company phone directory can be just as useful to everyone as an expensive third party product to do the same thing. The interns can might something even more useful because they can do anything they like.

From there, does size matter at all? When I think of groups, how big does it have to be for it to qualify as enterprise? The perl interpreter, for instance, doesn't have a huge development team, but its running some really big projects. It's just a building block though. However, being that Perl is pretty powerful, small groups can use Perl to create really big things. I don't have an answer for this.

Moving on, if Perl is just the building block, what characteristics do I think enterprise software should have? The p5ee folks laid out what they think, but they didn't hit most of the things I thought up in my list. At the top of my list was configurability. The difference between the hacked up script and a tool designed for use by many people is the ability to decide parts of its input and behavior. That is, the enterprise software is designed for use by more than one person.

After thinking about those a while, I gave up on configurability. It would certainly be nice if things were configurable, but does it matter if it is? I've made the assumption that a lot of people are going to use this thing in different ways. I haven't allowed that as part of the definition though. Of course, it doesn't have to be configurable by everyone, but someone somewhere sets something up or defines some templates.

Does this exclude "turnkey" software then? Some people don't want to configure anything. They want to plug it in, turn it on, and let it go. Why should let be any less enterprise if everyone still uses it? Most people care more about information than they do about colors and "dancing monkeys", as I use to call them.

At some point, I have to stop equivocating. I can go back and forth ad infinitum without gaining any more insight. Perhaps this is the sort of question you're supposed to take into the monastery with you so you have something to think about for the rest of your life. So, after all this thought (wasted mostly), stopping here, my definition for enterprise software is simply this:

Software whose failure everyone notices quickly.

In that short statement is the notion of the common and shared source, the use by people doing different things, and its importance to the users. The Gartner definition fits nicely in there, but so do many other definitions. It includes most important parts of the p5ee defintion. It also fits small, medium, and big business as well as web applications such as LiveJournal and MovableType. It's not enterprise software if no one realizes it doesn't work anymore.

This excludes perl though, strangely. If the perl5porters totally screwed up perl5.9.x (very unlikely), a lot of people won't even notice. There are people still waiting to find the problems in perl5.8. But it also includes perl because a single installation can screw up all the users of something else.

Finally, is perl enterprise software? Well, there's more than one way to answer that (TMTOWTAT - Tim Toe Tat). Ask me again next week, and if you don't like that answer, just wait another week.

Replies are listed 'Best First'.
Re: What is Enterprise Software?
by BrowserUk (Patriarch) on Oct 31, 2005 at 01:26 UTC

    I think it means different things to different people, with the major difference being dependant upon whether you are buying or selling--but more on that later.

    A definition for definitions sake might go something like:

    Software that's purpose is to gather, store, collate, re-present and communicate information across all job-roll, departmental, divisional and site including country, boundaries within an organisation.

    In most cases it will probably not be directly involved in revenue generation, serving a support and control function rather than a core revenue generating role. It can be seen to serve a similar purpose to HR and Legal and Corporate departments within an overall organisation, and it's ROI is equally hard to measure.

    In most cases, it will form a net cost burden that must be spread across all areas of the organisations revenue accounts.

    Libraries, utilities and tools used in the creation and/or enabling of such intra-organisational (inter-departmental) applications may also be (loosely), so classified.

    It may also play some role in the organisations communications with it customers and suppliers in etrading, promotional and communications roles.

    A couple of rather cynical takes on the term are:

    • In the purchasing department:

      It sounds important, like something we ought to have.

      It can be expected to come with on-going technical support (with the costs spread across many peoples budgets, where it will form a small chunk of a larger single figure, that people will find hard to break down and point fingers).

      With ROI seemingly impossible to gauge, it is unlikely to come back and bite me in the arse.

      If the company profits increase after it's deployment, I can stand up and point to it and claim qudos for having deployed it.

      If profits decrease, it will be exceedingly hard for anyone to point the finger at me and say "It's his fault!".

    • From the salesmans point of view, the inclusion of the term "Enterprise" or "Enterprise Edition", means that

      They can charge double for the product up front.

      They can charge double for on-going support and mainenance.

      And if things go wrong within a deployment, it can be attributed to it being wrongly deployed, wrongly used, incomplete coverage or lack of departmental cooperation.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      So it sounds like you're going with the Gartner definition. I think your frist sentence pretty much states its case without weasel words or smoke and mirrors. I'm not so sure that the rest that you include are part of the definition (that is, form a test that the software would have to pass) so much as state the likely consequences.

      From that definition, "enterprise softwware" would either have to be this huge, monolithic system fully provided by one vendor, or all of the parts of a cobbled together system. From that, perl could be part of an enterprise software system, but it not itself.

      I guess that makes sense.

      brian d foy <>
      Subscribe to The Perl Review
      Software that's purpose is to gather, store, collate, re-present and communicate information across all job-roll, departmental, divisional and site including country, boundaries within an organisation.

      That's pretty good. I usually add in there the necessity to communicate with other pieces of software as distributed resources. Availability isn't as important a criterion as integration, at least as I see it.

Re: What is Enterprise Software?
by renodino (Curate) on Oct 31, 2005 at 01:18 UTC
    Software whose failure everyone notices quickly.

    Probably a good definition, but not for the reasons you'd think. If you've ever been involved in a Java/COM/.NET "enterprise" adventure, you'll know that "everyone" means the CEO/CIO who's gotta fire somebody, and quick!

    My definition of enterprise software ?

    Something that costs at least one order of magnitude more than a reasonable solution to the problem should.

    Before you dismiss my definition, consider this case in point:

    I've developed both a Perl DBD, and a JDBC driver, for a large scale "enterprise" database system. When I attempt to solicit a modest price for the DBD, I am greeted with silence and occasionally derision. When I ask >US$10K per license for the JDBC driver, many sites happily fork over the money and the JDBC driver was derived directly from the Perl driver!.

    I suspect most of us know that many (most?) things being done under the auspice of "enterprise" J2EE could easily be delivered with Perl (or python, ruby, PHP, et al) for a 1/10th the time and money. But Perl/Python/Ruby/etc. don't have an army of marketing suits telling PHB's that its "enterprise".

    In summary, "enterprise software" eq "marketing grot".

    If your purpose is to market Perl, then you'll need to discuss its scalable paradigm shift in the context of re-engineering the enterprise to repurpose the legacy platform solutions in the context of grid computing frameworks for exposing service oriented architecture access via the empowering technology of dynamic language implementations.

      To be fair, though, Java or .Net or anything else we like to demonize aren't the only things that can break for executives. Plenty of Perl things can do that too. However, that only a couple of executives notice something breaking doesn't qualify things as "enterprise", I don't think.

      I've alrady considered your answer and I think it's glib and purposedly avoids the question. I'm not trying to talk about how stupid businesses can be or how messed up the software development process is, or how people beleive hype that they shouldn't. I don't think enterprise software has to be marketing hype (although I might beleive that marketing hype invented the term).

      brian d foy <>
      Subscribe to The Perl Review
        To be fair, though, Java or .Net or anything else we like to demonize aren't the only things that can break for executives. Plenty of Perl things can do that too.

        Except that Java/.NET will usually fail after > 10x the investment of the equivalent Perl/Python/Ruby/etc. solution.

        My comment may be glib, but 25+ years involvement in "enterprise software" (as both producer and consumer) leads me to believe it isn't false.

        Many of us have experienced the way that overly complicated nonsolutions get pimped as "enterprise", tagged with a massive price, and folks can't buy them fast enough. Meanwhile, elegantly simple solutions - some often free - are overlooked cuz they don't have a SKU code, a suit to pimp them, and someone to sue if they fail.

        Does my answer avoid the question ? I don't think so; in fact, I think it directly responds to the appellation in question. You presented a rather lengthy dissertation about what "enterprise software" might (or might not) be, and end up with a (IMHO) trite generalization. Your generalization, in itself, should indicate the question may be searching for technical confirmation for a pure marketing term. I.e., the premise that there actually is a technical, rational definition for "enterprise software" may be flawed.

        Based on your definition, if there's a bug in the firmware in my digital watch that also effects everyone who bought one, its enterprise software. For that matter, any of the numerous failings of MSFT's various Windows platforms also qualify it as enterprise software, tho Win95 seems an unlikely candidate for that classification.

        I'll offer another glib, albeit true, definition:

        If a manager (CIO or otherwise) gets fired when it fails, it's Enterprise Software.

        Think about that for a bit: if its just a desktop app of convenience (e.g., Word, Excel, Outlook, etc), that breaks, the CIO won't even be advised of it (except when some sysadmin shows up to install the patch). But if the Exchange server screws up and sends a copy of everyone's salary to the entire organization, somebody is likely going to get an escort from security.

        Here's another glib, albeit true, definition:

        When Enterprise software fails, there's someone to sue.

        Thats a major part of the reason PHBs pay the extra order of magnitude - and why it costs an extra order of magnitude. Again, its not a techie answer, but quite possibly (at least in the Litigious States of America) is what the purchasers of "enterprise software" are really looking for. (It lets them sleep better at night... hmmm, maybe thats another definition ?)

        So far, both our definitions seem to define enterprise software as a product defined by its effect when it fails, and (in my case) by its cost. So lets think about the opposite:

        • Enterprise software is software that demonstrably contributes to the success of the enterprise.
        • Without the enterprise software product, the enterprise would either fail, or would otherwise demonstrably suffer.
        Based on those definitions, I'd say Perl is undoubtedly enterprise software in many enterprises. Yet, if you collared the CIO's of those enterprises and asked if they agreed with that notion, they'd likely nrevously laugh at you, or otherwise ignore the question (very likely cuz they don't know what Perl is). For that matter, ksh, "Command prompt", and IE fit the definition as well.

        Since that seems to fall short of a full definition, here's another glib definition:

        Enterprise software is something complicated enough that a CIO will pay an order of magnitude more than its actually worth, regardless whether it actually solves the original problem.

        So we're back to square one. There is no definition. "Enterprise software" is not a provable term. It's not 3NF. It's not O(NlogN). It may be NP complete. The value of the limit of enterprise software as it goes to zero is unknown.

        Because its just a marketing term.

      You have brought up a very good aspect about enterprise software. Although at first glance, enterprise software is measured by a set of technical requirements (although not really that measurable ;-), it is certainly created with a clear and strong marketing purpose there.

      Have said this, you have to give credit to some of those softwares, such as Oracle. Things like MySQL obviously does not provide the same level of strength (at least not currently).

      But when a software is called enterprise, it is not just about techonology, it is about to charge companies that are at the enterprise level.

        Things like MySQL obviously does not provide the same level of strength (at least not currently).

        BZZZZT! Try again. I wrote a reporting application that was backed by MySQL that returned complex reports against several million-row tables back in under a second. What's not enterprise-level about that?

        My criteria for good software:
        1. Does it work?
        2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: What is Enterprise Software?
by dragonchild (Archbishop) on Oct 31, 2005 at 01:05 UTC
    I don't think there is such a beast as "enterprise software". I do, however, think that there is such a thing as an "enterprise resource". If you look at the items you described (water, power, connectivity, information), the common theme is that there is a resource that is used. The mechanism by which that resource is distributed isn't the important factor.

    Taking connectivity as an example, you can provide that resource using CAT-5, twisted-pair, wireless, optical ... the list goes on and on. In fact, connectivity is often provided over a combination of those methods. So, which connectivity method is "enterprise-level"? Well, it depends on what the enterprise requires. Many enterprises wouldn't consider twisted-pair to be "enterprise-level," because it isn't powerful enough. But, many other enterprises use it quite nicely.

    I think the same goes for programming languages, only moreso. Programming languages don't actually distribute or store an enterprise resource. They provide the foundation for creating the tool(s) that distribute or store said resource. Oracle is an enterprise-level application because it can store and search information with the requirements an enterprise has concerning said information. One would need to speak about an application written in Perl that meets the need of information distribution. For example, no-one would deny that Amazon or CitySearch are "enterprises." They both use Perl, which means that Perl can be used as a foundation for building applications that can store and/or distribute enterprise resources.

    In that regard, every single programming language in common use* can be used to build an application that handles an enterprise resource. One now has to discuss the costs and benefits associated with writing a given application in a given programming language. For example, when writing a web application, no-one seriously thinks that C is the appropriate way to go. Yet, C is the only language used to write the webserver or an enterprise-capable RDBMS. That's the same calculus, by the way, that's used to evaluate MySQL vs. SQL*Server vs. Oracle. There's no reason it shouldn't be applied to programming languages in the same fashion.

    *: Befunge and Brainf*ck need not apply.

    My criteria for good software:
    1. Does it work?
    2. Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
Re: What is Enterprise Software?
by itub (Priest) on Oct 30, 2005 at 21:54 UTC
    After reading your meditation, I still don't have a clue. Maybe I'll fall back to the theory that "enterprise software" is just a meaningless buzzword...
Re: What is Enterprise Software?
by pg (Canon) on Oct 30, 2005 at 23:06 UTC

    The dirty water you are trying to clear up is actually much cleaner than you thought or presented, at least in lots of other people's minds.

    First of all, Perl is not enterprise software. Period. You have clearly said that you were interested in Perl advocacy. To make it fair and even, none of other programming languages is enterprise software. As a matter of fact, I never heard anyone said the opposite before. All what I have heard were things like, foo language can easily support enterprise software.

    "Perl is decentralized though, so if it blows up in one place, it might be fine in another."

    The above was just one example where you tried to fit Perl with the definition of enterprise software. Perl certainly has nothing to do with either centralize or decentralize. An application does, and that application could either be written in Perl, or Java, or some other languages.

    To the minds of most people, Oracle is enterprise software. Oracle itself, or any other database system, is an application, and Oracle is at the high end among its peers.

      I probably should have been more clear there. The perl interpreter, java virtual machines, smalltalk environment and other such things might be considered enterprise software because you need them to make things work. They aren't similar to the output of a C or C++ program. You can run a program written in C without having a C compiler, but to run a Perl program you need a perl interpreter.

      The perl intrepreter is decentralized though. Most places don't have only one perl intrepreter that everyone has to use for everything everywhere.

      You haven't cleared the water much though. As I said at the start, many people can come up with a definition pretty quickly, but that doesn't mean that they are right or that their definition matches anyone else's. You haven't offered your own definition though, so you really haven't added anything.

      brian d foy <>
      Subscribe to The Perl Review
        "You haven't cleared the water much though... You haven't offered your own definition though, so you really haven't added anything."

        I don't think there is a need for me to provide my own definition of enterprise software to be able to contribute to this discussion. If enterprise software is a concept that everybody can come up their own definitions, then it clearly tells me that the concept is not well defined.

        "The perl interpreter... might be considered enterprise software because you need them to make things work."

        You are free to think this way, but that certainly does not prove that Perl interpreter or JVM is an enterprise software according to common sense, although they could be called enterprise software according to your own definition.

        The perl intrepreter is decentralized though. Most places don't have only one perl intrepreter that everyone has to use for everything everywhere.

        That's for sure. Not only will there be multiple versions in use in a company with a lot of machines, there can quite often be multiple versions in use PER server.

        But Perl itself is too far separated from anything specific to a business. It's a general tool. Like the C++ compiler, IMHO.

        An "enterprise application" would supposedly support the business in a very specific way, otherwise the company would use another "enterprise application" better suited to it's needs.


      I don't think it's that cut and dry. If a company paid a license for a development environment of some sort and had a development group that built customized behavior for the company in that environment, that company would consider that package an enterprise package. Perl, emacs, and the tools another group might build for themselves are no different, they are just free.

      However, this example doesn't agree with brian's definition that if it breaks people will notice. If the tools the developers build with the package break, everyone will notice. If the tools break and the developers can't do their work, people will *eventually* notice.

Re: What is Enterprise Software?
by sauoq (Abbot) on Oct 31, 2005 at 00:31 UTC
    What is "enterprise software"? Maybe you think you know what it is, but can you put that into a simple sentence?

    Enterprise software is what the computer on the starship piloted by Captain Kirk ran.

    "My two cents aren't worth a dime.";
Re: What is Enterprise Software?
by talexb (Chancellor) on Oct 31, 2005 at 03:51 UTC
      What is "enterprise software"? Maybe you think you know what it is, but can you put that into a simple sentence?

    For me, that means application software that is part of the company infrastructure.

    I specifically mentioned 'application software' to separate it from the network and/or systems software that is crucial but doesn't really fall under the umbrella of 'enterprise' software. Perl, in and of itself is not 'enterprise' software, although there may be Perl applications that fall into that category.

    I've skimmed over the other answers, and at least one refers to the 'expensive salesmen and consultants' part of Enterprise Software. Something like SAP or PeopleSoft comes to mind there. The whole 'enterprise' thing makes me squirm -- it makes me think of expensively suited and well-coiffed professionals sitting at glass conference tables pulling glossy brochures out of spanking new leather briefcases. Of course it's going to be expensive, they answer bluntly .. but how much is your business worth? As they gently pooh-pooh your home grown system built with open source tools.

    It seems 'enterprise' means you're not smart enough to be able to build your own system, so you have to hire outside help to do that. Why reinvent the wheel, right? Well, reinventing the wheel can be cheaper in the long run if it's going to be 1/3 the cost of a consultant. And, at the end of the project, all the knowledge on how the system works will reside within the company, rather than inside someone's well-coiffed head. And anyway, that head is at some other client now and doesn't have time for you.

    No, I am not a fan of 'enterprise' software as built by expensive consultants.

    Alex / talexb / Toronto

    "Groklaw is the open-source mentality applied to legal research" ~ Linus Torvalds

      I'm not sure that it's right to just focus on applications. Indeed, in some cases, it's not clear what the application is.

      I think that it would be reasonable to consider some operating systems to be "enterprise software". AIX, Solaris, VMS, perhaps even Win2k and Win2k3. And some OSes quite clearly aren't "enterprise software", such as Windows 95.

      Nor is it right to exclude sysadmin support software as some people have done. I don't care what your applications are, they won't deliver the goods if the sysadmins can't, for example, get early warnings about machines running out of disk space.

      As for the boundary between application and OS - some people joke that emacs is their operating system, and Unix is just the device drivers. I think they have a point. If you have a machine dedicated to running Oracle, with Oracle managing the storage, Oracle managing all the memory - it seems to me that Oracle is the operating system and the applications are what you build on top of it. Users don't interact with Oracle, they interact with the patient booking system. And the Oracle DBAs rarely interact with whatever is providing Oracle's device drivers.

Re: What is Enterprise Software?
by Tanktalus (Canon) on Oct 30, 2005 at 23:53 UTC

    Given that I'm probably as much of an expert as anyone (translation: I'm picking this out of me arse), the first thing to come to mind with the concept of "Enterprise Software" is software that is needed for business-critical processes. Of course, this definition is probably over-broad. After all, it would include the word processor that the secretary uses (after all, he couldn't get his job done without it - it's critical to his part of the process), the email program that the manager uses (again, she couldn't do her job without it since about all she does is send and receive email... at least at my company that's all managers do...), or even the web-browser that everyone uses - since in order to access the web-based enterprise software, one needs a browser. Now, granted, with commoditised browsers, if one browser stops working, you do, in theory, have a few other options available to you. In actual practice, however, I'm not sure - how many apps depend on IE, and depend on the quirks of IE?

    For example, we recently switched over to Rational ClearCase/ClearQuest for development and tracking. ClearCase itself works on many platforms. ClearQuest doesn't. And I don't work on Windows. So I started using the CQWeb interface - which only supported IE on Windows and MacOS. It has been an uphill battle to get Firefox on Linux supported - although they seem to be going that way. For me to get through my processes, I need CQWeb - to me, that makes it Enterprise Software.

      CQ? I pity you! I've seen that beast and I don't think you can get anything worse. The "designer" was definitely insane, if there ever was one. I'm really glad I'm one of the very few developers in the company that doesn't have to "use" it (often).

      And as far as the "support" goes, let include a quote from my conversation with someone near the top management:

      The people who own it are insane too because I remember Xxx talking about their "support" plan
      they don't support it :-O
      they probably don't have anyone capable of supporting it. I remember Xxx telling me how she would figure out the issues and solve them herself and they would be amazed, kind of like "wow, so that's how you do it".
      Yeah, enterprise, that's what it is.

      XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented.

        Really? That's your experience? Mine is about 180 degrees different. Admittedly, my situation was a pretty unusual one, working for a company that paid the $$$$$ for top-grade support from Rational. But we had Rational engineers (CC and CQ experts, respectively) on site two days a week and always on call. I learned a lot from them (as well as from the on-line resources) about how these products work, and I personally can't praise them enough. Yes, there's some complexity; yes, the products have some quirks and warts; yes, there's a substantial learning curve. In an enterprise environment, you should expect to, and shouldn't be afraid to, climb that curve. The payoff is a suite of powerful, "enterprise grade" tools you can exploit in taming your change management dragons. None of the open source tools I've encountered come close to the depth and breadth of power available in the Rational tools.

        A word spoken in Mind will reach its own level, in the objective world, by its own weight
Re: What is Enterprise Software?
by cyclist38 (Hermit) on Oct 30, 2005 at 22:29 UTC
    I rather have to agree with itub on this, with the possible exception of a database of some sort. It seems to me that 'Enterprise Software' is something that is used by everyone (like water) and cannot be done without. Oracle (or mysql enzovoort) fits this category, but perl does not. Nor, for that matter, do most software packages such as Word,, accounting packages, satellite tracking or nuclear weapon targeting packages. Perhaps, though, an email 'system' might qualify as Enterprise?

      If your defintion is something everyone needs, how does Oracle make it onto the list but not perl? A database server by itself isn't that interesting without something to pull data from it, display the results to the user, and allow the user to change the database. The thing which transports the data to the user is just as necessary as that which stores it.

      If your answer is that another language could do it so no language is enterprise software, then I say that a database server doesn't qualify either because another database server could do it.

      I'm not convinced one way or the other, but the defintions that people use don't match up with what they actually think, which is why I started this whole thing :)

      brian d foy <>
      Subscribe to The Perl Review
        There's a huge difference between perl and Oracle. A database server on its own might not be so interesting, but it's still an "entity": it's a process that runs, it manages disks and data. I would classify Oracle as "Enterprise Software". I don't think there's a clear definition of it, and if there is, I don't think many people know what it is. Most people seem to use the term "enterprise software" of software that
        • Is scalable. It can handle large amounts of data/transactions/users/traffic before showing more than a linear decrease in performance. It is also be able to use multiple CPUs "out of the box", if there are more CPUs available on the box. When it makes sense for the application, it should be able to run in "distributed mode", run on several boxes, but act as a single one service when seen from the outside world (for instance, a distributed database server, or a cluster of webservers with a level-4 or level-5 switch).
        • Is reliable. Databases should lose (or corrupt) data. If the application doesn't cluster itself, it should be cluster-aware.
        • Plugins. Enterprise software should come with plugins (or have them available) for at least the most important monitoring (for instance HP Openview), backup (for instance Veritas Netbackup) and cluster software (for instance SUN Cluster). Companies usually already have monitoring, backup and cluster licenses and expertise in house, and now software should fit it, and don't require a different solution. Or to be more general: enterprise software should fit in the existing infrastructure.
        • Support. You should be able to get (buy) a support contract from the vendor. On different levels. If you don't give your customers the options to buy a 365x24x7 support contract, you probably aren't producing "enterprise software".
        I classify "Oracle" as "enterprise software". I classify "Solaris" as "enterprise sofware" as well. I certainly don't classify perl as "enterprise software". I consider "Apache" and "Red-Hat Linux" as borderline.

        However, I don't think whether a piece of software is labelled "enterprise software" or not is important. There are some good pieces of "enterprise software" (is a piece of software could ever be 'good'), and there's horrible "enterprise software". And there's good software that isn't "enterprise software", and there's horrible software that isn't "enterprise software".

        Perl --((8:>*

        I need to bring up a different aspect for you. A definition that is not measurable usually never aligns people's judgement. Enterprise software certainly falls in this area. To say that there is a definition, I would rather say that there is a description (that is vague).

        Not perl, but the apps written by perl, much as not C or Java, but the apps written in C or Java. Oracle is perhaps not the best example, but I do tend to think of Oracle applications as applications and not just data (odd that I don't think so of other database servers).

        It's certainly not an easy question to answer (especially at 2am :-) ).

Re: What is Enterprise Software?
by dws (Chancellor) on Oct 31, 2005 at 01:50 UTC
Re: What is Enterprise Software?
by dave_the_m (Monsignor) on Oct 31, 2005 at 00:25 UTC
    Enterprise software is anything that is is overcomplex and overpriced. Funnily enough, I believe Oracle is usually regarded as enterprise software...


    PS: Sorry, I know I'm I not being particularly helpful.

      I found a lot of these glib answers on Google already.I think you mistake cause and correlation. Enterprise software may be complex and pricey, but I don't think that's what makes it enterprise software.

      What if the software were complex, but free? Does that preclude it from being enterprising useful?

      brian d foy <>
      Subscribe to The Perl Review
Re: What is Enterprise Software?
by perrin (Chancellor) on Oct 31, 2005 at 16:39 UTC
    There's an amusing paradox between the connotation and literal meaning of enterprise software. The term literally refers to software that is written for internal use by a company, as opposed to software that is written as a commercial product (or website). However, the connotation these days is that it has an extra level of quality. In practice, most of the software that companies write for internal use is the worst kind of quick and dirty junk. It's the land of Visual Basic and PowerBuilder. A far cry from the image that J2EE is trying to foster.
      Indeed. I've (relatively) recently joined an "enterprise" (large bank), and the code they've written to handle a lot of batch jobs of various types is pretty hairy (think thousands of lines of ksh). They use things like CA-Unicenter to manage all these jobs (scheduling) on a collection of machines with 50 or so production database instances, but the whole setup is what we call in French "une using gaz" - i.e. you have pipes going every which way, with various pieces interconnected in various ways, and where only a few people really understand what the dependencies are between the various bits...

      Me, I just manage their Sybase databases... :-)


        I've been amazed at the stuff I've seen inside financial companies. They are the example everyone loves to use of where one would have to write serious code with real accountability, pretty much the definition of the "enterprise" market that J2EE is aimed at, and yet they tend to be such a mess when you get inside...

        Likewise. A few years ago I spent a week working with some consultants from a "household brand name" computer systems supplier, helping them write what they call Adapters and Connectors for part of their middleare product range.

        The Connectors are the bits of glue that interface to the external systems and hardware. The Adapters perform the translation between the format of the information gathered from or supplied to those external entities, and the internal middleware comms protocol.

        You have never seen such a lash up in your life. Most of the connectors and adapters are written during the post-sales installation and deployment phase, by post-sales engineers (who are usually more saleperson/liason than programmers). They get hacked together at the customers site and tested on-the-fly. I was supposed to modify two pieces of code that "were written by the guys in XXX office for a similar job", and adapt them to the task at hand. You cannot beleive what hookey, inefficient, polling loop nightmares they were. Really quite unbelievably bad.

        Luckily, I got moved on by cirumstances before I had to make a decision about whether to speak up or shut up.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
Re: What is Enterprise Software?
by xdg (Monsignor) on Oct 31, 2005 at 14:09 UTC
    Software that solves an Enterprise Problem (rather than a departmental one) and that is written with an Enterprise Software Architecture

    I actually find that the p5ee and Gartner definitions comes pretty close to defining what begins to differentiate "enterprise software" from other software. However. the subsequent p5ee laundry list speaks more to desireable characteristics of enterprise software rather than a definition.

    Why do I feel this is so? My "theory" begins with the postulate that branding a product with a subjective qualifier or tag such as "enterprise software" is fundamentally a marketing endeavor, rather than an engineering endeavor. This kind of branding serves two purposes:

    • associating a product with a problem domain that it addresses
    • differentiating or positioning a product with respect to competitors

    This rules out some of the definitions in other posts in this thread:

    • cost versus other solutions -- this may be true, but it is correlated, not causal with the definition; it is an indicator either of the problem domain or of the success of the marketing designation in enhancing the price point of the product (or both)
    • risk to executives/providers for failure -- likewise, this is predominantly an effect of the high cost; any waste of resources on a large scale leads companies to seek to assign blame or seek recovery

    Interestingly, by focusing on the term for its marketing impact, I also rule out the real capabilities of any particular product in actually addressing a target domain or differentiating from another product in the quest for a definition of "enterprise software". What matters is the goal a company has in applying the designation, not in the ability of the company to have its product live up to the designation. It also means we can ignore software that may have similar characteristics but may not have been branded as such.

    Therefore, one must address the two terms directly for what they evoke in the listener. We should also consider the intended audience, as that's the perspective we have to take in understanding the intended marketing effect. Others may have different opinions, but I would posit in the most general way that the term is intended for those reviewing, selecting, or funding the purchase of the product.

    First, consider the goal of associating a product with a problem domain. "Software" is the easy word to address. Used generically for marketing, it just means program code running on hardware and, from a business perspective, implies which budget category it hits and how its purchase may be amortized under GAAP (or equivalent) accounting rules.

    "Enterprise" seems like it could be a difficult word. Many of the other definitions in this thread focus on scale or criticality of the resource. However, in a business context, "enterprise" has an organizational interpretation as the root of the organizational tree, above all divisions, departments, and business units. This suggests a couple reasonable intents for the marketing meaning of the term, particularly as would be interpreted by potential reviewers, purchasers, etc. at that level of an organization:

    • applying to the total organization (or a least more than one of the first-level organizational units)
    • applying to the needs of the "corporate center" at the top level of the organization

    Software in those problem domains would then seem likely to have some characteristics (though not necessarily all) along these lines:

    • a centrally-administered resource
    • purchase decisions made from the corporate center
    • benefits multiple parts of the organization
    • helps senior executives manage across the organization
    • creates change in multiple parts of the organization, with commensurate implementation complexity and need for senior executive sponsorship and change management
    • not directly revenue-producing (though it may be an enabler revenue gains within divisions)

    Given this emerging definition of the domain, we can turn to differentiating or positioning a product with respect to competitors. Given the problem domain, the implication is that the product is addressing complex needs across an organization and has a high degree of senior executive awareness. This is where notions of "criticality" properly re-emerge. Positive characteristics of "critical" software then begin to resemble the p5ee list -- though I would argue that failure avoidance characteristics would wind up taking precedence over growth-supporting capabilities, as executives (and company stock) is punished more for unexpected failures than for slower growth or speed to market.

    Summing up across these observations and thoughts, I'll offer my own definition, though with the caveat that this is what designating a product as "enterprise software" is intended to convey, not that any particular piece of enterprise software necessarily fully meets this definition.

    Enterprise software is a centrally-administered resource that addresses common information processing needs of multiple departments or bridges information processing across departments. Enterprise software has the maturity, quality, robustness and support to be relied upon for mission-critical business needs.

    Defined as such, Perl is not enterprise software, though particular applications written in Perl could be. Whether Perl can be taken seriously as a enterprise software development language will depend on whether software written in Perl for cross-department solutions can be shown to have the proper level of support for mission-critical needs. I think that has little to do with the language, and everything to do with the business model of Perl development. We need more success stories of Perl development companies serving the enterprise or more publicity on how Perl helps in-house enterprise developers better deliver mission-critical software.


    Code written by xdg and posted on PerlMonks is public domain. It is provided as is with no warranties, express or implied, of any kind. Posted code may not have been tested. Use of posted code is at your own risk.

Re: What is Enterprise Software?
by samizdat (Vicar) on Oct 31, 2005 at 15:12 UTC
    Whoa, boy. Thassa BIG enchilada.

    I think talexb is the closest of the posters so far. The application that enables and models and enhances the business functionality is the focus of enterprise software. There are tools such as Perl, Java Beans, Apache, Solaris, and Oracle which enable enterprise-level systems to be built, but the tools are the means to the end. There are tools at the nuts-and-bolts level (BSD and Perl, f.e.), there are tools at the middleware level (Apache and Oracle, f.e.), and there are tools at the architectural level (UML, flow charts, f.e.).

    The key to building an enterprise-level application system is in the top-down holistic approach to its development. This can be done successfully or unsuccessfully by either payware vendors or homebrewers, and it includes careful attention to the human aspects of the processes being automated. This holistic approach also includes provision for other systems to have access. This is why applications which use a scalable SQL database like Oracle (or MySQL in its recent incarnations) on a *NIX platform are more often successful enterprise solutions and why closed-API systems like Brooks' FACTORYworks cause growing companies so much heartburn.

    The key to a successful enterprise application is the careful attention to all aspects of design, not the particular tools used. My successes in architecting useful business-enablers have come from applying the following heuristics:
    • Never buy a first-year car! or CPU, or language, or toolset dot-zero release...
    • Use well-traveled API's like SQL, HTML, and BSD
    • Recognize the holes you can't fill and shape the human interface so that people can plug them
    • Focus on the robustness and flexibility of the core and make everything else out of small pieces that attach to it incrementally
    • Think about loose coupling which will save your @ss over and over!
    • Make your tools not matter in case you need to switch.

    Management often has the Holy Grail in mind when they ask for an enterprise-level enabler, and this often results in an uneducated preference for name brand or bleeding edge tools that will save their bacon. In the Sixties and Seventies, this meant buying an IBM mainframe. In the Eighties and Nineties, this meant SAP or a customized Oracle solution, or worse, some idiotic PC-centric monstrosity like FACTORYworks. These days, it usually means some sort of Java medication.

    What I've found is that today's managers have been toasted, fried, baked and burnt so many times by software automation vendors, especially "consulting firms," that they are ready to listen when you explain that solid solutions are built from well-grounded toolsets and proper architecting. They are already "there" in the sense that they understand that effective systems that are deployable in the short run are much better for their bottom line than any amount of hypervaporware that might someday hit the streets. I have successfully architected systems using open source Java and its underlying middleware like Jakarta/Tomcat and Hibernate, but I have had even more success with Perl/Apache systems that are prototyped on MySQL and deployed on Oracle.

    In most cases, a modern enterprise app is transaction- and state-based, and the processes usually go to sleep waiting for human or other execution threads to complete the handshake, so there are very few places where computational speed is a factor. It's much more important to have robust middleware and underlying platform software that can deal effectively with transaction volume and varied client systems. Since databases coupled with web interfaces form the basis of most such systems, code can be reused very effectively.

    Perl lets me deploy pieces of such systems one by one, using CPAN to augment its raw capabilities. More important, I can add more programmers as needed and the learning curve is minimal. Very rarely is a properly architected application dependent on quirks and special features of a particular database or operating system or toolset. If the architect does his job well, the tools are chosen for their ease of use rather than their raw performance or feature set.

    The key to success of an enterprise solution is to plan a deployment that gives your users productivity wins all along the way. Do that, and your managers will become your evangelists, leaving you alone to concentrate on hitting more home runs.
Re: What is Enterprise Software?
by tirwhan (Abbot) on Oct 31, 2005 at 07:57 UTC
    Enterprise software is software that is perceived as being useful only to (and is used exclusively by) mid- to large-scale enterprises.
    And if you're feeling mischievous
    A common characteristic of enterprise software is the (mostly mistaken) perception that its adoption per se will elevate the enterprise into a higher sphere of professionalism.
    People will waste an awful amount of money if they think they can earn more by doing so.
Re: What is Enterprise Software?
by ady (Deacon) on Oct 31, 2005 at 07:09 UTC
    Enterprise Software (ES):

    It seems to me that you need to delimit and define the scope of the ES for your specific analysis. Often this is done by exclusion, like:

    * IT solution developed to support processes of a large business domain, like an area of human/social administration (employee, customer / taxation, security, environment) or product manufacturing and control (purchase, stocks).

    * typically you want to excludes general office and infrastructure products (text processing, DB etc) and exclude tools to develop IT solutions (languages, libraries, IDEs etc).

    * often you also want to exclude "shrink wrapped" ES solutions (like commercial CRM, ERP)

    * when focusing on custom developed ES systems and the specific problems of these related to large scale project administration and SW design, construction, deployment, operation & maintenance
    Best regards
    Allan Dystrup
Re: What is Enterprise Software?
by zentara (Archbishop) on Oct 31, 2005 at 12:20 UTC
    I have usually understood Enterprise software to mean "software which costs extra, because it is supported by the vendor in a contract". It usually implies "for large organizations" since they can make more money there, but it's still enterprise software even if a single individual buys it.

    I think everyone has Enterprise confused with the aircraft carrier. :-)

    Enterprise simply means a business, and software for business requires contracts, support, guarantees, and monetary remedies if the software fails due to failures by the vendor.

    I'm not really a human, but I play one on earth. flash japh
      I think everyone has Enterprise confused with the aircraft carrier. :-)
      Actually, I was thinking it meant the very first space shuttle: big, expensive, complicated, and never got into orbit >;^)
Re: What is Enterprise Software?
by Anonymous Monk on Oct 30, 2005 at 23:33 UTC

    Please don't bring up P5EE. For two reasons: 1) The project was a failure and never produced anything usable in the EE sense; 2) The fact it mimics J2EE's name only proves that the P5EE people recognized Java's enterprise status, and they want to catch up, although they actually never caught up.

      Who cares if p5ee was a failure that never produced anything or never caught up with Java? They still tried to define enterprise software, and I fouund a much more trenchant definition than I found anywhere else.

      I don't really have an inferiority complex with Java, so I don't try to deny its existence eitgher.

      Perhaps you disagree with the p5ee definition. You can tell us how you think they're wrong (and that would be much more useful).

      brian d foy <>
      Subscribe to The Perl Review
        One thing I would add here is that those pages are not the work of "the p5ee project" but rather of one person, Stephen Adkins. He wrote that definition, and if you like it, he is the one who deserves the credit.
Re: What is Enterprise Software?
by swampyankee (Parson) on Oct 31, 2005 at 16:44 UTC

    I'm going to go out on a limb here, and probably start sawing it off.

    "Enterprise Software" is market-speak for the type of software that people used to run on mainframes: databases (anybody remember RAMIS II?), email, payroll, inventory control, etc. Largely, the applications that were accessed via COBOL, by people sitting at 3270 terminals.


    Mainframes and terminals: the logical endpoint of the client-server continuum

Re: What is Enterprise Software?
by thundergnat (Deacon) on Oct 31, 2005 at 14:07 UTC

    Nothing really useful to add to the conversation. It was just this line that struck me as funny.

    Most people ... don't really use Perl, although they use things that use Perl. Most people directly use the water, electricity, and other things I included in my list.

    Ok, water I'll concede, but electricity? In many years of corporate work I have NEVER seen anyone stick their fingers into the mains to get their shot of electricity for the day. (Not on purpose, at least.) The Perl/electricity analogy may be better than you initially thought. You don't absolutely need it to get useful work done, but it sure makes things easier.

      In your many years of corporate work you've never plugged in a computer, used a coffee pot, or turned on the lights? If electricity isn't powering those things, what are you using instead?

      brian d foy <>
      Subscribe to The Perl Review

        Sure I have. But I've never taken a raw electric arc and used it to heat water or provide light. Not that I couldn't, mind you, I just find it easier to use the elecricity indirectly and let the coffemaker and lighting fixtures do it.

        I was only commenting that that statement raised an amusing image when I read it.

        That being said, I personally view Perl as being infrastructure. Few people other than programmers ever deal with it directly. Most users have a very hazy view of how it works or if it is being used in a particular application and only really notice it when it breaks.

Re: What is Enterprise Software?
by radiantmatrix (Parson) on Nov 01, 2005 at 17:29 UTC

    There are two things at play, here, and I think that confuses the issue. There is the term "enterprise software" that refers to just that (which I'll proffer a definition of in a moment); but there's also the marketing term "enterprise software" that gets tagged onto things to increase the price tag.

    During my scant years as a contractor, I arrived at a definition of "enterprise software" that I found useful for comparing packages and helping suits to understand what was really being sold/built/implemented. That definition is, simply, this:

    enterprise software
    Software that is specifically designed to solve a class of problems shared among significant portions of an enterprise.

    By way of example, Lotus Notes qualifies as enterprise software because it was designed to solve a set of problems (e-mail, scheduling, etc.) shared by just about everyone in an organization. Maybe not Joe and Annie on the production line, but all of the help desk, management team, and office staff (thus significant portions as opposed to all).

    Also, note the specifically designed phrase: software that just ends up solving a particular enterprise's range of enterprise problems isn't enterprise software -- it's software shoe-horned into an enterprise role.

    Is perl enterprise software? That, I suppose, depends. Just about any cross-platform application framework (Java, .Net {sort of}, Perl, Python) could arguably be enterprise: they are designed, in part, to solve the shared enterprise problem of running software tools on whatever platform that's available. I think that's a bit of a stretch, personally.

    I think it's more accurate to say that Java, Perl, etc. are frameworks that are well-suited to building enterprise software.

    A collection of thoughts and links from the minds of geeks
    The Code that can be seen is not the true Code
    "In any sufficiently large group of people, most are idiots" - Kaa's Law
Re: What is Enterprise Software?
by exussum0 (Vicar) on Oct 31, 2005 at 19:43 UTC
    Enterprise software is the sum of its qualities and parts, just as a good man is. Sure, a good man may have killed a person once in his lifetime, but is he still good in the long run? Is it enough to count against him, for all the right things he's done?

    php and perl have a harder time since there's no one company (read authority w/ money, consultants and professionals) saying, "yes, it's good. we provide something and prove it." To some degree, they deliver, to some they don't. Sun does that for java, even if it spins the truth a little, like cross platform compatability. where's my jvm for my c64! ;)

    Same w/ ES. Sure perl is enterprise level, but not for the same reason oracle is, different component types. Certainly for not the same reason java is, but they seem to converge a little, w/ the advent of ORMs, XML processing, fast web prototyping and what not. But they don't converge due to the tools involved and their qualities, that can be argued all day long. 'cause it's like pizza toppings. Do we ever agree on that? (Ham and Pinapple ftw!)

Re: What is Enterprise Software?
by rcseege (Pilgrim) on Nov 01, 2005 at 03:20 UTC
    Software whose failure everyone notices quickly

    I think your brief statement cuts to the heart of the definition but leaves out at least one important aspect, which is any notion of the environment in which it is expected to operate.

    Although I like and use Perl, the vast majority of my paid work is in Java. One of the descriptions that I've found useful to me as I've read my way through ridiculous numbers of books was in Ted Neward's "Effective Enterprise Java" published by Addison Wesley where he describes qualities of an Enterprise System. Unfortunately, it doesn't do much to narrow the definition.

    Well, I don't know if this adds more clarity or more mud. Certainly, it is more of the same ideas. It was the first thing to come to mind when I read your post. I believe that the first chapter of his book is available online as a sample at

    The main problem I have with "enterprise software" is one of context. I find that the thing that is being built ends up being lumped in with the things that are being used to build it, and I see a fairly distinct difference between twhetwo. At my customer site, I find that "Enterprise system" and "Enterprise solution" tend to refer to the things that are being built using tools that some vendors market as being "enterprise software" or "enterprise versions" of their software.

    Is Perl Enterprise software? Well, at the very least I'd say it is a tool (or a collection of tools) that can be used to create Enterprise systems.

Re: What is Enterprise Software?
by spiritway (Vicar) on Nov 01, 2005 at 04:43 UTC

    If I had to limit it to one word, I'd say, "expensive". I agree with several others, it's a buzzword. It has been so overused by marketing droids that it means almost anything - and thus, almost nothing. I put it in the same category as "world class".

Re: What is Enterprise Software?
by Anonymous Monk on Nov 03, 2005 at 19:29 UTC
    Answer: it's a business buzzword, meaning, roughly, "important". Like most buzzwords, it's mostly useful for aging men in bad suits to chuff their chests, babble, and make vain attempts to impress. This rarely works.

    Example of use: "We'll need to concentrate our resources across the board, by utilizing synergy to manage our enterprise software to interface with our B2B and B2C relationship requirements! Can you handle it?!? I'll need it no later than Friday at the latest!!! Wait, make it this Tuesday, I'm golfing on Friday!"

Re: What is Enterprise Software?
by Moron (Curate) on Nov 01, 2005 at 13:45 UTC
    The term 'Enterprise software' has been abused (for long enough to confuse people) to sell things with the implied argument that 'you can't achieve your enterprise (i.e. b2b-level) software goals without this' usually with no justification for this even being offered.

    The term is clearer when properly confined to its specific goals: It was coined in the late '80s at a time when someone had the idea that systems integration (hitherto occurring between departments of the same company) could be extended to include b2b-level systems integration. And that's all it is:

    "enterprise software" is any software that provides or assists systems integration between several companies.

    On that basis, Perl is enterprise software ;)


    Free your mind

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: perlmeditation [id://504043]
Approved by itub
Front-paged by rob_au
and the web crawler heard nothing...

How do I use this?Last hourOther CB clients
Other Users?
Others about the Monastery: (4)
As of 2024-04-20 13:31 GMT
Find Nodes?
    Voting Booth?

    No recent polls found