Hi Stuart - I know you are talking D3 here - but if it was U2, IBM
would be very willing to come down and present with you the benefits
and give some case studies. I have not dealt with the D3 guys for some
time, so i am not sure if they do the same - it may be worth asking
tho,as after all it is a big licence sale for them as well !


rgds
Symeon.

Great response, just what I was after.

A big thanks to all those that responded here, or emailed me directly.

Stuart

"stuey" wrote:
I've sat on this response for a while and I hope it's not too much too
late.

Asking for "real world examples of large sites" might be the wrong
question to ask to solve a specific business problem. There is an
implied assumption that the end-user needs to add more licenses, so
they want to know what the limits are. If that assumption is invalid
then decisions might be made that are equally invalid toward solving
the original problem in a timely and/or economical manner.

I think a question should be asked first: "can we support more people
with the same number of licenses and some software changes?"
Depending on how the app is designed it may be able to run
transactions for several thousands of concurrent users on some
hundreds of licenses. The question may not be whether the system can
support some large number of concurrent users but whether it can
support the number of processes _actually required_ for a projected
number of non-persistent end-users.

For in-depth information on figuring out how many licenses are
actually required to support a given application, have a look at my
blog and the new article: "How many licenses do I need?"
http:// removethisNebula-RnD.com/blog

Does your client use a green screen interface? What if, based on your
research, your client decides MV is incapable of scaling to support
3000 users and they decide to migrate to Oracle Financials or SAP.
Those platforms aren't going to run every user persistently either
because they aren't green screen. As I understand it, they use pooled
connections and other techniques so that large numbers of queries from
different users can be processed from a much smaller number of
licenses (an N:1 ratio if you read my article). So your client is
told "yes, we can support 3000 users and we have sites to prove it".
Well, the MV market supports the same large numbers of users for some
sites too, and we don't need a 1:1 ratio of licenses any more than the
other DBMS platforms do. This isn't about DBMS scalability, it's
about application design and making use of modern programming
techniques. So don't let your customer go away thinking what they
have is any different or less capable than any other platform.

If your client has a traditional green screen which requires 1:1
licensing, then while they are looking into DBMS scalability they
might also consider a re-fit of the front-end for specific user
categories that are expected to expand. I'm doing this with a couple
clients right now. I call it Role Oriented Design, though I'm sure
there's another more popular name somewhere. The idea is that you
identify roles of specific users, then you figure out how many
licenses that specific class of users require based on all of the
specific programs they use. Then compare the development costs
required for enhancement of just those specific apps to satisfy the
needs of those workers. Then compare that number to flat out DBMS
license purchases to support the existing 1:1 green screen model. And
while you're at it you might compare that cost to full app
replacement. If development costs are lower for that area then it's a
good target for enhancements. After starting the first project you'll
find similar endeavors to support other roles have a much lower total
cost, so the savings start to cascade.

So the bottom line is that a flat out license purchase might cost some
hundreds of thousands of dollars plus about 15% annual support. If
putting a non-persistent thick or thin client on parts of the app will
eliminate the need for extra licenses, then it doesn't matter how many
licenses MV "can" support. You may already have everything you need.

Again, I'm available for discussion about techniques and specific
products if any of this sounds interesting.
Tony
TG@ removethispartNebula-Rnd.com

Tony

Neither too much nor too late, thanks for the input.

The application in use is indeed character based for the most part, (I
hate the term green screen). Due to a commercial take over, the size of
the customer's operation is likely to multiply several times over.

What I was after was the ability to say (in principle) that the
existing application could scale to 1,000 to 2,000 users with little or
no application changes. I was fairly confident that there were mv sites
out there of this size, but wanted more concrete details.

If this all comes off then it will be a major project, and it may be
that interfaces for certain users could be redesigned as you suggest.
In fact this application already makes use of pooled resources for a
website interface via FlashConnect.

I will bear your comments and offer of further input in mind, thanks
again.

Stuart

Careful. Nobody's saying that your application can scale as is. I think you
understand that the underlying database can easily handle an application
with that many users; however, if your application has not been written so
that it will scale - then it might not, regardless of the underlying
database.

Perhaps it will, perhaps it will take a little tweaking, perhaps it would
need a full re-write. Only someone that knows your application could say.

hth
Colin Alfke

"stuey" wrote > Tony

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Tony,

I think you are describing what is currently regarded as part of SOA
(Service Oriented Architecture) where the service is provided by the
application to serve the "Role" being played by the client. In SOA they
commonly talk about layers of functionality, sometimes on the same
functional level, sometimes above or below another service layer.

Your modification would be made to the communication layer(s) to allow for a
one-to-many relationship with the licensed connections with a possible
additional modification to the application layer(s) to support the
communication changes.

'Role Oriented Design' might get funny looks and require you to explain, but
'Service Oriented Architecture' on the other hand will get smiles and nods
(even if they don't know what it means.)

BFaux-

"B Faux" wrote:
Well, you can do SOA using ROD but they are separate concepts. SOA
describes a deployment methodology. ROD is _what_ you render, not
_how_ you render it. People entering orders have a different role
than those in the warehouse. Their needs are different so the set of
programs they use are different. If 80% of the employees are in the
warehouse then you might choose to target the functions required by
those people before you do things like cash receipts or check
disbursement. I'm not even talking about Roles as a method of
prioritization, just as categorization. In the same example do you
really want the people in the warehouse to mouse around when they've
been using serial lines with a Wyse50 for 20 years? In this case your
office crew might get the first mods. And as I've mentioned to a
couple people recently, upper management often gets priority over
everyone else with GUI and graphics to show sales and projections,
etc. (Hey, they're the ones that make the purchase decisions for
software so they often get whatever they want.) Prioritized role
oriented development for these people can be called Hot ROD. Now
that's what'll get the funny looks.

The SOA aspect relates to deployment, for example when you allow your
trading partners to check their order status, download pricing, or you
let your remote sales force recap how their meetings with clients are
going (one of my current projects). Each class of user does have a
role for which specific services must be available, and ROD ensures
that they have the tools required, but the decision to make those
resources available via SOA is different. SOA, to me, is more along
the lines of Web Services or extranet apps (thick or thin).

Maybe this is splitting hairs, I'm just as inclined to accept your
definition if it means we're all on the same page and doing business.

T

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote

Tony,

I agree completely with that last bit, any definition is fine as long as the
check clears! - On the other points, although I believe I understand your
point of view, I am not sure I agree. If a trading partner could be equated
with the internal constituents (management, warehouse, etc) then the SOA
model would seem to allow for deploying the Role Oriented Design. Unless
you are saying that they are completely separate stages, development versus
deployment, in which case your point is well taken.

And I really like the Hot ROD thing, LOL ;-)

BFaux-