The most useful advice that I can offer is that if you have someone in charge of overall design without experience, then you are guaranteed to make several of a large selection of common mistakes. Having a few answers to questions here is not going to be a substitute for experience. However actually making the mistakes while trying to learn and get feedback might give you the experience for a
future project, so whether making those mistakes is a Bad Thing kind of depends on your perspective...
If you want to learn more, then I would suggest some project management books. I am a fan of Steve McConnell, and I like some of the stuff that the Agile Software folks have come up with. (Particularly their point that process is overhead, and the need for that overhead varies directly with the size of your team. Smaller teams should aim for less...)
Answering the questions despite the fact that I suspect that the answers will prove somewhat useless...
- Since we have business rules should the architecture of the system
have middle-ware? The presence of business rules does not mean that you need officially separate middleware. But middleware may make sense depending on what you are doing. My inclination if you don't have experience, however, is to try to avoid middleware simply because it complicates your understanding of what is going on, and you are going to tend to confuse yourself a lot anyways.
- And if we will have middle-ware does the architecture have to be N-tiered? Well having a seperate middle-ware layer does suggest that you have an n-tiered system already.
- What languages should the middle-ware be written in? Whatever languages make sense for the team chosen, tools used, and protocols spoken. If you are using a proprietary pre-built piece of middleware, then you probably want to use whatever language is native to it. Otherwise you have more flexibility to use what you think will work best.
- Would the middle-ware contain the business objects? It can and often would.
- The original "developer" implemented the business rules in PL/SQL and triggers.
Is this a bad thing? I wouldn't lean towards that choice. I like avoiding stored procedures because they tie you tightly to the specific database, create deployment complications, and PL/SQL is far from my favorite language. However they can offer significant performance benefits, and some people like factoring the logic that way.
- I feel that our "team" should only be responsible for the back-end
and the middle-ware so do we need to be concerned about client/model views? Somewhat. You need to be aware of what the people using your stuff need from you, and you should be aware that many major hidden performance problems come because people building views repeatedly call back to the backend for pieces of data, when you could just call back for bulk data once. (Repeated queries for each item of data loses the automatic algorithm optimizations which are your reason to use a relational database - classic error!)
- Is the back-end basically a data warehouse and when combined with the middle-ware does this constitute a data mine? No. See an introduction to data mining to discover what it is.
- Should the business-objects contain the SQL to extract the data and manipulate it,
then store that resulting data back to the database, or should the business objects call
store procedures to do this? In a large system I would be inclined to factor the SQL out. In a smaller system you might do it either way above, or use any of a number of object/SQL mapping techniques.
- I am using terms correctly? Most of the time you aren't saying anything to indicate otherwise. That doesn't mean that you don't have some major misunderstandings which are simply not obvious from how little you have said.
- What is a Business Rule? Hmm, perhaps you don't know these terms so well. :-P Business rules are somewhat arbitrary restrictions that you have to meet for business reasons. Things like, "Only some people can see X" or "This calculation does not happen until the purchase is final." Generally they will turn out to be exactly the choice that makes your life as hard as possible. :-)
- What are client/model views? Pieces of a common design pattern known as Model-View-Controller.
- What is a data mine and a data ware house? A data warehouse is pretty much whatever people declare it to be. ;-) A data mine is a data warehouse with some sort of "intelligent learning" functionality in front of it to make it easier to get useful information without excessive human work.
- And last but not least what set of documents are typical for a small developement team that is developing a N-tiered system? Um, what does small mean to you? 2 people? 5 people? 20 people? It is all a matter of perspective. (See some of the agile software books for an idea of what documentation different sized groups have gotten away with in the past.)
As for selling your boss on Perl, well convince your boss that Perl is the right tool for the job. Perl's big wins are good productivity levels and CPAN. Big wins for its competitors will be pre-built PHB-friendly pieces, more possible employees, and language-support to help limit the amount of foot-shootage. (Perl's attitude is definitely more that people won't shoot themselves in the foot because that hurt last time...)
If the decision is that Perl isn't right for the job, then you need to make your choice between grinning and bearing it, versus finding a job you would be happier with. My suggestion is that in this economy, a paycheck is worth a lot. My further suggestion is that it is worth exploring other languages, if only so that your advocacy of the ones that you like can be more grounded in experience than fear of the unknown. (And who knows, you might discover things you like about languages you feared learning about!)
Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
Read Where should I post X? if you're not absolutely sure you're posting in the right place.
Please read these before you post! —
Posts may use any of the Perl Monks Approved HTML tags:
- a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
| |
For: |
|
Use: |
| & | | & |
| < | | < |
| > | | > |
| [ | | [ |
| ] | | ] |
Link using PerlMonks shortcuts! What shortcuts can I use for linking?
See Writeup Formatting Tips and other pages linked from there for more info.