Architecture with database

Hi, not sure whether this is the right forum for this question, but I would like to ask if anyone knows a good source of information for making decisions about overall application architecture. I am in a situation where the hardware is decided, but we need to purchase all the software (Application/Web server, Database and development tools). I need a place to start to formulate some criteria and means of objective assessment. Does such a source of information exist? If so, where can it be found?

There is a stack of information available of the web, but trying to wade through it and filter it is proving to be a nightmare. i need to make some decisions and need some guidelines.

Thanks for your help

Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


It is hard to specify an application architecture that fits all application kinds. The right architecture for an application is determined by balancing all sorts of product requirements and parameters for the project.

Try answer the following questions:
1. How many developers are dedicated for this project, what is their skill set? Do they have any previous J2EE development experience?

2. What kind of clients does your application require to support: web clients/ mobile clients / other clients?

3. What are the three most common user actions in the system (i.e: login, check-balance, prodcue report).

4. What is the schedule for the project?

5. How many concurrent users does the application require to sustain?

6. What is the chosen hardware for this project?

7. Is the application requried to be available for 24*7

8. Does the application has to contact a legacy application?

9. What kind of security requirements are there for your application?

I doubt there is a tool that can measure all these params for you, but ill try to help.. :)


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial

1. Defining the technical models ::>>

Remember that one of the purposes of architecture is to provide guidance to decision making. When an application is being built, there are many decisions to be made—one of the most important is the overall technical design. The technical design is created after business requirements are generated, but before the detailed design and coding work begins.

If you look at all of the various applications today, you can start to categorize them into application types, or models. Let’s think about a large company that has over 200 separate applications. Regardless of the specific type of application and the type of data that is processed, you should notice a handful of application types. This might include Web applications, data warehouse applications, decision support applications, transaction processing applications, and reporting applications. You will also notice that certain types of models work better for certain categories of business requirements.

For instance, you might see that a Web application is better for external customers to order products from you. On the other hand, if you have an accounts receivable system processing 50,000 transactions a day, a Web application might not be the right one. Likewise, business requirements that call for the storage and retrieval of millions of customer order records might point out the need for a data warehouse application, rather than a traditional client-server application using normal database processing.

You don’t want to be in a position where you have chosen the wrong platform and software. Many times you won’t realize this until you start to do heavy systems testing, or worse, when the application goes live. That is way too late to have to rework fundamental technical design decisions. Development architecture can help by providing guidance as to the type of application that should be built, based on the business requirements.

2. Rationalizing the existing application portfolio :: >>

The third feature of development architecture is to understand and categorize what you already have. It might be surprising to know how many companies really don’t have a high-level picture of every application in their company. It should not be a surprise then that companies end up redeveloping similar software multiple times.

A few years ago, I worked at a large beverage company. We had just gone through a major reorganization in the IT development organization. In the past, we had been organized based on the various business units—finance, marketing, sales, etc. But after the reorganization, for the first time we were organized by business function. The difference in organization structure highlighted major redundancies in our business application portfolio. This organization allowed us to see that we had three major manufacturing systems in use. We also had multiple financial systems, marketing systems, and sales systems. Each sales system was unique to a particular business unit and the type of products they sold. From all accounts, this was a very inefficient use of company resources.

The major step in development architecture is to take an inventory of all the business applications that exist today, as well as any that are in progress. This sounds simple, but it can be a huge effort for a large company. You must first be very clear on what constitutes a business application. The ones supported by the IT development organization might be simpler to identify. But what about all of the applications that are created by business users, as well as the applications that are within IT, but managed and supported outside the development department? You must first decide the scope and definition of the inventorying process.

Next you must determine what information you want to collect on each application. There are many obvious characteristics, such as the purpose, the client base, the types of data processed, and the technical environment. However, there are literally dozens and dozens of pieces of information you could collect. You want to determine the information that will provide the most value, that is easiest to capture, and that will not require a huge process to keep up-to-date.

The application inventory is used for two main purposes. First, you can look for opportunities to rationalize wherever possible. One way to rationalize is to look for redundancies—that is, different applications being used for similar needs. For example, you may find two customer relationship management (CRM) packages in use. Further follow-up may reveal that you can standardize on one package.

You may also discover that you have development products used only by a small number of applications. For example, another company I worked for realized they had only one application using an older database. This visibility allowed us to expand an already planned enhancement project to convert the application to the standard database.

3. Rationalizing application inventory is an ongoing process :: >>

You don’t make major decisions to retire duplicate applications and older technology in a short timeframe. In fact, in a large company, you may need to look at a five-year plan to get to a more rationalized application environment. You may even decide that you cannot make a business case to eliminate all the inefficiencies. But this aspect of the development architecture at least gives you the information you need to make appropriate decisions.

The second purpose of the application inventory is to map requests for new development against the current business applications. This can be done as a part of the project approval process. When business clients are looking to build new solutions, they can refer to the development architecture to see if something similar might already exist. The people who are making funding decisions can also see what the new projects are, what business processes they relate to, and what applications exist in that space already. They can catch obvious duplications and ensure that redundant applications aren't funded.

4. More effective and efficient :: >>

As companies get larger, the chance increases that development decisions will be made that lead to an inefficient use of company resources. Development architecture can help by providing guidance into the development process at three key areas. First, the development architecture shows you the best development life-cycle approach for the initial development project. Second, the development architecture shows you the best technical design model you should use based on your business requirements. Third, the development architecture gives you visibility into all the applications in place and in progress, so that you don't reinvent a business application that exists today. All of this guidance allows the development work that is approved to proceed more effectively and efficiently, with as little rework and redundancy as possible.

i hope it may help you
Best of luck..


marianna6000Author Commented:
Hi Rama,

Thanks so much for the useful information.  
One of the most important things that I need to consider is ability for rapid development because we have a backlog of work and a small department. We do not want to be the bottleneck in getting things done.I am revamping a web application and forming the basis for future development. Just to give you an idea of where I am at, I am debating whether to implement Oracle or MS SQL Server as a foundation database. We have J2EE developers who are familiar with Oracle at present, but Ms SQl is much cheaper, and I understand it is relatively easy to learn. My preference is for Oracle, any thoughts? This way I would have an entire suite, application server and development toold that are integrated with J2EE already. Not very familiar with .net but been doing a lot of reading, and like what I have read (except platform restriction). We have existing Oracle applications in other countries and it would be nice to be able to integrate with this easily. Any helpful thoughts or comments on this would be appreciated.


If your thinking about rapid, blitz project go for Tomcat as your server (it does not support EJBs but you can manage very well without those).
If budget is tight, you can do your development with Eclipse, an open-source IDE that has great plugins for working with Tomcat, JSPs an such. If  you have some dollars to spare go for IntelliJ as your IDE, it has good Tomcat support and it is (IMHO0) the friendliest IDE around.
Also, you can manage with mySQL which is a free database as far as i can recall.

It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Application Servers

From novice to tech pro — start learning today.