Things to address in enterprise application
Moderator: General Moderators
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
Things to address in enterprise application
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.
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.
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..
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..
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
thanks for your reply.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..
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.
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.
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.
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.
(#10850)
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.
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.
- Ollie Saunders
- DevNet Master
- Posts: 3179
- Joined: Tue May 24, 2005 6:01 pm
- Location: UK
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?
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?
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
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.
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.
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
- raghavan20
- DevNet Resident
- Posts: 1451
- Joined: Sat Jun 11, 2005 6:57 am
- Location: London, UK
- Contact:
- Kieran Huggins
- DevNet Master
- Posts: 3635
- Joined: Wed Dec 06, 2006 4:14 pm
- Location: Toronto, Canada
- Contact:
"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.
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.
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
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.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.
(#10850)