Role of Solution Architect in Software Development, Compared with Enterprise and Software Architects
ฝัง
- เผยแพร่เมื่อ 27 ก.พ. 2019
- Solution architecture: how does it work? When do you need a solution architect?
To learn more about solution architecture check our articles:
1) Solution Architect: Processes, Role Description, Responsibilities, and Certifications www.altexsoft.com/blog/engine...
2) Software Architect Role, Skills, and Impact on Product Success www.altexsoft.com/blog/softwa...
Learn more about AltexSoft: www.altexsoft.com
Follow us on LinkedIn: / altexsoft
Follow us on Facebook: / altexsoft
Follow us on Twitter: / altexsoft
#SolutionArchitect #ProjectManagement #AWS - วิทยาศาสตร์และเทคโนโลยี
OH MY GOD! Thank you, thank you, after 20 years of searching you have described EXACTLY what I do in my job, who I am, my "tribe" if you will. I even work in the same industry sector (hospitality technology), but no-one has ever used the term 'Solution Architect' before. I have been a Software Engineer, Software Manager, R&D Manager, Technical Consultant, Project Manager, Product Manager, Business Analyst, but this is EXACTLY what I really do, and in the same language that I use that causes most of my colleagues look at me in bewilderment. Bizarrely, this is also the best video I have ever seen that summarises the whole software enterprise - but then that must be because you are describing it from the same perspective as me! I am so grateful and excited. I will be following this up!!
😂😂😂😂 i am a solution engineer and i dont know how to tell people what it means to be one
You found yourself. lol
Extremely easy to interpret. Very helpful illustrations. As Industry 4.0 integrates into viably new companies or into the ecosystems of legacy companies across the world, the increasing role of bonafide Solution Architects are prudent to say the least. Now that I think about it, I see the 2020's decade emergence of brilliant teen and university Solution Architects in Rwanda, Nigeria, Ethiopia, Kenya, South Africa, Senegal, Morocco, Tanzania, Namibia, Kazakhstan, Singapore, Boston and Jamaica.
you don't just gave me a explanation for my topic
you gave me a clear view for all what i am don't at the university for 4 year
i wished that vid won't finish
great work
This is the best animated video ever. It explains my work of the last 15 years in this video. Great work.
Hello sir ! I'm just learning about AWS services, can you please provide some insight as what to expect on the way to becoming a solutions architect ..?
Simple and straight to the point! Good stuff!
I'll be watching all the rest of your videos as well, thanks a lot for making these, they are super great
More videos like these please. Super refreshing to find vids like this explained so well and entertaining
This is great, I love the beginning with the history of the role so we can understand why there was a need for it and what it's supposed to archive. Great content.
I cannot thank you enough. This video really gave me a thorough insight into SA role.
Very good approach of SA role , responsibilities and interaction within the teams and individuals. Congrats
Loved this video. So in depth and there’s no fluff. Thank you. Subbed!
Awesome value in 12 mins . Crisp explanation and covers all vital points. I could learn a lot. Thank you
That was super helpful. I wish that many Job Descriptions were explained same as how you explained. I Liked and Subscribed!
Ur Comment Bot😂😁
Perfect, best video I have seen. What multiple books tried to do in 1000s of pages this video was able to communicate in mater of mins. Kudus
Excellent paced explanations.
Solution architect : Very well articulated. Keep up the good work :)
Very Helpful. Nicely Explained.
Wow... I got my MS Solution Architecture certification way back in 2003 and it wasn't until I saw this video that I fully understood all of skills I have, have learned, and have practiced in all of my projects ever since. Pad in my own back, my friend! :D
Hands down the best Solution Architecture explainer video I've ever watched - perfect when swotting for an Agile exam :-)
What a great video which I found extremely helpful for my work and next step in my career towards solutions architect. Thank you!!!
By far the best video I have seen to understand different types of architects and their functions! 😊👍
Well, that was super helpful visually helping me understand what this is and what I'll be roughly learning if I continue with AWS certifications. I don't really know how to code but I do know that you don't have to know how to do it but you should be able to explain the gists of it which is plenty for me. Thank soo much for this video!
Outstanding style of presentation. Excellent logical flow the way you laid it out. Thanks, I liked & Subscribed!
Great description. Loved the graphics and detailed explanations. Good job !
This is simply amazing! Great content
Amazing. thank you!
Great Explaination. Best I've found
Insanely good overview, thank you.
Nice brother!!!!!!!!!,your content very helpful ,thanku so much and groom it...............
Congratulations on the video.
The soft jazz "Take me out to the ball game" at 3:40 is wrecking me and my ADHD. XD
Such an awesome tutorials!!
awesome video, thanks!
Amazing explanation, thank you
Good presentation , but a correction is due.. Solutions architects shouldn't normally select patterns at the level suggested - MVC / Factory / Controller level. This should be done by either "software architects" - a role that's pretty defunct across most sectors - or more commonly by the Technical Lead / Lead Engineer types
Excellent explanation
Great video!!!!
Nailed it . Thanks for good work .
Very good description, watched it multiple times. But my lord that background music is loud!
love this video and the explanation!
helpful, thanks!
Good video. Thanks
interesting video, thanks!
This is a great video, solution architects are for bigger or more complex projects
This video is effing amazing
thank you so much
Extremely easy to get to understand this position and background. very helpful!
This made me realize what I want to purse
SE: Integrate and/or deploy the thing.
Sr. SE: Improve the thing.
Lead SE: Advise on how the thing works for a category of clients or type of business.
SA: Try to prevent all the problems you encountered as SE, for a product.
Sr. SA: Sit in a lot of meetings. Gain so much institutional knowledge, your scowl can validate a heated QoS review.
Lead SA: You can recite legacy code, the person who asked for it, and the one who made it work with eerie detail.
ALL: Make sense of the Jerry Springer Thanksgiving table that is Product, Sales, and Engineering - all while begging for more money for your cloud compute du jour.
Oh. And cry. Sometimes drink. Usually both in a loop.
Good explanation
philippe kruchten was my professor at UBC!!!
useful nfo thanks
terrific
This was a very helpful delineation between these roles. Thank you. Can I ask that you avoid real songs for background music? I'm trying to listen to the talk, and all I'm able to hear is "Take Me Out to the Ball Game". There's plenty of canned non-descript music out there.
I feel the same way as you. I love their content, but I was too focused on the background music. All I could think of was baseball.
Amazing content! Please explain how HRIS helps a company.
What's HRIS?
I'm trying to do a comparison between Solutions Architect and UX designer - Can anyone help with this?
One huge problem; none is in charge of 360 perspective in this model. I am trained and I also agree that the solution architect owns the solution, drives innovation and work together with the project manager/product owner to drive the product/project forward. Solution architect, or if you are lucky an EA, sets the structure (areas etc.) for the requirements, what is important to capture, spend time on and detail and inherit or create rules, principles, guidelines and guide/direct the business analysts.
Did no one notice the really jazzed out version of Take Me Out To The Ball Game playing in the background?
Yes and it's incredibly distracting...
Basically Systems Engineering but for IT
So solution architect depends on the type of xompany ..
Mentioned uml and showed a flow chart
sounds over compicated
we use 3 roles (BA and SD offten are done by the same person)
1. Business Analyst - responsible for getting solid “as-is” business knowledge of the client and business requirements for the to-be solution.
2. Solution Designer - responsible for “to-be” solution design, i.e. how business requirements will be implemented in the solution. SD does the following:
• Describes to-be solution as a Functional Specifications. This is not very technical document understandable by Client, Developers, QAs. The document contains screen prototypes and describes how the functionality will be implemented including assumptions and limitations.
• Answers to questions, raised by team members, on how the solution has to handle different corner cases and defines functional limitations
3. Tech Lead - responsible for:
• Technical Architecture
• Dev Team technical management including
o Task decomposition and allocation to developers
o Code review
o Helping developers with resolving complex issues/tasks
o Timeframes and efforts estimation
• Troubleshooting (poor performance, memory leaks, etc)
Yes, roles you've described is another option
Can someone tell that how to switch from developer to solution architect with 1 year experience?
Portal pa
Yes, UML is a MUST to communicate any design decisions to clients BEFORE coding started.
Foreman?
Problem with projects failing probably had to do with business people overpromising features when they didn't understand software development at all.
I am a solution architect, I don't write UML.
Having "take me out to the ball game" playing as the background music is super distracting from what the narrator is saying
Most software projects are still over budget and fail to deliver expected features. You talk as though this problem has been solved.
Solution Architecture, but SolutionS Architect
Please don't add background music.
Please please please.
The "Waterfall" approach to building software is mostly a myth. I've struggled to find any example of a software project that did not use some form of iteration at least of the coding and testing cycle, even back in the 1970s and 1980s. The idea that no testing would be done until the very end is the most egregious part of this myth (with the exception in some cases of integration testing). Most successful software projects from the past used some form of iteration and progress verification with their customers. This methodology was not suddenly invented, instead grew out of the natural and quite obvious way software needs to be built. It's been codified into named methodologies, but is not something new.
Warning - Superfluous and distracting background music.
This was made like 4 years ago 🥲