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.
| [reply] |
|
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.
| [reply] |
|
| [reply] |
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.
| [reply] |
|
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).
| [reply] |
|
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.
| [reply] |
|
|
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.
| [reply] |
|
| [reply] |
|
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:
- Does it work?
- Can someone else come in, make a change, and be reasonably certain no bugs were introduced?
| [reply] |
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... | [reply] |
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.
| [reply] |
|
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.
| [reply] |
|
"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.
| [reply] |
|
|
| [reply] |
|
| [reply] |
|
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.
| [reply] |
Re: What is Enterprise Software?
by sauoq (Abbot) on Oct 31, 2005 at 00:31 UTC
|
| [reply] |
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
| [reply] |
|
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.
| [reply] |
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.
| [reply] |
|
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.
Jenda
XML sucks. Badly. SOAP on the other hand is the most powerfull vacuum pump ever invented. |
| [reply] |
|
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 wei ght
| [reply] |
|
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, Openoffice.org, accounting packages, satellite tracking or nuclear weapon targeting packages. Perhaps, though, an email 'system' might qualify as Enterprise?
| [reply] |
|
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 :)
| [reply] |
|
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".
| [reply] |
|
| [reply] |
|
| [reply] |
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...
Dave.
PS: Sorry, I know I'm I not being particularly helpful. | [reply] |
|
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?
| [reply] |
Re: What is Enterprise Software?
by dws (Chancellor) on Oct 31, 2005 at 01:50 UTC
|
| [reply] |
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. | [reply] |
|
| [reply] |
|
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...
| [reply] |
|
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.
| [reply] |
|
|
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.
-xdg
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.
| [reply] |
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. | [reply] |
Re: What is Enterprise Software?
by tirwhan (Abbot) on Oct 31, 2005 at 07:57 UTC
|
| [reply] |
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
| [reply] |
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.
| [reply] |
|
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).
| [reply] |
|
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.
| [reply] |
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
| [reply] |
|
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 >;^)
| [reply] |
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.
emc
Mainframes and terminals: the logical endpoint of the client-server continuum
| [reply] |
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.
| [reply] |
|
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?
| [reply] |
|
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.
| [reply] |
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!) | [reply] |
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.
| [reply] |
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 informit.com.
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.
Rob
| [reply] |
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".
| [reply] |
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 ;)
| [reply] |
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!"
| [reply] |