Forum OpenACS Q&A: What does "Enterprise Class" mean?
I have been asked the question, or a variant of this question, "What does 'Enterprise Class' mean?" and the natural follow-up, "Why do I need it?" quite a few times. Each time, I feel that I've been caught in a marketroid buffer overflow. It's a term that is often used but rarely understood or put in proper perspective, at least in my experience.
So, in the grand tradition of the Asher "How to buy a Used Car" I ask the esteemed community what the hell this term means. Preferrably in non-techno-speak, of course.
I found one reasonable definition, in techno-speak, here (http://www.windowsadvantage.com/tech_edge/04-02-01_enterprise_class.asp), in an article regarding whether Win2K was "Enterprise Class." The items that the author suggests should define the term are:
1. System scalability ; scaling up (the use of multiple central processing units (CPUs) in a single system), as well as scaling out (the use of a distributed cluster system model to deliver system performance). 2. System reliability/availability determined by hardware dependability and extensions, properly structured applications and software drivers, and use of "best practice" operating procedures. 3. System/subsystem manageability centralized administration and control over all computing environment resources 4. System security protection from both physical theft and unauthorized system access. 5. Support for directory services a consolidation point to store and manage data that is used by applications and network resources for the purpose of reducing administrative overhead and providing improved environment flexibility. 6. Interoperability collaboration among computing resources, especially within a heterogeneous environment. 7. Availability of qualified resources access to highly skilled and experienced resources to design, deploy and manage the operating environments in an enterprise-class setting.These are excellent points, and ones for which certainly the components of the OACS all qualify. However, I was wondering whether anyone has any experience describing "Enterprise Class" and its benefits to non-techies, in addition to these points.
Glib responses like, "Enterprise class means you won't have your data sucked away by the evil virus troll, at least not without a fight" don't really count, although they may very well be appreciated if they're witty enough. (gauntlet thrown at toddg's feet)
This question certainly is directed at not only helping me (and others) pitch the benefits of the OACS and its components to clients, but also to help write the literature for the OACS (which refers to enterprise-level on the homepage without mentioning what it is).
The specific points you quote are conclusions/requirements drawn from enterprise level goals and strategy. It helps to first be certain that "enterprise class" strategies are understood and appropriate for the task (most likely they are!), and thus your question...
I've used these two books to help identify a broad set of enterprise strategies applicable to various clients that nontechies agree with:
Freidheim, Cyrus. (1998). Trillion-Dollar Enterprise: how the alliance revolution will transform global business. Reading, MA:Perseus Books
Kanter, Rosabeth Moss. (1995). World class: Thriving locally in the global economy. NY:Simon Schuster.
The points aren't unique to these books; I would be interested in knowing what references others use to create a foundation for value and/or opportunity.
Once the client (and IT company) agrees on the strategy, the technical requirements follow --ie. IT must do everything. =)
Migrating a desktop application to a web application certainly exposes the differences between non-enterprise and enterprise. The shift implies that dedicated hardware will be chosen, it will be run 24x7, it will be backed up, it will be secure, and professional services for installation/support/training will be available. During installation, the system will have to be configured to receive automated data feeds from other enterprise systems (mostly ERP).
All of the above means that the decision to purchase ideally involves IT signing off on the technical competency or appropriateness of the solution, as opposed to before-enterprise when the department head just wrote a check. The sales cycle thus becomes much longer.
Enterprises (the kind that buy "enterprise" solutions) have too many complex systems to master each one and will rely on professional services to do this. This hand-holding is absolutely necessary for them. It costs a lot, and it's worth it.
My friend's company is small, and may have to get most of the above by partnering or setting up a VAR network. Or getting some VC and staffing up.
Allow me to provide a sense of what kind of application I'm trying to apply the terms to, and why I think that while "Enterprise Class" is not the right term, it's the only one I can think of right now.
One of our clients is an organization of about 60 people. Of these, the DB app we'll be building them will only be touched by about 25 out of this group. Of these 25, I would say that there will no more than 10 or 12 will have admin access to the really critical data. As a result, I would doubt there will ever be more than 5 concurrent users of the DB.
That being said, it may not be an exagerration to say that the sanctity of the data (security, consistency, maintenance, etc) is tantamount to life or death in some cases. If a record is lost or corrupted, then it could mean that a client's service is delayed, changed or at worse not delivered. For some of the organzation's clients this could be disastrous.
This is probably way overstated as they've been using a Clipper DB for the past 10 years without quite killing anyone, but it illustrates a point. The client could probably get away with an application like Filemaker Server or MySQL, but building a system using those tools might be irresponsible if you're looking to protect the data as completely as possible.
Probably the vast majority of OACS projects will fall under a category that is not really "Enterprise" in scope but do require levels of data security and maintenance that are found in traditionally enterprise class tools. The reason the OACS community is such a stickler for a true RDBMS, I might argue, is not because we're all trying to build Amazon.com but because we want the best tools to maintain the integrity of our systems.
John, I like your idea that "Enterprise Class" must also include support solutions, or at least access to support solutions. That's a very helpful point. Torben, I'll check out those books, thanks...
Enterprise Class. Funny story there. As we all know, all technical terms describing suitability are defined in constrained agreement between suits and techies, both of whom are lying to each other just as fast as they can, both trying to avoid being replaced by a very small perl script. Remember also that techies form phrases out of in-jokes to nerd culture. With this in mind, we can examine the etymology of 'Enterprise Class' as applied to computers. It means 'capable of driving the USS Starship Enterprise'. No seriously:
- Stable: only crashes when attacked by aliens, for instance, intelligent nanoprobes or guys from marketing.
- Extendible: painlessly interfaces with a variety of devices, such as medical scanners, docwolf's "energy drinks", weapons, small planets, and men who go mad and tie their brains in directly.
- Hidden: no one ever sees an 'Enterprise Class' computer. It may even be gerbil-powered.
- User Friendly: usable by persons born 6 centuries before its construction, or in our case, just before the italian renaissance. It may be I18N, but everyone speaks English anyway.
- Persistent: capable of defying logic or physical reality. Things like "compute our chances in that paradox', or 'Enron Central, please hide all this money forever' are commonalities with 'Enterprise Class'.
- Clean: there is no pr0n anywhere on the server. This may be more improbable than the previous 5 design goals.
Stupid, yes, but I submit that the above are just as valid a definition as the confused sales pitches of the auto-fellating computer media.
I will, however, post a serious rebuttal. I had the misfortune of working on 'Enterprise Class' back in 98-99. Big old IBM mainframes, VM-VXes from the early 80's. Refrigerator sized hard drives; components soldered onto breadboard (back then IBM still hadn't moved everything to ICs and modern fabs). So here's my impression of actual 'Enterprise Class' Computing:
- Old. When you find something that works, you stick with it. Setting up such a system demands you toss out all notions of technology as sexy or innovative. I first bought into the ACS when philg wrote "We ignored technology startups. We ignored Windows NT. We used the same technology we had used since 1994." et cetera.
- Service faster than your local fast food joint. One to Four hour service contracts. Things break. Life sucks.
- Available source. I think this is the most important. I didn't say "open" just "available". You'd be laughed out of the glass room if you tried selling a mainframe without source. And I say this not as an OSS partisan, but as the poor bastard who had to keep this stuff running. The customer will have people crawling all over that source.
Your 7 points are certainly important. But I think they're baseline these days, and not sufficient. 'scalability, security, interoperability' fits my definition of "Software that isn't crap." And people that want your seven points but not my additional three should understand that don't need 'Enterprise', just quality. The above seven points would fit a system comprised of a linux box, Rolf, and a nearby pizza place.
From your clarifying (second) post, it sounds like the term you are looking for is "mission-critical". As in, the mission of the enterprise will fail (or at least be seriously impaired by) the failure of the component in question.
That being said, is there a difference between "mission critical" and "enterprise class"?
Todd, glad you know where your pants are. Now, would you be so kind as to let Vinod know what you did with his?
I wholeheartedly favor Todd's definition over Talli's. After all, he enumerated 9 planks, compared to Talli's 7. Even adding that "mission critical" piece only gets you to 8. Also, reason #7 doesn't count since it defines "enterprise-class" in terms of itself. Too recursive.
I also like the fact that Todd's enterprise class system can be implemented with "a linux box, Rolf, and a nearby pizza place".
I define them as:
Enterprise class systems are about setting global standards, being leaders in taking action (not just talk), creating capable, high-capacity [mission critical] solutions that can be applied and adapted to the multitude of local environments (localization). This kind of system is too large for any single firm to really develop well --requiring a vast network of alliances as in "open source" development for example.
Mission critical - something that is required in to reach a goal. Such as an egg-timer reminding me about a current mission: dinner cooking on the stove.
Enterprise solutions are not just a buzzword for the Global 2000, but a buzzword for anyone (entrepreneur, volunteer, corporation etc) who wants to participate in a global event (of a common mission) in creating something greater (than the sum of the parts) through a concerted effort.
A system is only enterprise class if the customer perceives it to be so.
Just look at some applications suites which we'd all agree are "enterprise class": SAP, Oracle, CICs, DB2, ...
What do they have in common?
- Expensive. A customer buying an affordable product just feels like a businessman or entrepeneur. They're badges with no class. Spending megabucks on an "enterprise class" system means that you're part of the big boys club: you're an Enterprise.
- Big on research. Your enterprise customers must be made to feel that you're working tirelessly at the bleeding edge to make sure that the product they bought is better than the product their competitors bought. To be considered, you have to have a research budget and it has to be bigger than the GDP of Switzerland.
Room to grow. No matter how big and sprawling the customer's "enterprise" is right now, he has to feel that the system has room to grow with his
ego power basebusiness. The best way to give this impression is to list large companies amonsgt one's existing customers, even if your product only manages the janitorial shift. Another way to give this impression is to offer a pricing plan which is capable of swallowing all of the company's 3rd round of venture funding.
- Professional Services. A customer feels special if they feel they warrant the personal attention of your best consultants. Your consultants are perceived as being the best if they cost a lot.
- It all comes back down to money. The CEO/CFO already has the most brains and is obviously the only one who really knows how the company should spend money from one day to the next, but he just needs something which can make if obvious to the goons next to him. So the system must be able to slice and dice the data in any way he can think of (and ways that he hasn't thought of yet) so that he can point to the success of his initiatives and reward himself with that fancy new yacht or weekend in Monte Carlo. This means that the system must be able to capture every expenditure made by the enterprise and be able to relate it to one of three things: share price, productivity or profit. So, an enterprise class system allows the CFO to set up a summary for peanut butter consumption vs share price, or internet bandwidth vs. productivty, or (best of all) payroll vs. profit (annual bonus).
I'm sure that the VCs were convinced that tcl and aolserver were creating cracks in the customer perception of aD as an enterprise vendour and so moved to Java as a way of papering over those cracks. And they'd have done it too, if it hadn't been for those pesky open source kids...
Yup, it's Monday.
I contend this: 'Enterprise Class' is a way, not a tool; it is defined by the amount of human capital expended to keep it running, and the human importance of its uptime. To think that the tool is the way would be analogous to selling customers a 'bushido class' sword -- but the sword can know nothing of the way of life-in-death.
I did not emphasize my 'service' plank highly enough. I can sell mainframes to two companies; one has passing use of it, the other is totally reliant upon it. One looks for tools and 'wizards' to cut its IT staffing requirements; the other has people swarming over its code to spot problems before they happen, and certainly before tool vendors package them into shrink-wrap. One talks about 'Enterprise Class'; the other simply acts, and contends not with names and labels.
Talli: my god! These aren't my pants, these are Vinod's!!
What to do, what to do. Aha!
- Take Vinod's pants.
- Biiiiig profits!!
I must correct one of his points: A pizza place is necessary, but not sufficient, for Rolf to work efficiently. Access to high-quality coffee or tea is critical, as well as the ability to easily travel to one or more hamburger-based franchise establishments.
With those elements in place, he is capable of building a yahoo stores clone in under 8 weeks.
Or so I hope.
Todd, you're right. So perhaps what we're really talking about is the OACS has an "Enterprise Class" community of developers and companies that are capable of building, maintaining and supporting a software package that any size organization can leverage. This, I think, makes a lot of sense and is quite compelling.
I imagine this kind of idea should be somehow folded into the way the OACS is presented. For instance, would it make sense to write a little introduction or definition to and of Enterprise Class and have the "enterprise" on our front page link to that?
I do, however, take exception with this "Rolf" thing everyone is speaking of. The fact that the megalomanical Doc Wolf claims that he exists and can accomplish feats of ridiciluous heights on a combination of caffeine and high caloric diets means nothing to me. That mad scientist is always concocting lies and half-truths from the depths of the Floridian jungles.
Perhaps you are all referring to his humpbacked lackey, Igorzolf?
Of course none of this helps Musea sell OACS ("oaks") to clients. I should add one more plank, then, for marketing's sake. An 'Enterprise capable' tool is flexible. The API is highly orthagonal, modules are well integrated, the data model is kept in one place with powerful modifiers (eg, a RDBMS), and simple yet powerful transforms are possible (page_contract, ns_ filters, etc); debugging is easy to trace. Flexibility is extremely important so that a client's staff may quickly learn how to maintain and extend the Enterprise. I think OACS fulfills this far better than the over-engineered Java app servers running on W2K (which still crashes twice a day for me). This is not the same as easy to use -- the simplicity and orthagonality of the system is the important point, not the inclusion of a few "wizards"; the "wizards" can't help the user do something unanticipated.
Talli, I do like your idea of presentation. It might just work.
No haiku about "Enterprise", but since you asked:
you - step into my
office. why? 'cause you're freaking
fired! plum blossom.
And that's it. I'm going back to bed.
An interesting set of definitions for "Enterprise application frameworks" and OACS would be one for Web apps is in:
Building Application Frameworks : Object-Oriented Foundations of Framework Design by Mohamed Fayad (Editor), Douglas C. Schmidt (Editor). Wiley
Implementing Application frameworks by the same authors.
These books (it is really a trilogy) has a lot on the software engineering side but also business arguments like the ones discussed here. Amazon has the PDFs for the preface that provides some of the definitions.
Regarding the name "Kappa", we could have named the company after the lizard (in keeping with mozilla etc.), but really it refers to the Greek letter, as in... the tenth brightest star in a constellation etc. We don't have to worry about trademark disputes; There's more letters readily available should we need them. =) And as you state, this company is among those that "simply acts, and contends not [very long] with names and labels."
I've had business people ask for the definition of "scalability", yet they all inherently know the meaning of "Economies of scale." So, one might want to include the phrase in a summary for business types (as a subset of scalability since the two terms are not equivalent), and use other phrases accordingly also. Just a thought anyway.