Guy kolbis

In my previous post "Design Decision: Where to place the admin for your application" I have explained a design decision I had to take. Generally, I was looking for a solution on where to build my application administration.

Alik Levin, suggested that the administration should be placed on a different process (application) from the main process (application). His main motivation is security.

I must admit, usually I would agree with Alik, however there are several more considerations that we must take into account before making a decision:

• Target - Who will use it? Is it for internal usage?  If you will need it for internal usage or for internal engineers, just select the quickest way possible, usually several utils wil do the work, but remember to remove all trace of those feature when deploying the application.
• Type - Is it a product? If so, you need to think about the long run. Think about the administration the same as you would for any other application. I would suggest a different application  that will encapsulate all admin operations.
• Security - Are you building a secured application? Do you consider security as an important aspect? If security is a must, surely you would want to decouple the application from its administration, thus two application must be created, one for the client and another for the admin.
• Connectivity - Do you need the admin to connect the client (to clear the cache, for instance)? If so, it is far more easy to create the admin as a module within the application; You simply gain more control of the features and the connectivity between the client and the admin is high (good). However, if given the time, it is possible to achieve just that event if using two applications. So, if you have the time, using two applications would be better, otherwise a single application is easier.

• Time Budget - Do you have time to build new application? Do you need to build new infrastructure for the admin? Can you reuse the infrastructures? How complicated it it? Can you do it quick and dirty? This is T-H-E question.

Summary

As a thumb rule: Two applications, one for admin and another for the client.

However if you do not have the budget, ask yourself: what is the penalties for not separating it? Think about the long run.

So, in the past month I have encountered several definitions on what is an Architect. I found that each one of them had a portion of the truth, but still there was something missing...

Today, while browsing MSDN, I encountered with, what I believe is the closest to a definition yet for Solution Architect:

"The name solution architecture is sure evocative of the big picture. When you think of a solution, it includes the hardware, software, and supporting people and documentation to solve a problem. Solution architecture starts with an understanding of the problem—a really deep understanding—and this is where so many projects fail. Too many people have the idea that solving a problem is all about coding. The coding is the easy part, compared to the contemplative effort that is required to gather requirements, envision the solution, evaluate the options available for the solution, perform the time/people/resources trade-offs, design the solution, and then communicate all of this to the developers."

For me the important points are:

1. Seeing the big picture.
2. It is not only about the code.
3. Gathering requirements.
4. Designing a solution that will best fit the time, people, resources and requirements.

One thing that is missing here in my opinion is the "People Person" and "Politician" qualities. A solution architect must be a person with the capabilities of building a solution that everybody excepts (even if they do not know it) and wants to help getting him there. In order to do that, sometimes the architect must be a really good politician... :)

What do you think?

You can read more about it here.

Most application I know require some sort of administration. It does not matter if this is a desktop application or a web site, you must be able to perform administrative tasks, for example: creating new users, creating role, setting security and etc.

Having said that, I was facing a design decision:

"Where do I want the admin features to reside on?"

"Does the admin features will be a module in the (same) application?"

"Do I need to create an admin application?"

""Do I want a separation between admin and application"

Just to make sure we are on the same page, I was trying to decide whether I want to create a different application for the admin features or placing those feature on a module within the main application.

So, I have a question:

What would you do and why?

(Explain your considerations)

I have selected the way that is best for my case, however it is important for me to know what would you have done. I will post later on, my design solution.

Did you know that in order to operates YouTube, all you need is:

• 2 System Administrators.
• 2 Scalability Architects.
• 2 Developers.
• 2 Network Engineers.
• 1 DBA.

Total: 9 people.

A-M-A-Z-I-N-G ! ! !