Configuration parameters - In database or in config files?

Every application either accicentaly or by design, ends up having some system configuration parameters in the database and some in the configuration ( .ini or .xml or .config) files. But where are they better placed?

Lets look at config files:

• If the application uses databases, the database to connect to must be there in the config files, so this cannot be eliminated.
• There are some environment properties (outside our applications) which the runtime reads from the config files. they cannot be moved to database as well.
• Its usually easy to edit config files using any text editor.
• Its easier for development as it doesnot require any infrastructural code to read these parameters from the database.
• It is easy to distribute these.
• In the case of clustered application, the same parameters need to be synchronised to all nodes in the cluster.
• There are chances of making a mistake while editing it.
• In case there are multiple environments, maintaining different files with most common, but some different values is cumbersome.

Now lets look at databases.

• In case of changing a parameter in a cluster - we need to do that only once. 
• We need to write a small piece of code to efficiently load these values from the database, and keep them in memory for future use.
• We could allow for dynamic update of these parameters, but there would be a lot more code if this needs to be cached and all.
• We can provide an interface for users to change these.
• These parameters are easier to change and maintain as one change reflect in all machines.
•  In case of multiple environments, we could keep the parameters on these servers, and these parameters will not be affected when a new application deployment happens.
• For adding new parameters, SQL scripts need to be created for all environments.

So what does it mean? Which way to go?

In my experience, I prefer to keep as much in the database as possible, leaving in the config files only those which are inevitable, like the Database connection string, session parameters etc.

I also tend to have a simple application which can be used to maintain any set of name value pairs - which we use for editing the database.

How to be an architect?

I have answered asked and deliberated this quite a few times, and I am trying to put together my thought on it. I hope this puts some sense into this loaded word.

IMHO, an architect brings to the table an ability to make or assist technology and platform choices which let business achieve its core objectives.

Apart from this, an architect is also expected to understand and communicate to different stakeholders ( be it ISP who you are supposed to chose the bandwidth package on behalf of the client, be it OOAD expert modeling the system, be it project sponsor who has to make choices and compromises).

Deliverable of an architect is a partitioned view of the system, with technologies / products and other basis or constraints of these partitions.

Let me elaborate these points by examples.

Sometime back, a manager at a forward looking financial institution got a brilliant idea for a new product / service the bank could sell. The management gave her a small budget and a time of 6 months to prove that the concept works, it sells and is profitable by doing a pilot. So when she approaches an architect, the architect needs to be able to understand ( possibly by questioning) that the application needs to be low budget/low time. Scalability and maintainability and other goodnesses could take a back seat here. The architect needs to explain to the Business owner that - in case the product is successful, the application will require to be re-built before it could be put to a bigger use. In this case a so called poorly designed application is the best architecture. The Architect also needs to be aware of ( or need to hunt for) any COTS ( commercial off the shelp product) which could fit the need and the budget, instead of proposing a custom development.

Now lets take a second scenario. Lets say a Startup approaches an Architect. One of the business objectives of the Startup is to maximize the capital value of its IT investment, as it is likely that they would like to be acquired. Now as an architect, you are expected to propose leading edge technology which creates a product better than what is out there in the market. which covers all the basic definition of a good software of scalability, maintainibility, security, availability and the works. It should possibly avoid product and components which restrict the sale of the same or make it prohibitively expensive to scale.

Now lets take a case of a product which operates as a software factory - having a common code base but certain client specific customizations which are also to be maintained. In this case, testability and maintainbility become important.

Now coming to HOW does one become an architect?

An architech needs to be able to do rough estimations - so that a proper granularity of partitions could be achieved.

An architect needs to be able to gather Non Functional Requirements  and apply them ( like the examples above)

An architect needs to have or to be able to get opinion on different technologies and product options (whether they are mature, whether they are used, is support available, which products are available, which are popular). This usually comes from networking, googling, experimenting and /or by sending out RFI to the vendors.

An architect needs to have a background of application design, so that he/she is able to convert the partitions and their responsibility definition into concrete specifications and interface contracts - possibly with the help of application design experts.

An architect needs to have some background on performance tuning and application load testing.

An architect needs to have understanding of different software and hardware ways to enable application scalability and availability, and cost / compromises required for each of the options.

So in short:

Get involved in “technical” and non functional requirements gathering.

Get involved in deployment planning and deployment (and possibly on-site application support) and figure out the concerns datacenter support teams have and their stake and interest in the applications.

Get involved in estimation and figure out how an application development is broken into individual tasks which can be expecuted.

Get involved in design.

Get involved in performance testing and testing of non functional requirements.

If you are reading this, its likely that you are already doing one or all of the above. If so, probably you already are an architech and all you need to do is to figure out nice document templates to put content in.

I recommend two places to look at: http://www.opengroup.org/togaf/ and http://www.rgoarchitects.com/saf/
The latte, being created by a single person , is more practical.

Packaging - what developers dont do while creating installables.

Did you know that there is an industry out there which specializes in creating installers in which silent install works- using the installers provided by developers? I was blissfully ignorant about it, though designing an installer has been a part of my job description for ages.

An example of such a product is http://www.altiris.com/Products/Packaging.aspx

So what is wrong with the default installers?

Developer productivity

We all - at many points in our lives - try to improve the efficiency with which we execute projects. Most of these fall under the following categories: Quality processes, Execution /project management methodologies, design efficiencies, coding efficiencies, reuse, testing and debugging efficiency, and reuse of knowledge.

Logginge Wows and Voes

Those old enough will recogonize the two mehods ( PrintError and PrintDebug) which we would have in each application we would write, which in turn will have something like

If(debugEnabled) printf(message).

In production, we would only have error logs as the synchronous

Then we discovered loggers -

OR mapping - opinion and issues.

One of the biggest architecture decision which stares us on our face is whether to use OR mapping or not. The arguments in favour are very convincing, but does it apply in all scenario?

Layers and Tiers

Software architects are a confused lot. Communicating with each other is a challenge. There is always a discussion about what goes in what layer ( or tier) and logical vs Physical separation. Even the definition of Data Tier specially is open to interpretation.

Arnon is the first person I saw calling (potential) physical separation as Tier and (Definitely) logical separation as layer - and I believe its a good separation to have in our vocabulary.

Component or service?

Every few days, in one forum or the other, I see the question “How to choose between a component and a service” or “shall I make this module a component or a service” or some variation of it. Is there a simple answer?

Navigation, Ads, Site stats and custom messages for co-branded sites

In this post, I will explore how to handle Navigation, ads etc for co-branded sites. Next post will be a concluding post in this series on how content management (WCMS) delivery systems fare in this respect (After all, their job is content re-positioning).

Branding Application Continued..

In the previous post on this topic, I talked about simple ways of branding application or content pages. Sometimes, however a much higher level of customization is required.

This is usually handled in one of the two popular ways of doing this-  Having custom templates, and having a separate UI layer hosted either by customer or service provider.