Software Architect và Solution Architect (edit)
Software Architect và Solution Architect, họ là ai, họ làm gì? (linkedin.com)
Mình mới đọc một bài báo miêu tả về công việc của software architect trên một trang tuyển dụng công nghệ có tiếng của Việt Nam. Đáng tiếc là bài báo hoàn toàn thất bại trong việc cho người đọc biết được cụ thể software architect làm gì cùng vai trò và ảnh hưởng của software architecture với dự án phần mềm.
Mình trao đổi với một số đồng nghiệp và phát hiện ra không ai thực sự hiểu về software architect và cũng nhầm lẫn trong việc phân biệt software architect khác solution architect thế nào. (1) Hầu hết các việc làm tuyển dụng ở Việt Nam là solution architect, việc tuyển software architect khá hiếm dù software architect có vai trò quyết định trong việc tồn tại và nâng cao năng lực cạnh tranh của một hệ thống phần mềm khi đi đường dài. Qua đây mình muốn chia sẻ góc nhìn của mình về hai vị trí này.
Khi bắt đầu phát triển một hệ thống phần mềm, những dòng code đầu tiên, những tính năng mới thêm vào rất dễ dàng, nhưng cái giá cho việc thêm một tính năng là độ phức tạp của hệ thống bị tăng thêm. Khi độ phức tạp quá cao do đã thêm nhiều tính năng, việc thay đổi hoặc thêm tính năng mới sẽ trở lên khó khăn, tốn thời gian, tốn tiền hơn. Lúc này các developer sẽ vừa làm vừa càu nhàu, trà đá nói xấu sản phẩm. Đến khi độ phức tạp quá cao, giá trị của một tính năng mới mang lại thấp hơn chi phí làm ra nó thì sản phẩm chết. Trước lúc sản phẩm chết sẽ có rất nhiều ý kiến xin "đập đi làm lại". Nếu công ty đủ tiềm lực tài chính thì có thể đập, nhưng sau vài năm quy trình này sẽ lặp lại và chúng ta tiếp tục đập. (2)
Software architect là người chịu trách nhiệm thiết kế bộ khung cho hệ thống, cách phân chia và tương tác giữa các thành phần (component). Bảo vệ những component quan trọng nhất khỏi ảnh hưởng bởi sự thay đổi từ các component khác. Nếu software architect làm tốt công việc của mình, khi thêm các tính năng mới, độ phức tạp của phần mềm sẽ không bị tăng nhiều. Dự án càng chạy càng thuận lợi, chi phí vận hành (thêm tính năng, bảo trì) không bị đội lên.
Một software architect giỏi có thể giúp công ty tiết kiệm được rất rất rất nhiều tiền bạc và thời gian qua đó nâng cao năng lực cạnh tranh. Nhưng những nhà quản lý thường không hiểu được điều này vì số liệu qua sổ sách không thể hiện được người software architect đã giúp công ty tiết kiệm được bao nhiêu, hoặc không có software architect thì công ty đã thiệt hại bao nhiêu. Tình trạng này diễn ra cả ở những công ty phần mềm vừa và nhỏ ở Âu, Mỹ. Khó trách những người quản lý không có chuyên môn kỹ thuật, vì developers là dân trong nghề cũng không nhiều người hiểu được điều đó.
Về solution architect, nhiệm vụ của người này gần như bao gồm cả BA và developer. Họ thiết kế các tính năng, màn hình, lựa chọn framework, công nghệ. Solution architect là senior developer, nắm nhiều công nghệ, framework, biết cách trao đổi để lấy requirement, vị trí này ngả về phía khách hàng nhiều trong khi software architect nghiêng về nội bộ. Về trình độ kỹ thuật, solution architect ở mức thấp hơn software architect.
(1) Sau một cuộc họp hết sức căng thẳng với các đồng nghiệp mình xin phép được sửa câu này thành: "Sau khi trao đổi với 1 nhóm kín bao gồm các IT tech lead hang đầu việt nam, mình đã tổng hợp được định nghĩa cô đọng xúc tích nhất về Soft A và So A."
(2) Đập đi làm lại không phải là giải pháp đúng đắn khi chất lượng software architecture kém.
Software Architecture, nhân tố quyết định thị trường việc làm trong lĩnh vực phần mềm
Software Architecture, nhân tố quyết định thị trường việc làm trong lĩnh vực phần mềm | LinkedIn
Trong bài viết trước mình đã viết về công việc của software architect và những ảnh hưởng của người làm software architecture đối với dự án phần mềm (1). Trong bài này mình sẽ đi vào chi tiết hơn về software architecture trong một hệ thống phần mềm. Từ đó chúng ta có thể hiểu được tại sao một công ty phần mềm lại đi thuê outsoucing bên ngoài, yếu tố nào ảnh hưởng đến quyết định chọn thành phần nào sẽ được outsource, thành phần nào giữ lại làm nội bộ. Cuối cùng là những quyết định này ảnh hưởng thế nào đến thị trường việc làm. Khi đã hiểu về thị trường việc làm bạn có thể định hướng tốt hơn cho con đường sắp tới của bản thân. Mình tin là những phân tích của mình về thị trường việc làm dưới đây vẫn sẽ đúng trong nhiều năm tới.
Đứng trên góc nhìn của người làm software architecture, hệ thống phần mềm là một tập hợp của nhiều thành phần (component) khác nhau. Các component được phân loại dựa trên một tiêu chí duy nhất là mức độ quan trọng.
Quan trọng nhất là các component xử lý bussiness, domain logic. Quan trọng vừa là những component xử lý application logic (các logic không phải nghiệp vụ). Ít quan trọng nhất là những component liên quan đến UI. Ok các bạn frontend developer, mình biết UI rất quan trọng đối với người dùng. Tuy thế về mặt software architecture, tức là về mặt kiểm xoát complexity của hệ thống phần mềm thì UI là component ít quan trọng nhất. Tại sao?
Tại UI là component phụ thuộc vào các component backend khác và không có component nào phụ thuộc vào UI. Với software architecture, component nào không có component khác phụ thuộc vào thì nó ít quan trọng. Khi đó UI component có thể thoải mái thay đổi mà không tác động đến các component khác. Code xấu, software design kém, không sao, miễn chạy được là được, nó không ảnh hưởng đến các thành phần khác trong hệ thống. Chính vì yêu cầu dễ dãi trong chất lượng code mà các công ty Âu, Mỹ sẽ tìm cách outsource các component UI (hoặc gần UI) để giảm chi phí, trong bối cảnh nhân sự phần mềm khan hiếm.
Quan trọng nhất là những component xử lý nghiệp vụ (tạm gọi là domain component). Những component khác sẽ phụ thuộc vào domain component. Những thay đổi trong domain component sẽ ảnh hưởng đến nhiều component trong hệ thống. Vì thế yêu cầu chất lượng (software architecture, software design) của domain component rất cao. Do chúng ta đang sống trong một thế giới không hoàn hảo, nguồn lực và trình độ là có hạn. Nên công ty sẽ dồn những người giỏi nhất để làm việc với domain component và sử dụng nhân sự chất lượng thấp hơn cho các thành phần ít quan trọng.
Hiện tại các công ty phần mềm Âu, Mỹ thường outsource các UI component hoặc thuê remote developer với mức thu nhập khá cao nếu tính theo mặt bằng sống ở Việt Nam. Các thông tin tuyển dụng thường yêu cầu biết Android, iOS, React, web development... hay một framework cụ thể nào đấy. Vì đây là những công nghệ cần thiết để phát triển UI component và component gần phía UI.
Đối với domain component, công ty sẽ yêu cầu những kỹ năng thiên về software design như SOLID principals, object oriented analysis and design, algorithm, complex analysis, software architecture, clean code, TDD, BDD... Do nhân lực phần mềm khan hiếm, nhiều công ty đang đến các nước đang phát triển như Việt Nam để tuyển nhân sự có trình độ làm domain component, tài trợ VISA rồi đưa sang nước ngoài làm việc. Do tính chất quan trọng của domain component, các công ty thường không thuê outsourcing hoặc thuê remote developer vì họ không kiểm xoát được.
Nếu xem tin tuyển dụng trên StackOverflow hoặc những trang tương tự, chúng ta sẽ thấy các job frontend sẽ tuyển remote, các job backend sẽ tài trợ VISA và hỗ trợ thay đổi chỗ ở.
Bạn muốn tận hưởng cuộc sống vui vẻ ở Việt Nam với mức lương trội so với mặt bằng hay ra đi tới một môi trường sạch sẽ, giáo dục tốt hơn cho thế hệ sau?
Not Management, Technical Skills Are The Only Way to Fix Problems in Software Development
The Problem.
One of the most important aspects of a software development project is controlling the code complexity. High complexity (short for code complexity) makes changing software hard. Whatever it is adding new features, fixing bugs or refactoring, everything we do, we do them much slower. An identical feature cost ten days to implement when complexity is low may take ten times longer when complexity is high.
The Principles.
Based on the nature of code complexity, I have come up with four principles of software quality as below:
1. Good Start.
When we start developing new software, the complexity is low. Adding new features are easy. We don't have many bugs and fixing them is easy too. Our bosses and customers are happy.
2. Bad End.
The good start doesn't last long. As time went by, we added features, fixed bugs and changed the code to adopt changes in the business thus we are increasing complexity. Complexity is increasing and make adding new features slow, creating many bugs. Fixing a bug may create several new bugs or revive old bugs. Our bosses and customers get angry.
3. Small Up.
A small team with fewer people usually don't increase complexity as much as a big team when working. When the result is good, bosses and customers want to add more people to the team. They don't understand that the good result is because the team is small. The small team becomes a big team.
4. Big Down.
It's much harder for a big team works in software development. People steps on each other foot. Complexity increase at very high speed. The productivity is low or even become negative. Everyone is tired. I have worked on projects that after one year I looked back and don't see any of advancement at all. The customer gets angry and cuts headcounts. The big team becomes a small team.
The Solution.
With four principles above, we aware of the problem. The next step is to solve it. We have to make complexity as low as possible.
1. We have to break a big team into many smaller teams. Small teams don't increase complexity as much as big teams. If you have a developer who is good with software architecture, he/she can break a big system to many small independent components. Each small team develops a component. This is the most effective way to reduce complexity.
2. We have to keep high-quality code when working. The most basic way is careful when coding and set up a code review system. But it the most inefficient way and it's costly (time, money). There're practicals and technical skills that are more efficient but much harder to learn and apply. They're Test-Driven Development, eXtreme Programming... Discussing them here is too much writing.
Conclusion.
In software development, technical skills are the only way to push a project forward. Low complexity code not only boosts our productivity but also make work becomes fun and relax thus boost people morale. Smaller teams also reduce the time we wasted on meeting and communication.
We are living in a fast-paced world. Everything changes at incredible speed.
You will make many errors. You will solve the wrong problems due to mistakes in analysis, design or requirement gathering. Yesterday, you solved the market demand and created a perfect software but today it is no longer relevant.
To stay alive, software needs to change constantly. The perfect software today will die tomorrow if it is unchangeable due to the high complexity code. The useless software today will become useful if it is easy to add useful features due to the low complexity code.
Scrum Master vs Project Manager: Who Wins? Developer!
The Past: Project Manager
When project managers have good developers, there are good results. They don't need to do anything. When project managers have bad developers, there are bad results no matter what they do.
In the past, management plays a huge role in successful projects, but in software development, things are different. The main factor that decides the quality of software is developers.
The Present: Scrum Master
People look for a better way to develop software and scum/agile born. In the present, project manager replaced by scrum master. In the scrum methodology, developers have more responsibility and play a more significant role.
Scrum master acts as the monitoring and focuses on process, not management.
Developers now give the estimation, discuss the features and the implementation. Previously, it was the project manager's responsibility.
The scrum methodology has proven prosperous but many Asian countries stuck in the past. They keep trying the past model while westerners adopt agile methods.
Software outsourcing firms also favor the past model, because they can sell project managers for a premium price. A project manager can bill 8 hours a day each project for a few projects with different customers. Why they do that? It's because they can.
The Future: Developer
In my opinion, people working on software development, manager or not, it's better if they have strong technical skills. Successful companies have managers has a technical background.
Scrum is not perfect. There're too many meetings. We can prevent it by giving developers more responsibilities. Westerners have a mindset to always trying to improve current things. We, Asians, lack that and insist on staying in the past.
Conclusion
We do software development.
Give responsibility to non-technical managers. It doesn't work!
Move some responsibility from managers to developers. It's scrum/agile. It works better!
But some roles like scrum master and product owner is non-technical should we make everyone technical? It may work better or not.
For me, I believe only a good developer can become a good project manager. Everyone who work on software development should have a technical background. Hint: be a developer before becoming anyone else.
In the next post, I will give a list of reasons why software development project failed and why they can only be solved using technical skills.
