if we take word cloud of all the design discussions a technical architect participates in (or made to participate in ) generic solution would stand out as one of the key term. Be it a waterfall process or an agile one or even appraisals.
The claim is simple. There are multiple things that need to be done in an IT scenario and there is a generic solution that takes care of it. It is often also a direct claim to some efficiency or effort-cost saving. Which makes it very appealing in meeting rooms and is often makes technical people trip (the verb). Often it is not the case tough.
if we take word cloud of all the design discussions a technical architect participates in (or made to participate in ) generic solution would stand out as one of the key term. Be it a waterfall process or an agile one or even appraisals.
The claim is simple. There are multiple things that need to be done in an IT scenario and there is a generic solution that takes care of it. It is often also a direct claim to some efficiency or effort-cost saving. Which makes it very appealing in meeting rooms and often makes technical people trip (the verb). Often it is not the case though.
Examples of Generic solution claims
In the era when NoSQL DBs were all that buzz, I was reviewing a generic solution that would allow connection to all types of DBs.What the solution claimed was that between relational and different NoSQL DBs the way to connect to DB was different so a generic solution was build to handle it. To the experienced eyes, this was actually a common wrapper for various DB. Internally there were factories that were forced under a Common Interface. And not to say a lot of IF-ELSE around DB_TYPE flag and so on. It wasn’t objectional as a proposal except for that claimed lot of savings and fell apart when DB specific constructs were to be handled. And DRY of what was in the field already.
Another example was when we were doing REST. This was more than a decade back and lots of legacy code existed with us. Again a generic solution. This was, hold your breath, a generic REST service. The claim was that is more effort efficient! This generic REST service would expect service name and all parameters in the header and a generic service message body. One needs to then just write specific handlers and bingo lots of effort saving. It was a long struggle to convince the involved that this solution folded the URLs into headers and the effort to write service related code was still there. In fact, the enforcement of generic had increased the coding work. Not to mention it had killed REST.
I had seen multiple variations of this. A generic integration toolkit for service integration. A generic authentication manager.A generic message parser, a generic webpage, generic deployment tools(cloud + bare metal), generic build tool, generic log. Invariably it would be some combination of factories-command-strategy that missed the essential complexity of specific processing and claimed to be a faster way to project success.
How to evaluate such claims?
Given that most of such occurrences missed the same points, I use the following line of probing when I was to approve-review the designs.
- How did it handle the differences? (of whatever was summarized as generic viz different formats, protocol, delivery mechanism, etc. The answer would invariably be to write code to handle it )
- How would it communicate the different types of errors? (many times this would be a total miss or some generic error wrapper that needs to be parsed by calling party)
- How did it cater to the conditions that apply to the execution flow? (it would be either missed or one need to write code or sometimes a domain-specific language ie DSL was to be used)
- Does it/have to maintain some sort of state or stack in order to finish the execution? (this would expose deeper design flaws )
- How much effort would it take to add a completely new variation of specific to this solution(again a very fair question that would test the robustness of the design)
I would specifically not ask whether such a solution exists already or can we open-sourced it. The fact you are in this situation means the point is lost. I would also not ask which all design patterns apply which when answered would offer false proof of validity. The intent was to do a fair assessment and check if the generic solution discounted the specifics.
Invariably the generic solutions had missed the complexity of the specific and claimed that because it has been wrapped -it doesn’t arise (and hence the savings ). Gradual questioning like this would uncover the effort/processing complexity. This often leads to the generic solution giving space to rightly estimated solutions that represented the real depth of the complexity.
The positive side
But there is also a positive possibility. Sometimes there is a real fitment that exists for such adapters(a very broad range I cover with this word). An expanded version of the above questioning makes the design specifications deeper and allows the team to correct the course. The example in the above list where a DSL was proposed to handle all common tasks applicable to our problem space was indeed a good solution that offered effort saving and also empowered the developers. We must also note that in such cases the correct term would be general-purpose as opposed to generic. It conveys the trade-offs neatly and effort aspects transparently.
In another case mentioned above, a generic webpage solution was offered. This was basically a wrapper of HTML and JS that could handle a number of UI related needs we had. One could argue (and I also had my reservations)on merits creating markup language for markup. In the era where componentized micro front ends are proving to be practical, we could have dismissed this solution. In my case, we stressed it on the team that this is not a generic solution. It was, in fact, a templatized design-solution. This made the team aware of the enormity of the claim but it also allowed the respective scrum teams to make their choice if it really fit their scenario.
In cases where I had more control over the teams, we also used all such submissions of the generic solution as a training opportunity for the architects. It would often be contrasting their work with existing tools and frameworks in the mainstream and whiteboarding on how all their solution could evolve to a professional level.
But that’s about a positive spin. The appeal of generic solutions in effort discussion has not reduced….. I hope this post helps you with that somewhat.