[almighty] Architectural Considerations: User based setup (Configs, Wizards, Code)

[Miroslav Hradilek]

Hello,

this is the first of my emails where I will be sharing my thoughts on 
some design decisions that, in my opinion, are worth considering when 
designing ALM architecture.


# User Based Setup

So in most applications, and especially ones like ALM, there is a big 
need for customizing everything like objects, behavior etc.

It is mostly done in three ways:

1. Via dedicated UI forms, wizards and DSL
2. Using configuration files
3. Customizing it in application code


I've personally had a chance to use all three ways throughout my life 
and I'm sure the readers are the same. All the methods have pros and 
cons. Some depend on licensing and their application depends on the 
skill set of the user.

# Approaches

1) UI etc
This is by far the most consumable method for not very technically 
skilled people or people not willing to invest in learning the 
application. The sole configuration form is like reference documentation 
and configuration files combined. Even higher level of contextual 
configuration can be achieved by employing wizards which interact with 
the user until the configuration is finished.

The downside to this is that it requires the application developers to 
burn time to code often quite complex forms. Sometimes the expression of 
such form is quite limited and Domain Specific Language must be defined 
to overcome this lack of expression. Example being the languages 
describing mail filters, query languages etc.

After some time the user learns a lot about the application and these 
interfaces start to limit his/her efficiency.

2) Configuration files
Somewhere in between. You do not have to be a coder to configure 
application this way.

What you have to do though, is to read quite a bit about the application 
and have a reference documentation at hand. This can be minimized by 
including the documentation inside template configuration files in form 
of comments. The expression is quite limited. Difficult data structures 
and Domain Specific Languages must be used to overcome this problem.

3) Hacking the code
You need to be involved a lot in the application and you have to 
understand it's code in order to modify it.

The expression is virtually unlimited though with little effort on 
developers side. No config interpretation code and DSLs are necessary. 
This can be improved a lot by splitting the configuration part of the 
code from the system implementation structuring the code as a 
configuration file. If you include documentation in comments you have a 
nearly commented config file experience but you still require the user 
to be quite involved in the app and know at least basic data structures 
used in the language.

The biggest downside is that the app often (not necessarily) needs to be 
rebuilt to perform a change. Second most severe limitation is that 
closed source applications would be difficult if not impossible to 
configure this way.

# How to choose

There is one important consideration, sometimes overlooked when deciding 
which style of configuration to employ. Apart from time money and 
developers personal engagement. It is the TARGET AUDIENCE.

Who will be configuring which part in reality? How involved are they 
going to be in the application when in production? What are their use 
cases? Are there any security implications if I choose this over that?

These are some of the questions you should consider. And please do 
expand on this. I'm sure you will have some more options to consider.

-- 
Miroslav Hradilek
Quality Assurance Engineer
Base OS Quality Engineering

Red Hat Czech, s. r. o.
Purkynova 99
612 45 Brno, Czech Republic