Enterprise Tools
Enterprise, Opensource or Commercial tools, which is better and why? Of course the answer is, "it depends".
~ Aristotle Sabouni
Created: 2002-03-11 |
A place for everything and everything in its place
One way to categorize development tools is by their market or audience. I like to break them into the follow groups (With each category having its own specialties, or things it does better):
- Enterprise
- Commercial
- OpenSource
For each category, I have the following areas of interest (Creator, Users and market):
- By: Who creates these solutions.
- For: Who these solutions target.
- Users: How many users use these tools (how big is the market you can draw on?)
Tools and frameworks
- Tools: How many tools, how good, etc.
- Frameworks/Libraries: How big the libraries, what do they do.
Support:
- Examples: Can you get solutions for your task? How much?
- Documentation: How well documented are the solutions.
- Training: Can you get your people trained on the tool? How much do they need it?
Results:
- Scale: How big can the solution go?
- Lifespan: How long do these tools last.
Each of these items can help define how well the solution will work for you.
Enterprise[edit | edit source]
By/For/Market: Enterprises are big business, like fortune 500 companies. These tools are often done by big business, for big business. Enterprises are not agile or reactive - they have huge momentum, and they select a tool with momentum and put the training into it, they want to use that one tool for lots of stuff (leverage those up-front costs for as long as possible). Thus enterprise tools are usually the biggest, and broadest category of tools out there; making them the most complex. In number of users, there's usually not as many in sheer numbers as Commercial or even many OpenSource solutions; most businesses and teams are small, and not big, and most developers can't handle the huge amount of complexity or time it takes to learn these behemoths. However, remember that these users often have the deepest pockets, and the most money. So in market size they may not be big, but in market capitalization, they are usually the monsters. Remember the golden rule, "he who has the gold, makes the rules".
Tools/Frameworks: Enterprise tools often try to do everything (or lots of things). They have many tools, and the tools are complex to enable all these broad uses; the frameworks and libraries are the same, big and broad, usually going from very high-level to very low-level, trying to do it all. This means that Enterprise tools take the most time and money to learn. That much "built-in" could make users more productive, in theory, but it is debatable if it makes it to the real world. Often, these tools/frameworks try do so much, that they don't do anything well and are overly complex and confusing (slowing down productivity), or have so many layers to do things in very generic and adaptable ways, that programmers spend all their time writing code in ways that can be adapted to do anything, instead of just solving the far simpler problem at hand. Long term maintenance costs can go down - but at the cost of higher initial development. On huge projects, with huge teams, this can pay off - on smaller ones, you're moving all your costs to up-front costs, and this can spend you of business before you even have a market.
Examples/Documentation/Training: There is usually excellent support, tons of documentation, great training opportunities, and often lots of examples. But they need all of them. There is a question as to whether they keep up with their own size.
These solutions are so big, that there needs to be tons of documentation; so Enterprise solutions are often spotty - some areas are very well documented, and some areas are too new and thus poorly documented, and you need to read far more just to stay even with simpler tools.
In other areas of support, you can buy support from many organizations, and often have to; including training which is often expensive and needed. Remember, tools are big and broad, so you have to pay for training, or pay for someone who has gone through all the training: think money. And anyone who has gone through the training has more value (expertise) if they leave and go somewhere else, so you have to keep paying to train them, and then paying them more because you trained them. And since these tools are growing quickly, you have to pay to retrain them for each new version; or else you pay them in lost productivity because things change and they have to learn it on their own. Either way, it is expensive.
Support contracts are common, practically required, and very expensive - all to get you the latest releases which are required for the newest hardware and to fix older bugs, but that also create new bugs and issues you need to learn the work arounds to. (There are usually lots of bugs in the tools and frameworks because the solutions are so big that you can't get them all out, and growing constantly).
In examples, it gets fuzzier. There's usually a lot of examples, but the tools try to do so much, that there may or may not be examples for what you need to do. Often you can pay for examples, starting points, pre-built solutions - all extra costs to get you going. Or you can just pay consultant to create the starting points for your organization: at a very high price. If you can pay the cost of entry for the tool, then you're going to pay those costs everywhere. And the tools are so complex to learn, that experts need to charge you for their expense in learning them. And they will keep charging, as each version can change things, are require more training/porting costs, and so on.
Scale/Longevity: The tools do the most, and have the most money in them, are stable and can be leveraged for long periods of time, and usually have ways to bring your solutions to very large levels.
| Car enthusiasts and racers have a saying, "speed costs, how fast do you want to go". The idea being that if you've got the money, they've got ways to make you go faster. The enterprise version of that would be, "scale costs, how big do you want to go?" If you've got the money, they've got ways to get you to support as many users, as many platforms, or as many features as you need. But it is going to cost you, every step of the way. |
On huge teams and huge projects (that are going to last many years or decades), this may make sense. If you use one tool across many dozens of solutions, it can also pay-off (because you pay the training and support costs only once). But on smaller solutions, smaller teams, or quick turn-around times, enterprise tools can eat you alive, not to mention eat your budgets alive. And you have to constantly pay to stay on this bleeding edge, every version is going to cost you, and you have to keep training and supporting to keep up; so the entry costs (often in the $20K+ range) are just the beginning.
OpenSource[edit | edit source]
By/For/Market: OpenSource tools are the other end of the spectrum. OpenSource tools are often done by individuals or groups that are focusing on tools for the sheer love of the solution. They don't usually have the support of an organization; but many people and organizations are using the tools, and will contribute to them. The market is anyone who also wants to use this tool.
If Enterprise are the "money-bags" of the tool spectrum, OpenSource are the cheapskates. The tools cost nothing (or very little), and so people jump on board because the entry costs are so low. But then that also means that their market (in users) are usually huge. Anyone can use these tools, and they cost the least (in resources, learning curve, etc.) - so for small teams and small solutions, they are incredibly cost effective and "the" way to go.
Tools/Frameworks: These tools were usually made by someone, who wanted to do one thing better than anyone else. So these tools usually start very focused (simple) at doing one thing well; and then grow from there. Usually the programmers that create them, are not into making big, feature rich tools, or big feature rich frameworks: it is about getting a small job done very quickly.
The interesting thing about OpenSource is that it is "open", you can add or modify the tool, and contribute those features back to the "community". So there is sort of an anarchy rules approach; if you want to add something to the tool, you can. You just write it, and put it out there, and it probably will be incorporated. You'd think that such tools would grow quickly and quickly entropy into complete chaos, but this seldom happens. Generally, there is a group overseeing things, and the tool tends to attract like-minded or like-goaled people in the first place, so usually there is far more order than you'd expect. Sometimes what happens is that two camps of developers/users have totally different philosophies or ideas about how things should progress, and they fork (split) the solution; and suddenly you have two OpenSource tools with the same origin. But usually the group adapt to the philosophy of the tool originator, and drive everyone else out, and so the solutions stay fairly focused.
Because the tools are so focused, and the barriers to entry are so low (cost, training, tools, etc.), for small solutions or organizations that won't put a lot of investment into tools/learning curve, and those looking for short term gains, will see the most out of OpenSource tools. The tradeoff is that on larger projects, or longer term goals, the lost productivity over more complex/advanced tools can cost you in the long run. But if used wisely, you can use OpenSource projects to make a market for your solution, then when you can afford the time and money, and your OpenSource solution is paying for it, you can start moving up to commercial or enterprise solutions.
The downside to OpenSource is that things often move slowly. It is done often on free time; or as people can contribute. So you have a constant evolution, but it is hard to have a real quick drive. These projects usually plod along, evolving in some ways very quickly, and in others, very slowly. The trick is if they are evolving in the ways that you need, or if they do what you need them to do.
Examples/Documentation/Training: There are some support organizations that pop-up for these tools, even without a big organization behind them. OpenSource projects usually excel in the sheer volume of sample code our there for it. Because they are usually free, there are tons of users, and those users create code/examples out the wazzoo. The same, they often create prebuilt solutions with the tools as well, and since those solutions are built "by the cheapskates, for the cheapskates", they are often very low priced or even free as well. People are using the tools sometimes for fame more than fortune. Consultants in this category is also the cheapest, and you can find tons of people that use the tools - so there's a huge safety in numbers (and replacement).
Now for the downsides. While the quantity of code and starting points and people are numerous, the quality of all of them can be "lower". These tools are easy, so they often attract the newbies to programming, or the hobbiests. They pump out code and examples, but it isn't always good stuff. Now there are still very good people and good code out there that are picking these solutions because they are so cost effective, but there are so many of the "lesser" coders in these seas, that they often give the whole tool or solution a bad name. In some ways this is unfair, a good coder can create good code using many tools. But in other ways there is a reality, if you aren't careful you're not going to get good coders, and you need good mentors to manage the rest, and so many solutions done with these tools will be of a lesser quality, not always because of the tool but because of the market you are drawing on, but it still ends up being less.
Documentation in books is usually pretty good in that there is often momentum (and lots of users). But built in documentation and support for each release can be somewhat less. Often there's a coders mentality, and coders think that "the code is obvious" - so that kind of support can be a little weak. And the training and outside support is often worse still. There are often a few organizations that will train in the most popular OpenSource solutions, but most of them are thinner or non-existant. So users spend time on "free support" like email lists, which can be quite good; but the paid support and documentation may be less.
Scale/Longevity: A surprise with OpenSource is that you'd think without an organization or commercial support, that they wouldn't have a long life span, or many users. But the tools are free to use, and free to make into what you want; so there is always a group that will go for the cheapest solution (good or not). This means that you just can't kill an OpenSource projects, once it is established, because there always seems to be at least a few people left, keeping the solution alive, or moving it forward to new platforms. In practice, it seems that OpenSource tools have a longer life-span, and longer support than either Enterprise or Commercial solutions. I can name hundreds of word-processors that have disappeared in the last decade, but there's still OpenSource text editors from the 60s and 70s that people fanatically follow and cling to.
In scale, these tools are designed for smaller teams and smaller solutions, but there's a hoard of users behind them, always pushing these solutions forward (to do more than they were intended on doing). The surprising results are that they often scale fairly well - far better than the arrogant Enterprise coders pretend, and they grow up to their ceilings at a fraction the cost. Ultimately, you can reach these tools limits, but then they'll have served their purpose and paid for themselves up to that point. And then many organizations will be able to afford the migration costs to more complex tools than they could have initially.
Commercial[edit | edit source]
Basically commercial tools become "everything else". So there's a wide spread of possibilities. But there are some generalities that we can assume. Enterprise does more, OpenSource does less - so Commercial has to do it better, or at least convince a market that they do it better enough to pay for it, in order to stay in business.
By/For/Market: Commercial tools are usually between enterprise tools and the OpenSource tools. They might be done by large companies, or smaller companies; they generally have to be good at doing something better than enterprise (or OpenSource) tools, or they'll be eaten alive. They cost more than OpenSource (which is usually free), but they cost less (often far less) than Enterprise solutions.
Since people are willing to pay money for the tools (or support) they expect and demand that they get something out of it. But usually they do, and there is a market that develops. That market is right between OpenSource and Enterprise as well. There's usually more users than Enterprise, but they usually have less money. There's usually "pay-for" solutions, but they can't charge too much or people will move to OpenSource or Enterprise solutions (depending on their needs). And the teams tend to fit in the middle; on small solutions, people often go for OpenSource, or large ones they go for Enterprise - and that leaves commercial in the middle. A few people to justify the costs and learning the tool, but not such big solutions/teams that you need enterprise solutions.
Tools/Frameworks: Commercial tools vary in complexity from very simple, to nearly as complex as enterprise; but while enterprises moto could be "scale and versatility at any cost", commercial tools are a tad more moderate, more focused and have to factor in those costs. Instead of being "swiss army knives", trying to everything in one tool, they often go for solving a few problems better. But where OpenSource sometimes focusing on doing just a few things well - commercial has to be broad enough to warrant their development costs and price.
Because they aren't as big, and there is a market incentive to eliminate bugs (and less opportunity to create "work-arounds" in training, and less tolerance for bugs), in general commercial tools are more bug free than most enterprise tools. OpenSource has more people looking at the code, so more opportunity to find/fix bugs, but the cycles take longer and there's not as much economic push as with commercial tools. Commercial tools and OpenSource tools are about even - some are better or worse in bugs than each, it really matters on which tool.
Examples/Documentation/Training: Commercial tools don't do as much (as Enterprise), but what they do, they often do better, easier, for less cost and less training. Because they don't do as much, there can be better examples for what you need (even if there are fewer examples). And you can often buy prebuilt partially complete or complete solutions for these tools - and because their market is bigger, and the cost of people smaller, these solutions are often far more affordable than Enterprise (but not as cheap as OpenSource). The same with consultants - they are more affordable than enterprise, but not as cheap as OpenSource.
Commercial Documentation is usually some of the best. They're getting paid to have it as part of the solution, and the markets are big enough to warrant lots of extra books as well - but there isn't as much to the solutions (both libraries and tools) as Enterprise, so you need less.
The training is more spotty; it depends on the solution. Some are great, some are nearly non-existent. And after market support is about the same, sometimes you can get support contracts (upgrades, bug fixes, etc.), sometimes not - it really matters on the solution.
Scale/Longevity: The downside of commercial tools is that they have the weakest longevity. If the tool survives, it is good - but you have to pay for it. And many (most) commercial tools will die, and when they do, your support is gone. A few companies are dumping failed projects into OpenSource to at least allow customers some future support - but those are few and far between. Often you have no choice, you go where the owner of the tool wants to go, and sometimes for that tool, it is out of business. So if you buy commercial tools, you want to be very conservative and buy the bigger ones, if you don't want to take a risk.
The other thing is that market realities with commercial tools are that they usually have to keep adding features, functions and scaling capabilities to each version, in order to entice (force?) customers into upgrading (so they can make more money). So the tools often start out small and focused, but maybe not that fast or scalable - but over time they get more and to make them bigger, more bloated, less focused and ironically, sometimes ways to make them faster and more scalable - trying to grow into becoming Enterprise solutions (of sorts). So it sort of matters where you are in that products lifecycle as to how big it well be. It seems that eventually the product will crush itself under it's own weight, or it finally reaches some place where it can survive, but many big products have lost their markets or were just too expensive to keep growing. So there needs to be some caution.
Conclusion[edit | edit source]
In general, OpenSource or some Commercial tools are better for smaller organizations and smaller solutions/teams. And in general, if you're a large organization, trying to create large solutions, with large teams, that have long lifespans, then Enterprise tools are worth the added costs. But I've seen organizations be successful or fail both ways; including some enterprises that committed whole heartedly to OpenSource and succeed because they could create the additional tools and support that they needed, or other small organizations that went enterprise from the start because they knew they were going to grow the team or solution to where they needed to be and they had enough of a stake that they could afford the slower up-front development costs. But more often, the mistakes are quite costly.
Any class of solution can be right or wrong for your task. People have a tendency to try to "play it safe" and move up the food-chain too fast; so small organizations buy enterprise tools, and cost themselves far, far more in development costs, time, and missed opportunities than if they'd been more sensible to begin with. Just because IBM uses it, doesn't mean you should, remember, you're no IBM. They can afford a lot bigger mistakes, and they pay a lot for "safe". You beat them by being more nimble and cost efficient, not by being more conservative and wasteful.
And the other mistake can happen when organizations buy too small a solution and run into those solutions limits - then they have to pay for redevelopment costs to replace the solution (or wait for the solution to "grow" and hope). This isn't quite as bad, since you can often borrow design or things learned on the "too small" solution, and in theory the solution has saved you money or made you enough money to pay for redevelopment, but it is still a risk and cost.
I liken this whole thing to different cars; a School bus is great for commuting kids to school, but it probably isn't what you want to commute to work in. An Indy car is great on the race track, but wouldn't make a good family car. So you need to pick the right tool for the job, and make sure it has the right trade-offs for what you need it to do. Listen to your team, they probably know the tradeoffs and they're the ones that have to use the tools, so it is in your best interests to help them make the best choice (and not dictate to them).
👁️ See also
- Anti-aliasing - What is Anti-Aliasing? It is using color to increase the percieved resolution on a display.
- Basics of BASIC - People ask me, "How do I get started programming?" Ther are a lot of choices, but BASIC is a pretty simple start.
- Big or Little Endian - What is Endian? How do you like your eggs (or counting systems)? Big or little end up?
- Command Line Interface - There is an ancient computer debate about command-lines versus a GUI (Graphical User Interfaces).
- Databases - What is a database? What are the kinds of databases? Why do you care?
- Digitized Sound - Digitized Sound: understanding samples, rates and digital audio is really pretty simple.
- Enterprise Tools - Enterprise, Opensource or Commercial tools, which is better and why? Of course the answer is, "it depends".
- FUD - FUD means "Fear, Uncertainty and Doubt", it was used by big companies to scare users away from small companies.
- Forward Compatibility - People talk about "Backwards" compatibility, but Forward Compatibility is often more important.
- Free Features - A free feature in software, is like a free lunch: and in case you don't know, there's no such thing as a free lunch.
- Hiring Programmers - Many Human Resources and Managers, don't know how to hire or utilize programmers; proven by their job reqs.
- History of Visual Basic - The History of Visual Basic is a bit of a history of early computers and Microsoft...
- How does compression work? - How does software Compression work? How do you make something smaller?
- MHz or GHz - MHz or GHz, what does it mean? It's just clock speed - but that doesn't mean what some people think.
- RISC or CISC - During the 80s and 90s there was a Computer Chip design war about RISC or CISC.
- Raster Images - What exactly does raster versus vector images mean? Here's the very basics of pictures or rasterized images.
- Software Consultants - I worked over a decade as a consultant, and used and managed them for a couple decades more.
- Software Development Life Cycle - There's a lot of variants of a Software Development Life Cycle.
- Synthesized Sound - Synthesized Sound is just making waves... sound waves.
- UNIX - UNIX is the old war-bird of Operating Systems -- which is ironic as it isn't an OS any more -- but more on that later.
- What is MP3? - What is MP3? It's just a compressed file format used for sound (that came from MPEG's version 3).
- What is a WebApp? - What is a Web Application, and how does it vary from a traditional website?
- Why is software so buggy? - Why are programs so buggy? They're not bugs, they're undocumented features... sorry, that's an old programmer joke.
🔗 More
| |
| |
Tags: Tech Programming
