Architectural feedback

[John Spiegel]

Hi all,

I'm in the early stages of designing a system that we'll use in-house and am
looking for opinions and suggestions for further reading on which directions
to take.

Background: Though we're a small company, I'd like to design this with the
mindset of a larger company from the start. This will be an ongoing project
to encompass a lot of needs, which will generally be variations on standard
themes: Customer account management, billing, reporting and other fairly
common business functions. Most functionality will be accessed from our LAN
with WinForms-based apps (assume all client machines are Windows running at
least 2000). There will be some limited Web access for employees, e.g.,
order forms for sales staff. While we may eventually want to build some Web
services for sharing informtion, the general pulic website will remain
fairly autonomous.

The nature of the company and application is that there will be fairly
frequent releasing of the system, or components thereof.

Current leanings: Most of the functionality will probably APPEAR to be
(from user standpoint) unified under a single app. There are a number of
underlying components into which this apparent monolith will actually be
broken. Aside from various departmental boundaries that will make for nice
conceptual breaks. Utilities, e.g., common dialogs, data access and account
calculations, will be broken into various solutions. I'm thinking that
there will be a skeleton client app that provides the system navigation,
security and user preferences then uses the appropriate other resources to
provide actual functionality.

A lot of my uncertainties are in determining what forms and in what
locations the pieces should be. For example, I'm not clear on whether the
core app must reside on the client or may be run from the server. Is it
better to leave the individual dll's on the server, or install in each
client's GAC? My guess is that deploying all components to individual
clients will give notably better performance. On the downside, that would
imply updating a number of machines every time we add a new or function.or
want to release bug fixes.

I've read a fair amount on remoting, serviced components, and related
functional divisions (a 70-320 prep book, mainly), but have seen little that
really ties together when the best situations to use each are.

TIA,

John

[Cor Ligthert]

John,

When you have not the staff equaly too Oracle, SAP or Peoplesoft to your
command for what you want to do, than will this what you write has a very
high change to fail in my opinion.

Background: Though we're a small company, I'd like to design this with
the
mindset of a larger company from the start.

Microsoft has bought Navision for that.

You are not the first one who tries that, however there were who succeed in
it (often after a complete refreshment from the first developmentteam too
new(er) because the project did cost more and took more time than the
management had expected).

However just my opinion as I wrote.

Cor

[John Spiegel]

Hey Cor,

"Like a large company" leaves a lot of room. What I meant is "not a tiny
company". Right now, we've only got about 15 clients and a single server.
I'm talking about just keeping in mind things like the effects of having a
server cluster, separating out the database server from application
server(s) and/or introducing servers that are more dedicated to certain
processes/departments and how to share resources. We're not trying to build
an end-all-be-all system for the masses.

We have the luxury of having an existing system that will meet current needs
as well as the foreseeable future. This new project will be an ongoing,
long-term one that will work in tandem with the existing for some time to
come. It will at first, mainly add new functionality that the current
lacks, but as time goes on, will absorb the functions of the current.

The reasons are many, but (assuming you don't want a dissertation on the
inner workings of a company you don't care about) I think we do have enough
justification to look at heading down this path.

Thanks,

John

We have an existing VFP system that honestly would meet our needs for some
time to come.
"Cor Ligthert" <no************@planet.nl> wrote in message
news:ea**************@TK2MSFTNGP11.phx.gbl...

John,

When you have not the staff equaly too Oracle, SAP or Peoplesoft to your
command for what you want to do, than will this what you write has a very
high change to fail in my opinion.

Background: Though we're a small company, I'd like to design this with
the
mindset of a larger company from the start.
Microsoft has bought Navision for that.

You are not the first one who tries that, however there were who succeed

in it (often after a complete refreshment from the first developmentteam too
new(er) because the project did cost more and took more time than the
management had expected).

However just my opinion as I wrote.

Cor

[Bob Milton]

John,
Just to muddy the water some more - do you care what happens when the
server goes down? (They do). That can influence your design. For example,
bank branches absolutely must be able to function with a failed server (or
connection to same). This means a lot of functionality is duplicated on the
clients just for this case. (But upgrades are done rarely - sometimes years
apart - because of the pain of upgrading).
Basically, there aren't any good guidelines as to when you use which
approach since that can be so dependent on the specific situation.
BTW, trying to foresee future growth and features in your application
(being more "large company like") is a good practice in my experience.
Bob Milton

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Hi all,

I'm in the early stages of designing a system that we'll use in-house and
am
looking for opinions and suggestions for further reading on which
directions
to take.

Background: Though we're a small company, I'd like to design this with
the
mindset of a larger company from the start. This will be an ongoing
project
to encompass a lot of needs, which will generally be variations on
standard
themes: Customer account management, billing, reporting and other fairly
common business functions. Most functionality will be accessed from our
LAN
with WinForms-based apps (assume all client machines are Windows running
at
least 2000). There will be some limited Web access for employees, e.g.,
order forms for sales staff. While we may eventually want to build some
Web
services for sharing informtion, the general pulic website will remain
fairly autonomous.

The nature of the company and application is that there will be fairly
frequent releasing of the system, or components thereof.

Current leanings: Most of the functionality will probably APPEAR to be
(from user standpoint) unified under a single app. There are a number of
underlying components into which this apparent monolith will actually be
broken. Aside from various departmental boundaries that will make for
nice
conceptual breaks. Utilities, e.g., common dialogs, data access and
account
calculations, will be broken into various solutions. I'm thinking that
there will be a skeleton client app that provides the system navigation,
security and user preferences then uses the appropriate other resources to
provide actual functionality.

A lot of my uncertainties are in determining what forms and in what
locations the pieces should be. For example, I'm not clear on whether the
core app must reside on the client or may be run from the server. Is it
better to leave the individual dll's on the server, or install in each
client's GAC? My guess is that deploying all components to individual
clients will give notably better performance. On the downside, that would
imply updating a number of machines every time we add a new or function.or
want to release bug fixes.

I've read a fair amount on remoting, serviced components, and related
functional divisions (a 70-320 prep book, mainly), but have seen little
that
really ties together when the best situations to use each are.

TIA,

John

[William Stacey [MVP]]

wow. First, I would look *seriously at some existing accounting packages
and/or CRM that your company could buy, that may be extentable or have
exisiting apis/web service points to extent for your specific needs.
Writing a complete accounting system is just a massive task and many have
failed so why recreate the wheel? I would keep looking first.

However, say you need to do xyz and need custom inhouse function. Below is
a big generalization and naturally the options are long and things are
complicated. Lets forget the DB for now and just say that is an
implementation issue and can be abstrated with your SOA. Let also assume
you have one server and one client. I would use WSE using tcp or http via
IIS and create my Business layer/SOA contracts. CreateCustomer(),
UpdateCustomer(), etc, etc. Start small and get the base functions you
need. Create your smart clients as std winforms apps using c# or VB. They
will call web services server to get lists, updates, etc. As the business
layer is web services, you can use console clients, windows clients, or web
clients and they all call the same buisiness logic/web services. Just your
presentation layer changes. I said forget the db, but SQL 2005 could change
this a bit. SQL 2005 can now host xml web services and CLR .net assemblies.
So in some respects, it can now be a one-stop-shop to host your business
tier and have ready access to your data as your inside the server.
Naturally you can leverage all the transaction ability of the server within
your business code and leverage things like the new Broker which can give
some cool options and reliability in your code. You can also start coding
with it now for proof of concept stuff and prototyping. I may be well worth
the effort to look hard at it now and see how much logic you want to keep in
the "server" and what you may want on other web servers that just call sql
DB in normal manner (i.e. ADO.Net, etc.) With integrated web services,
direct inproc DB access, and CLR hosting, it makes a powerful thing to look
hard at now.

Again this is a big topic and you really want to get some good books on
three tier arch, etc. Good luck!

--
William Stacey, MVP
http://mvp.support.microsoft.com

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:#w**************@TK2MSFTNGP11.phx.gbl...

Hi all,

I'm in the early stages of designing a system that we'll use in-house and am looking for opinions and suggestions for further reading on which directions to take.

Background: Though we're a small company, I'd like to design this with the mindset of a larger company from the start. This will be an ongoing project to encompass a lot of needs, which will generally be variations on standard themes: Customer account management, billing, reporting and other fairly
common business functions. Most functionality will be accessed from our LAN with WinForms-based apps (assume all client machines are Windows running at least 2000). There will be some limited Web access for employees, e.g.,
order forms for sales staff. While we may eventually want to build some Web services for sharing informtion, the general pulic website will remain
fairly autonomous.

The nature of the company and application is that there will be fairly
frequent releasing of the system, or components thereof.

Current leanings: Most of the functionality will probably APPEAR to be
(from user standpoint) unified under a single app. There are a number of
underlying components into which this apparent monolith will actually be
broken. Aside from various departmental boundaries that will make for nice conceptual breaks. Utilities, e.g., common dialogs, data access and account calculations, will be broken into various solutions. I'm thinking that
there will be a skeleton client app that provides the system navigation,
security and user preferences then uses the appropriate other resources to
provide actual functionality.

A lot of my uncertainties are in determining what forms and in what
locations the pieces should be. For example, I'm not clear on whether the
core app must reside on the client or may be run from the server. Is it
better to leave the individual dll's on the server, or install in each
client's GAC? My guess is that deploying all components to individual
clients will give notably better performance. On the downside, that would
imply updating a number of machines every time we add a new or function.or
want to release bug fixes.

I've read a fair amount on remoting, serviced components, and related
functional divisions (a 70-320 prep book, mainly), but have seen little that really ties together when the best situations to use each are.

TIA,

John

[Cor Ligthert]

John,

I dont think that I can give you an advise (I can make an empty message from
which you saw hundreds and than are you as far as you are now) however some
things in your message let me think on webservices.

And to get the best idea about that is for me this walkthrough very good.

http://msdn.microsoft.com/library/de...alkthrough.asp

It directs you as well directly that you should seperate your data from your
user interfaces.

Just my thoughts,

Cor

[Cor Ligthert]

William,

Before you think it, I had sent my message before I saw yours, better when I
had sent mine, I saw it.

I think that it is basicly not far from each other.

:-)

Cor

[William Stacey [MVP]]

Sorry Cor, I did not follow that? Cheers.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Cor Ligthert" <no************@planet.nl> wrote in message
news:#D**************@tk2msftngp13.phx.gbl...

William,

Before you think it, I had sent my message before I saw yours, better when I had sent mine, I saw it.

I think that it is basicly not far from each other.

:-)

Cor

[John Spiegel]

Hey William,

Thanks for the feedback!

wow. First, I would look *seriously at some existing accounting packages and/or CRM that your company could buy, that may be extentable or have exisiting apis/web service points to extent for your specific needs. Writing a complete accounting system is just a massive task and many have failed so why recreate the wheel? I would keep looking first.

Sheesh. Rereading my original post I scoped the problem like an end user!
Bad John! <g> Some of this may duplicate what I mentioned in my response
to Cor, so sorry for repetition...

I was pretty vague as to "like a large company"--"no longer super-tiny" may
be more accurate. We're currently tiny (1 server, 15 clients). I'm looking
at how do we build something with the idea of scaling to 100-ish users on a
server-clustered (but probably single locationed) LAN with a few dozen more
needing limited functionality over the Internet.

We have an existing system that handles much and can stay around for a while
to come. Though there's always overlap, we're not so much reinventing the
wheel, per se. In many regards, we're more looking to tie together various
other systems like an existing accounting package, supplier interfaces, et.
al. While there will be some CRM functionality, it's not nearly as in-depth
as one thinks of a full-blown CRM. Also, this will be an ongoing project
where we'll roll out functionality incrementally through the years. (The
current system has, depending on definition, been in the works for eight
years.) So we have no hard and fast time frames. I have no delusions that
we can build the perfect system that ten years from now will still be
perfect.

How is the performance of a Web service-based architecture? This question
comes as much from lack of real world experience with them as anything.
I've done a lot of MCSD prep and learned about a lot of topics, but the
examples are too simplistic to give much real feel in a lot of cases and
most of the topics get covered in a vaccuum. On the other side, the
patterns & practices book I've read is very high level, touching on dozens
of design patterns in very light detail. Any recommendations on a good book
that delves into the topic further?

Thanks for all the consideration!

- John

[John Spiegel]

Hi Bob,

Thanks for jumping in! I would like to factor in multi-server and reduncy
considerations (clusters/failover). On a scale of on-line gaming to
financial and medical apps, we're somewhere in the middle. My light reading
has indicated that (not meaning to trivialize this but) once the servers
themselves are configured, the applications themselves, if planned for, are
no where near as excruciating to run and stay up in such an environment than
was the case not so long ago.

- John

"Bob Milton" <bm*****@adelphia.org> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

John,
Just to muddy the water some more - do you care what happens when the
server goes down? (They do). That can influence your design. For example,
bank branches absolutely must be able to function with a failed server (or
connection to same). This means a lot of functionality is duplicated on the clients just for this case. (But upgrades are done rarely - sometimes years apart - because of the pain of upgrading).
Basically, there aren't any good guidelines as to when you use which
approach since that can be so dependent on the specific situation.
BTW, trying to foresee future growth and features in your application
(being more "large company like") is a good practice in my experience.
Bob Milton

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Hi all,

I'm in the early stages of designing a system that we'll use in-house and am
looking for opinions and suggestions for further reading on which
directions
to take.

Background: Though we're a small company, I'd like to design this with
the
mindset of a larger company from the start. This will be an ongoing
project
to encompass a lot of needs, which will generally be variations on
standard
themes: Customer account management, billing, reporting and other fairly common business functions. Most functionality will be accessed from our
LAN
with WinForms-based apps (assume all client machines are Windows running
at
least 2000). There will be some limited Web access for employees, e.g.,
order forms for sales staff. While we may eventually want to build some
Web
services for sharing informtion, the general pulic website will remain
fairly autonomous.

The nature of the company and application is that there will be fairly
frequent releasing of the system, or components thereof.

Current leanings: Most of the functionality will probably APPEAR to be
(from user standpoint) unified under a single app. There are a number of underlying components into which this apparent monolith will actually be
broken. Aside from various departmental boundaries that will make for
nice
conceptual breaks. Utilities, e.g., common dialogs, data access and
account
calculations, will be broken into various solutions. I'm thinking that
there will be a skeleton client app that provides the system navigation,
security and user preferences then uses the appropriate other resources to provide actual functionality.

A lot of my uncertainties are in determining what forms and in what
locations the pieces should be. For example, I'm not clear on whether the core app must reside on the client or may be run from the server. Is it
better to leave the individual dll's on the server, or install in each
client's GAC? My guess is that deploying all components to individual
clients will give notably better performance. On the downside, that would imply updating a number of machines every time we add a new or function.or want to release bug fixes.

I've read a fair amount on remoting, serviced components, and related
functional divisions (a 70-320 prep book, mainly), but have seen little
that
really ties together when the best situations to use each are.

TIA,

John

[William Stacey [MVP]]

clustering is more a hw arch then sw arc thing so you should not have to
worry about that now during sw design and class design. There are many ways
to go with clustering. SQL 2005 will give you some good options here as
well and may be all you need. IIS has well documented ways to use server
farms, etc.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:OL**************@TK2MSFTNGP10.phx.gbl...

Hi Bob,

Thanks for jumping in! I would like to factor in multi-server and reduncy
considerations (clusters/failover). On a scale of on-line gaming to
financial and medical apps, we're somewhere in the middle. My light reading has indicated that (not meaning to trivialize this but) once the servers
themselves are configured, the applications themselves, if planned for, are no where near as excruciating to run and stay up in such an environment than was the case not so long ago.

- John

"Bob Milton" <bm*****@adelphia.org> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...

John,
Just to muddy the water some more - do you care what happens when the

server goes down? (They do). That can influence your design. For example, bank branches absolutely must be able to function with a failed server (or connection to same). This means a lot of functionality is duplicated on the

clients just for this case. (But upgrades are done rarely - sometimes

years

apart - because of the pain of upgrading).
Basically, there aren't any good guidelines as to when you use which
approach since that can be so dependent on the specific situation.
BTW, trying to foresee future growth and features in your application (being more "large company like") is a good practice in my experience.
Bob Milton

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message news:%2****************@TK2MSFTNGP11.phx.gbl...

Hi all,

I'm in the early stages of designing a system that we'll use in-house

and am
looking for opinions and suggestions for further reading on which
directions
to take.

Background: Though we're a small company, I'd like to design this with the
mindset of a larger company from the start. This will be an ongoing
project
to encompass a lot of needs, which will generally be variations on
standard
themes: Customer account management, billing, reporting and other fairly common business functions. Most functionality will be accessed from our LAN
with WinForms-based apps (assume all client machines are Windows running at
least 2000). There will be some limited Web access for employees, e.g., order forms for sales staff. While we may eventually want to build some Web
services for sharing informtion, the general pulic website will remain
fairly autonomous.

The nature of the company and application is that there will be fairly
frequent releasing of the system, or components thereof.

Current leanings: Most of the functionality will probably APPEAR to be (from user standpoint) unified under a single app. There are a number of underlying components into which this apparent monolith will actually be broken. Aside from various departmental boundaries that will make for
nice
conceptual breaks. Utilities, e.g., common dialogs, data access and
account
calculations, will be broken into various solutions. I'm thinking that there will be a skeleton client app that provides the system navigation, security and user preferences then uses the appropriate other resources to

provide actual functionality.

A lot of my uncertainties are in determining what forms and in what
locations the pieces should be. For example, I'm not clear on whether the core app must reside on the client or may be run from the server. Is

it better to leave the individual dll's on the server, or install in each
client's GAC? My guess is that deploying all components to individual
clients will give notably better performance. On the downside, that

would imply updating a number of machines every time we add a new or function.or want to release bug fixes.

I've read a fair amount on remoting, serviced components, and related
functional divisions (a 70-320 prep book, mainly), but have seen little that
really ties together when the best situations to use each are.

TIA,

John

[Brandon Potter]

You are already aware of the scope creep and "my God, the code has become so
entangled that we have to start over" possibilities of a project like this.

With that said, have you thought about possibly using a plugin-based system
for this app? The main app (.exe) is simply a skeleton that defines which
and what order other assemblies are loaded in. If you're not familiar with
Interfaces, you would be well served in the long run to take 2 months and
get comfortable there before tackling it. Ever seen Microsoft CRM? Might
look at that for UI ideas.

Brandon

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Hi all,

I'm in the early stages of designing a system that we'll use in-house and am looking for opinions and suggestions for further reading on which directions to take.

Background: Though we're a small company, I'd like to design this with the mindset of a larger company from the start. This will be an ongoing project to encompass a lot of needs, which will generally be variations on standard themes: Customer account management, billing, reporting and other fairly
common business functions. Most functionality will be accessed from our LAN with WinForms-based apps (assume all client machines are Windows running at least 2000). There will be some limited Web access for employees, e.g.,
order forms for sales staff. While we may eventually want to build some Web services for sharing informtion, the general pulic website will remain
fairly autonomous.

The nature of the company and application is that there will be fairly
frequent releasing of the system, or components thereof.

Current leanings: Most of the functionality will probably APPEAR to be
(from user standpoint) unified under a single app. There are a number of
underlying components into which this apparent monolith will actually be
broken. Aside from various departmental boundaries that will make for nice conceptual breaks. Utilities, e.g., common dialogs, data access and account calculations, will be broken into various solutions. I'm thinking that
there will be a skeleton client app that provides the system navigation,
security and user preferences then uses the appropriate other resources to
provide actual functionality.

A lot of my uncertainties are in determining what forms and in what
locations the pieces should be. For example, I'm not clear on whether the
core app must reside on the client or may be run from the server. Is it
better to leave the individual dll's on the server, or install in each
client's GAC? My guess is that deploying all components to individual
clients will give notably better performance. On the downside, that would
imply updating a number of machines every time we add a new or function.or
want to release bug fixes.

I've read a fair amount on remoting, serviced components, and related
functional divisions (a 70-320 prep book, mainly), but have seen little that really ties together when the best situations to use each are.

TIA,

John

[John Spiegel]

Hey Brandon,

Thanks for the insight.

The skeleton's not too far off of the general picture I've been thinking.
Just to make sure we're clear, when you mention interfaces, do you mean (I'm
assuming) the contract that a class must implement or UI? I'll take a look
at the MSCRM.

Thanks,

John

"Brandon Potter" <msnews@brandonpotter_nospam.com> wrote in message
news:ui**************@TK2MSFTNGP12.phx.gbl...

You are already aware of the scope creep and "my God, the code has become so entangled that we have to start over" possibilities of a project like this.
With that said, have you thought about possibly using a plugin-based system for this app? The main app (.exe) is simply a skeleton that defines which
and what order other assemblies are loaded in. If you're not familiar with
Interfaces, you would be well served in the long run to take 2 months and
get comfortable there before tackling it. Ever seen Microsoft CRM? Might
look at that for UI ideas.

Brandon

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:%2****************@TK2MSFTNGP11.phx.gbl...

Hi all,

I'm in the early stages of designing a system that we'll use in-house and

am

looking for opinions and suggestions for further reading on which

directions

to take.

Background: Though we're a small company, I'd like to design this with

the

mindset of a larger company from the start. This will be an ongoing

project

to encompass a lot of needs, which will generally be variations on

standard

themes: Customer account management, billing, reporting and other

fairly common business functions. Most functionality will be accessed from our

LAN

with WinForms-based apps (assume all client machines are Windows running

at

least 2000). There will be some limited Web access for employees, e.g.,
order forms for sales staff. While we may eventually want to build some

Web

services for sharing informtion, the general pulic website will remain
fairly autonomous.

The nature of the company and application is that there will be fairly
frequent releasing of the system, or components thereof.

Current leanings: Most of the functionality will probably APPEAR to be
(from user standpoint) unified under a single app. There are a number of underlying components into which this apparent monolith will actually be
broken. Aside from various departmental boundaries that will make for

nice

conceptual breaks. Utilities, e.g., common dialogs, data access and

account

calculations, will be broken into various solutions. I'm thinking that
there will be a skeleton client app that provides the system navigation,
security and user preferences then uses the appropriate other resources to provide actual functionality.

A lot of my uncertainties are in determining what forms and in what
locations the pieces should be. For example, I'm not clear on whether the core app must reside on the client or may be run from the server. Is it
better to leave the individual dll's on the server, or install in each
client's GAC? My guess is that deploying all components to individual
clients will give notably better performance. On the downside, that would imply updating a number of machines every time we add a new or function.or want to release bug fixes.

I've read a fair amount on remoting, serviced components, and related
functional divisions (a 70-320 prep book, mainly), but have seen little

that

really ties together when the best situations to use each are.

TIA,

John

[Brandon Potter]

John,

Yes, the "contract that a class must implement" is the textbook definition
of an interface...

Let me know.

Brandon

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...

Hey Brandon,

Thanks for the insight.

The skeleton's not too far off of the general picture I've been thinking.
Just to make sure we're clear, when you mention interfaces, do you mean (I'm assuming) the contract that a class must implement or UI? I'll take a look at the MSCRM.

Thanks,

John

"Brandon Potter" <msnews@brandonpotter_nospam.com> wrote in message
news:ui**************@TK2MSFTNGP12.phx.gbl...

You are already aware of the scope creep and "my God, the code has become

so

entangled that we have to start over" possibilities of a project like this.

With that said, have you thought about possibly using a plugin-based

system

for this app? The main app (.exe) is simply a skeleton that defines which and what order other assemblies are loaded in. If you're not familiar with Interfaces, you would be well served in the long run to take 2 months and get comfortable there before tackling it. Ever seen Microsoft CRM? Might
look at that for UI ideas.

Brandon

"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message news:%2****************@TK2MSFTNGP11.phx.gbl...

Hi all,

I'm in the early stages of designing a system that we'll use in-house and

am

looking for opinions and suggestions for further reading on which

directions

to take.

Background: Though we're a small company, I'd like to design this with the

mindset of a larger company from the start. This will be an ongoing

project

to encompass a lot of needs, which will generally be variations on

standard

themes: Customer account management, billing, reporting and other fairly common business functions. Most functionality will be accessed from

our LAN

with WinForms-based apps (assume all client machines are Windows

running at

least 2000). There will be some limited Web access for employees,

e.g., order forms for sales staff. While we may eventually want to build some Web

services for sharing informtion, the general pulic website will remain
fairly autonomous.

The nature of the company and application is that there will be fairly
frequent releasing of the system, or components thereof.

Current leanings: Most of the functionality will probably APPEAR to

be (from user standpoint) unified under a single app. There are a number

of underlying components into which this apparent monolith will actually be broken. Aside from various departmental boundaries that will make for

nice

conceptual breaks. Utilities, e.g., common dialogs, data access and

account

calculations, will be broken into various solutions. I'm thinking that there will be a skeleton client app that provides the system navigation, security and user preferences then uses the appropriate other resources to

provide actual functionality.

A lot of my uncertainties are in determining what forms and in what
locations the pieces should be. For example, I'm not clear on whether the core app must reside on the client or may be run from the server. Is

it better to leave the individual dll's on the server, or install in each
client's GAC? My guess is that deploying all components to individual
clients will give notably better performance. On the downside, that

would imply updating a number of machines every time we add a new or function.or want to release bug fixes.

I've read a fair amount on remoting, serviced components, and related
functional divisions (a 70-320 prep book, mainly), but have seen

little that

really ties together when the best situations to use each are.

TIA,

John

[Kapil M]

Not sure if you have the luxury of a 3rd party option , but in case you do ,
salesforce.com offers a good package which offers support for custom stuff.
its expensive but solves a lot of issues.

-kapilm
"John Spiegel" <js******@YETANOTHERSPAMHATERc-comld.com> wrote in message
news:#w**************@TK2MSFTNGP11.phx.gbl...

Hi all,

I'm in the early stages of designing a system that we'll use in-house and am looking for opinions and suggestions for further reading on which directions to take.

Background: Though we're a small company, I'd like to design this with the mindset of a larger company from the start. This will be an ongoing project to encompass a lot of needs, which will generally be variations on standard themes: Customer account management, billing, reporting and other fairly
common business functions. Most functionality will be accessed from our LAN with WinForms-based apps (assume all client machines are Windows running at least 2000). There will be some limited Web access for employees, e.g.,
order forms for sales staff. While we may eventually want to build some Web services for sharing informtion, the general pulic website will remain
fairly autonomous.

The nature of the company and application is that there will be fairly
frequent releasing of the system, or components thereof.

Current leanings: Most of the functionality will probably APPEAR to be
(from user standpoint) unified under a single app. There are a number of
underlying components into which this apparent monolith will actually be
broken. Aside from various departmental boundaries that will make for nice conceptual breaks. Utilities, e.g., common dialogs, data access and account calculations, will be broken into various solutions. I'm thinking that
there will be a skeleton client app that provides the system navigation,
security and user preferences then uses the appropriate other resources to
provide actual functionality.

A lot of my uncertainties are in determining what forms and in what
locations the pieces should be. For example, I'm not clear on whether the
core app must reside on the client or may be run from the server. Is it
better to leave the individual dll's on the server, or install in each
client's GAC? My guess is that deploying all components to individual
clients will give notably better performance. On the downside, that would
imply updating a number of machines every time we add a new or function.or
want to release bug fixes.

I've read a fair amount on remoting, serviced components, and related
functional divisions (a 70-320 prep book, mainly), but have seen little that really ties together when the best situations to use each are.

TIA,

John