A student asked me a question in my Introduction to Software Architecture course, and I decided to write a bit of a longer answer than usual. So I posted it here. đ
How and When Architect decide which technologies to go with?
I would like to know How and When an Architect decides which technology to go with? If he/she is not having in-depth tech knowledge, how to decide if selected technology is capable of catering the need
Well, that is a big question of course. This course went over the role of a software architect at a high level, but a more practical question is how to decide between two or more options when faced with a tough decision.
So letâs look at a scenario with real products, and figure out which we would like to buy.
Scenario: You know you need to buy a piece of software, but how do you choose which piece of software is best?
You have to go and find a marketing solution. You did your research, and the choices are⌠IBM Marketing Cloud, Oracle Marketing Cloud, Adobe Marketing Cloud, and Salesforce Marketing Cloud. Yes, four massive companies have named their product the same thing.
So how do you choose which one to go with?
Usually, the way companies do this, is come up with their requirements (part of a RFP). They make a list of features that the product they choose must have, and a list of nice to have features, against which products will be judged against.
In my case, I want a marketing cloud that has the following features, must have:
- Rock solid security
- Intelligent folder structure for projects to support all my clients without risk of overlap (multi-tenant)
- Fine control over which users get access to which clients
- Proven ability to send high volume of emails
- Detailed and reliable reporting and tracking features
- Email automations, funnels
- Schedule emails
- Pre-stored templates
- Customer support by the vendor
- Cost per user
My nice-to-have features are the following:
- Can host standalone web pages
- Support multiple languages for the same email
- Handle unsubscribes with customizable pages
- Future roadmap
So you make your lists of features that youâd like to see.
Now for each application, you need to âgradeâ the application on a score of 1-10 against each of the features.
On a scale of 1-10, how great is the security? Does it integrate with your Active Directory? Can you block IP address ranges? Does is do threat detection and ensure to raise an alert if hackers attempt to get in?
Some applications only do the basics, while others have security features you havenât even thought of.
You go down the list, and evaluate the software on each feature. If an application doesnât support something on your must-have list, thatâs a big problem. A 0, and possible elimination from contention unless youâre willing to modify your requirements.
Now add up the scores under the must-haves and nice-to-haves.
There will be applications that have a low score compared to the others, and that puts them at the bottom of the list. There will be applications have have a high score compared to others, and that puts them at the top. Easy enough, right?
Now how do you choose between two applications where the scores are similar?
Well if they meet the requirements, and the price is within your budget, it might just come down to picking the one you feel will suit you best. Which one had sales teams that replied to your questions the fastest? Which one has the best reputation for support online? Do you already have this companyâs other products in your organization?
Thereâs no perfect solution. Every architect has experienced the case where you start down the path of choosing one vendor, and then you learn that they donât support something basic. Or things donât got as easily as you planned. Such is life sometimes.
But if you start with your requirements, and grading applications based on your requirements, youâll have âthe factsâ in front of you on which you can make a decision.
