I originally consider EIGO, Experience In Gospel Out, but felt that EIKO sound better.
On one of the Linked-In groups there was a lengthy discussion on architecture stack to use. What became very apparent was the trend to advocate a particular architecture primarily on the fact that you have experience with it. Opinions follow the same type of brand loyalty that you see with cars (Toyota, VW, Ford), computers (Linux, Mac, PC) and event TVs (Sony, VIZIO, Panasonic).
If MD followed the same brand loyalty –they would likely be deemed to be unprofessional and perhaps facing malpractices. One of the keys of being a responsible architect is to be profession which means become familiar with the different brands and to make rational decisions based on solid criteria. This means not slipping into plagiarizing marketing literature (which by definition, is not objective or rational), or opinions on the groups you frequent (most groups are inclined to a biased, self-affirming attitude.
Before even looking at REST versus SOAP versus COM versus whatever, you really need to get out of the technical ghetto and make sure that you have heard what the customer wants (remember the customer is always right!)
- What’s the budget?
- What’s the delivery time line?
- How risk-adverse is the customer?
- What’s the best case and worst case for load today and for the next 5 years (a decade ago, it was 10 years, when I started in this business – 20 yrs was not uncommon)
- What are legal requirements?
- Accessibility – ADA
- Privacy Laws
- Degree of security needed (often something like REST will be excluded immediately if the customer is risk adverse – REST is a minefield for security)
- Then there’s a ton of semi-technical questions:
- Which browsers and versions
- Which OS (and versions)
- Which Mobile OS (and versions)
- IT Security Practices and Standards
- There is nothing like going into final testing and discover that Security veto some key aspect of the system
A common pattern that I have seen is folks going with their favorite brand and then “fixing” problems found (“Oh, we just need to raise the car and put in different shock absorbers”) or doing polemics (“The gas mileage is actually quite good given the safety ratings of the car”) or the classic overloading of the listener with technical details that are really irrelevant but is successful in turn the green field project into a sheet of ice (from the excellent snow job),
It is natural for folks to want to keep to familiar ground – it should be part of the architectural design if you are working with an existing staff – but as an architect or development manager you should make sure that this human factor does not make for poor decisions…