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

[Pete Muir]

The other thing to think about here is "infrastructure as code",
particularly in relation to continuous delivery.

How would someone be able to store the ALM configuration in a source
control repo, and make changes to the running instance using
continuous delivery and at the same time support non-technical users
in making changes (such as the UIs that Miroslav discussed).

I think this is definitely a scenario we should support, given our
focus on supporting companies wanting to use CD/pipelines.

On 27 July 2016 at 08:48, Konrad Kleine <kkleine at redhat.com> wrote:
> Hi Miroslav,
>
> thank you for sharing your thoughts on these three ways to customize an
> application:
>
>> 1. Via dedicated UI forms, wizards and DSL
>> 2. Using configuration files
>> 3. Customizing it in application code
>
>
> I believe that 1. and 2. have a somewhat symbiotic effect. Let me try to
> explain what I mean by this:
>
> I think there's the act of customizing and then there is storing of this
> customization. The later can be a configuration file format (e.g. JSON) with
> DSL inside. We use PostgreSQL as our database and this can store JSON as
> native objects. The pure act of customization on the other side can be
> either writing these JSON files by hand or manipulating them using a UI.
>
> I may be naive but I think the benefit of having a configuration file format
> allows for customization right from the start. A UI can be added later (that
> is probably the naive part).
>
> Regards,
> Konrad Kleine
>
> Software Engineer
> Red Hat GmbH
> Werner-von-Siemens-Ring 15
> 85630 Grasbrunn, Germany
>
>
> On Tue, Jul 26, 2016 at 7:00 PM, Miroslav Hradilek <mhradile at redhat.com>
> wrote:
>>
>> 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
>>
>> _______________________________________________
>> almighty-public mailing list
>> almighty-public at redhat.com
>> https://www.redhat.com/mailman/listinfo/almighty-public
>
>
>
> _______________________________________________
> almighty-public mailing list
> almighty-public at redhat.com
> https://www.redhat.com/mailman/listinfo/almighty-public
>