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.

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

TIA

talli

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. =)

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

talli

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.

HTH

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

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?

1. 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.
2. 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.
3. 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 egopower base business. 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.
4. 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.
5. 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.

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.

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.

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