Page 1 of 1

Things to address in enterprise application

Posted: Wed Feb 14, 2007 4:41 am
by raghavan20
All of us know developing enterprise or large-scale applications is difficult. There are many things to be addressed. Most of the things should be just right from the beginning of the project or we would be wasting a lot of money and effort later on.

I am interested in finding out the things that are to be addressed in the development of large-scale application such as database connections, security, etc. Thanks.

Posted: Wed Feb 14, 2007 5:33 am
by timvw
Afaik, most enterprises require you to sign a non-disclosure clause so it's hard to talk about things you know/learn.. Anyway, here are a couple of general thoughts:

Most configuration settings (enterprise-wide) come from one (logically) central 'configuration repository' where client can request connection strings, resource urls, ... Depending on the domain they want settings for (development/test/quality/production/maintenance), via an application config file that is written at install time, they will receive different data.

Users and groups are managed via ldap (active directory) and active directory federation services (for external users and groups). Depending on the application there is a (large set) of other management tools too..

Posted: Wed Feb 14, 2007 5:48 am
by raghavan20
timvw wrote:
Users and groups are managed via ldap (active directory) and active directory federation services (for external users and groups). Depending on the application there is a (large set) of other management tools too..
thanks for your reply.

is this something like identity management systems, where authentication is done by one central system for all other applications? in such case, how do you communicate with ldap? i am do not have much knowledge in making applications communicate apart from Web Services and cURL.

Posted: Thu Feb 15, 2007 9:17 am
by obiron
My main tip would be to get data mapping correct and make sure your tables are normalised. Even if you don't need it now, it makes life a lot easier later on.

E.g.

You are storing product records. You could store the product description in the same table as the product but you are actually better off creating a table for product descriptions with a langage code and product ID as an index. If you are using OOP then getting the correct description is no harder than it would be for having the data stored in the main table.

Also, NEVER EVER EVER use information that the user may want to change as the primary key. In the above example of products, do not use the product code as a primary key, build your own internal reference and use that. It makes the SQL joins and results more complicated because you will nearly always want to report the product code as a key (and use it for search inputs). If you do make this mistake and then the company turns round and says that all their product codes now have to comply with EU standards, the number of tables and queries you have to update becomes a nightmare.

Posted: Thu Feb 15, 2007 2:39 pm
by Christopher
It is my experience that the main differences that distinguish "enterprise" applications from, I guess, "non-enterprise" apps are that enterprise apps frequently (not always ;):

1. interact with existing systems (i.e. not green field),

2. have larger development teams,

3. have older style, less effective, more formal design and management imposed upon them.

4. are more focused on profitability and client retention than things that programmers are interested in.

None of those things are specifically technical in nature so many of the difference are people, not code, related. There are common ways to deal with these (e.g. 1=OR/M, 2=CVS, 3=Agile, 4=Dilbert) but dealing with people is much more difficult than dealing with code.

Posted: Fri Feb 16, 2007 11:51 pm
by DrTom
Things to look out for

1) Many time you'll be developing on servers that do not have a ton of extensions installed, use old versions of php,etc...
And upgrading a production server is a pretty monumental task in most coorperate environments. This can cause major
delays if it's not given the proper attention. My advice is don't assume or take someones word on this, find out what the production box is, login and
find out what you need to know. If you don't, it can cause absolute nightmares later down the road.

2) Tight deadlines leading to lots of "// UGLY HACK" all over the code. Every developer always swears "I'll never do that", yet I've never worked with one who hasn't.
This usually comes from a lack of a proper requirements document or just plain old poor design in the early development stages. At the very least, the requirements
needs to be absolutely set in stone before production can begin. OF course, even if they are "set in stone", they will undoubtedly change anyway, so try to keep
that in mind.

3) DBA's are slow. Plan your DB and make your requests to the proper people to get those tables up on Dev/RC/Live servers as soon as you can. DBA's have a lot
of databases's to manage and your tables may have to wait, and nothing sucks worse than being ready to push to RC for testing and not having the tables.

4) Reporting. Whether they tell you they want it or not, the business side of the company will want a report on every single piece of data your application interacts
with. Keep this in mind.

5) Remember that you are working for profit. If you spend 12 hours perfecting code on a feature that makes the company $3 a year, no matter how cool or clever the code is, you wasted 12 hours(unless you are even more underpaid than the rest of us).

6) Proper management of SVN/CVS/whatever. It's of paramount importance that these things be managed properly otherwise it'll just become a nightmare preparing releases. The larger the team, the more important this becomes. The memories are painful. The project leads needs to set guidelines on this, and developers need to stick with it.

Posted: Sat Feb 17, 2007 5:18 am
by Ollie Saunders
And at least 90% of them fail in the sense that they go over budget, past deadline, or fail to be useful because something has changed by the time they are delivered.

I'd like to think that writing MASSIVE applications is a thing of the past. Clearly they can't adapt to change and are incredibly risky, why would anyone want to do that?

Posted: Sat Feb 17, 2007 6:57 am
by raghavan20
Thanks for your replies guys.

I notice that everyone is writing more on project management including team members and project and liasing with high-level management. Good to know about these, but I would appreciate if you could shed some light on technical complexities such as database access, transaction control, security, scalability (ability to serve many users at the same time), extensibility( adding of more and more functions to existing application ), refactoring including performance enhancement, reusability, ability to communicate with other internal applications, etc.

Posted: Sat Feb 17, 2007 11:43 am
by Kieran Huggins
You could make life easier and deliver your app as a VM - that way it can be virtualized within existing systems and you control the feature set AND possibly also the DB.

Posted: Sat Feb 17, 2007 1:19 pm
by raghavan20
Kieran Huggins wrote:You could make life easier and deliver your app as a VM - that way it can be virtualized within existing systems and you control the feature set AND possibly also the DB.
what is VM? could you explain in detail your post? Thanks

Posted: Sat Feb 17, 2007 2:52 pm
by Kieran Huggins
"Virtual Machine" - google VMWare for more info - virtualization is pretty quick these days, often at something like 95% efficiency.

The basic idea is you give them a stripped down server disk image with everything you need and nothing you don't pre-installed and ready to run. Then they "boot the server" inside virtualization software like VMware or Bochs or Xen (or whatever) and *poof* instant network service.

It's a great way for you to distribute server software in a controlled environment, and it's a great way for companies to leverage existing, underused resources.

RPath is worth googling as well.

Posted: Sat Feb 17, 2007 9:05 pm
by Christopher
raghavan20 wrote:...but I would appreciate if you could shed some light on technical complexities such as database access, transaction control, security, scalability (ability to serve many users at the same time), extensibility( adding of more and more functions to existing application ), refactoring including performance enhancement, reusability, ability to communicate with other internal applications, etc.
I can't think of anything within the application code that I would do differently. Most of the things in you list would be handled by best practices. And those that aren't, like maybe scalability, would be handled outside the application -- like distributed sessions or a front-end load balancer. That's very much the PHP style to let other standard systems do what they do best, sort of transparently to the application.