Thinking about Enterprise Platform Constraints
I mentioned that I hate aimless bitching before, and I have been doing that for a while about Microsoft CRM. I would still like to lob the GoF, the PoEA and the AntiPatterns books at the team responsible for the CRM, but the new goggles are wonderful, it barely hurt at all. *
Just to be clear, and for Scott's peace of mind, I don't have any intention to build Rhino CRM. That is beyond the scope of my interest. That doesn't mean that I can't amuse myself by thinking out loud the ideal architecture for such as system as far as I am concerned.
I have been accused that the hypothetical Rhino CRM would offer a slick interface to create new customer, just have the end user write an anonymous delegate to do so. It was funny at the time, but I am actually considering doing just that.
At any rate, before I can think up an architecture, I need to understand what the constraints it needs to meet. Of the top of my head, I can see the following:
- Extensible in an easy manner - note that this holds for business analysts and for developers, both are groups that are likely to do work on the system. Ideally we can have some sort of a common interface that would make both people happy.
- New entities
- User Interface:
- Forms
- UI elements
- Editing existing forms
- Replacing core services
- Upgradable - We want to allow the users to move from version 2.0 to 3.0 without having to re-write everything. This means that we need to make clear what we allow the user to do to the system if they want to have a successful upgrade.
- Auditable - I don't suppose that I have to explain why, right?
- Performant - well, it should. Considering the other contestant, that could be a major selling point.
- Scalable - I want to be able to scale wide, so the CRM can scale as I add more servers.
- IT friendly - not sure what this means, Windows Authentication? Monitoring support?
The two major hurdles are going to be the first combined with the second.
What other considerations and constraints do I need to consider?
* I still hate it that I have to develop a full blown framework just to get a half way decent programming experience. Well, at least it has boobs in it. Some of the team members caught on to that, and hilarity ensued.
Comments
Here's some more:
Secure - Duh.
Open/Allows-for-Integration - provides services to input and extract data both in small and large chunks. Side bonus: This would allow for some easier testing too!
Platform independent (sort of) - Runs on multiple DB's. Maybe runs on multiple OSes (some Fortune 500's have Unix fetishes)
Hostable (optionally) - can be run in a datacenter, can have multiple instances on a single machine securely
Secure - absolutely.
Integration points - yes.
Platform independent - not a concern I am worried about. If they would really like it, they can run it on Mono.
Hostable is not really key, but several instances per machines is critical to allow a developer to work on more than a single app at a time
So when does Iteration #1 start?
This might fall somewhere under "IT Friendly":
Data/Plugins/Code needs to be easily migratable/promotable from Development to Test to Production (or whatever staging setup an organization has).
I know my Production and Test environment are exactly the same (except for the data)... aren't they?
DLL Versions? Script Source Code
I'll back it up to a file, import it onto a new server. Change a few settings like hostname and connection strings and have a clone site for whatever nefarious purposes.
Well, as much as possible anyway :-)
Easy Backup/Restore process
Customizable - think about the layout
Hate to sound like a MS CRM fanboy, but I'd argue that except perhaps for the auditability-department, MS CRM scores very good marks on all points mentioned in the original post...
Michael,
Please check my previous post about MS CRM.
It goes into great details about why it fails in all of this accounts.
Comment preview