Theo nhiều nghiên cứu, dự án phần mềm càng lớn, cơ hội thành công sẽ càng ít bởi vì độ phức tạp vượt quá khả năng của người phát triển để hiểu nó. Chìa khoá cho thành công phụ thuộc vào khả năng của kiến trúc sư hệ thống phân rã các yêu cầu thành các nhiệm vụ nhỏ hơn để cho những người phát triển có thể hiểu và có khả năng thực hiện chúng. Khi người phát triển đã hoàn thành, những việc này có thể được tích hợp vào trong hệ thống lớn tương ứng với kiến trúc đã xác định.

Kiến trúc tốt phải làm chi tiết mọi giao diện, chức năng, và cơ chế kiểm soát tách biệt để cho nó có thể linh hoạt, dễ dàng thay đổi. Nếu được thực hiện đúng, nó cho phép người phát triển tập trung vào nhiệm vụ riêng mà không cần hội tụ vào giao diện, luồng dữ liệu, và các chức năng hệ thống khác. Nếu được làm tài liệu tốt, nó giảm nhu cầu điều phối giữa các chức năng tổ khác nhau (người phát triển, người kiểm thử, đảm bảo chất lượng, quản lí cầu hình) nhưng nếu được thực hiện kém, nó sẽ là những biện luận không bao giờ dứt, lẫn lộn, và nhiều vấn đề tích hợp.

Kiến trúc chảy từ yêu cầu tới đặc tả chức năng. Do đó, yêu cầu phải đúng đắn, đầy đủ và không mơ hồ. Yêu cầu được xác định kém sẽ dẫn tới kiến trúc kém và kiến trúc kém sẽ làm tăng vấn đề trong các dự án lớn. Thu lấy yêu cầu là trách nhiệm then chốt của kiến trúc sư hệ thống. Người đó phải làm việc với đại diện khách hàng như người quản lí kinh doanh để nhận diện nhu cầu và mục đích của hệ thống. Kiến trúc sư hệ thống là giao diện giữa người dùng và người phát triển bởi vì người dùng không biết cách giải thích nhu cầu của mình theo cách người phát triển hiểu, và người phát triển không biết về qui trình nghiệp vụ để hỏi câu hỏi đúng. Để giảm rủi ro trong dự án lớn, kiến trúc sư hệ thống phải xây dựng bản mẫu để kiểm nghiệm các yêu cầu với khách hàng. Làm bản mẫu là qui trình xây dựng “mô hình hệ thống” bởi vì nó chuyển các yêu cầu vô hình thành mô hình làm việc hữu hình nhưng bị giới hạn của hệ thông tin mong muốn. Kiến trúc sư hệ thống trao đổi với người phát triển bằng việc xác định các mô tả “hộp đen” về các nhiệm vụ. Hộp đen là các thực thể trừu tượng có thể được hiểu, và được thực hiện một cách độc lập với phần còn lại của hệ thống. Qui trình xây dựng mô hình hộp đen được gọi là “trừu tượng hoá”. Trừu tượng hoá được dùng để đơn giản hoá thiết kế của hệ thống phức tạp bằng việc giảm bớt số chi tiết phải được xét tới. Về căn bản, kiến trúc sư giải thích cho người phát triển cái gì cần thực hiện, nhưng không nói về làm sao thực hiện nó.

Người phát triển phải hội tụ vào xây dựng phần mềm tin cậy được và không có lỗi. Để giảm thiếu số lỗi, họ phải tuân theo qui trình được xác định bằng việc dùng các thực hành và công cụ tốt nhất có thể giúp cho họ tìm ra các lỗi sớm trong kiểm điểm và kiểm thử. Người phát triển cũng cần đo công việc của họ để đảm bảo chất lượng phần mềm. Bằng việc có cách đo, người phát triển có phản hồi hữu dụng về công việc của mình và cung cấp tái đảm bảo cho kiến trúc sư hệ thống, người quản lí dự án và người dùng rằng phần mềm có chất lượng cao.

Phát triển dự án lớn có chất lượng là không dễ dàng. Nó yêu cầu kỉ luật mạnh, làm việc tổ và nhiều phối hợp. Nó cũng yêu cầu sự hỗ trợ quản lí mạnh trong việc hiểu công việc gian nan và cho người phát triển nhiều thời gian hơn để thiết kế và kiểm thử công việc của họ. Phần lớn các dự án lớn đều rất phức tạp cho nên yếu tố then chốt là kiến trúc tốt và quản lí dự án chắc. Những kĩ năng này khó tìm được bởi vì đào tạo ngày nay vẫn hội tụ vào khía cạnh lập trình chứ KHÔNG vào khía cạnh thiết kế và khía cạnh quản lí. Rất ít trường dạy kiến trúc, thiết kế và quản lí dự án mà chỉ dạy ngôn ngữ lập trình và đó là lí do tại sao nhiều công ti thành công với các dự án nhỏ nhưng KHÔNG thành công với các dự án lớn. Kiến trúc phần mềm và hệ thống là khó dạy vì nó yêu cầu nhiều kinh nghiệm trong thế giới thực. Bạn không thể học được nó từ sách vở hay theo lớp học mà phải thực nghiệm nó trong thế giới thực, đặc biệt trong các dự án lớn. Cách tốt nhất để học về kiến trúc là trở thành phụ tá cho kiến trúc sư hệ thống, việc “đào tạo trong công việc” này sẽ là tốt cho người phát triển có vài năm kinh nghiệm. Một khi bạn kinh nghiệm điều đó và có tri thức cơ sở nào đó về nó thì bạn có thể lấy vài lớp học để làm mạnh thêm tri thức của bạn và học thêm về các phong cách khác, các cách tiếp cận khác. Chỉ khi bạn đã làm chủ những kĩ thuật này thì bạn mới có thể xin vào làm chức vụ kiến trúc sư. Nhớ rằng người phát triển xây dựng công việc của họ dựa trên kiến trúc và chính kiến trúc xác định liệu dự án có thành công hay không.

—-English version—-

System Architecture

According to several studies, the larger the software project, the less chance of success it will have because the complexity exceeds the developer’ ability to comprehend it. The key for success depends on the ability of the system architect to decompose requirements into smaller tasks so that developers can understand and be able to implement them. When developers finished, these tasks can be integrated into the large system according to the defined architecture.

A good architecture must detail all interfaces, functions, and control mechanisms separately so it can be flexible, easy to change. If done correctly, it allows developers to concentrate on specific task without the need to focus on interfaces, data flow, and other system functions. If documented well, it reduces the need for coordination between different team functions (Developers, testers, quality assurance, configuration management) but if done poorly, it will be a never-ending arguments, confusions, and lots of integration problems.

Architecture flows from the requirements to functional specification. Therefore, requirements must be correct, complete, and unambiguous. A poorly defined requirements will lead to bad architecture and bad architecture will increase problems in large projects. Obtaining requirements is the key responsibility of the system architect. He must work with the customers representative such as the Business manager to identify the needs and the system’s goals. The system architect is the interface between users and developers because users do not know how to explain their needs in the way that developers understand, and developers do not know about business process to ask the right questions. To reduce the risk in large project, the system architect must build prototypes to validate the requirements with customers. Prototyping is the process of building a “model of the system” because it converts the intangible requirements into a tangible but limited working model of the desired information system.The system architect communicates to developers by specifying “black-box” descriptions of the tasks. Black boxes are abstract entities that can be understood, and implemented independently from the rest of the system. The process of building black-box models is called “abstraction”. Abstraction is used to simplify the design of a complex system by reducing the number of details that must be considered. Basically, the architect explain to developers what to implement, but not how to implement it.

Developers must focus on building software that are dependable and free from defects. To minimize number of defects, they must follow the project’s defined process using best practices and tools that can help them to find defects early during reviews and tests. Developers also need to measure their works to ensure software quality. By having measurements, developers are having useful feedback on their works and provides reassurance to the system architect, project manager and users that the software is of high quality.

Developing large project with quality is not easy. It requires strong discipline, teamwork, and lot of coordination. It also require a strong management supports in understanding the hard works and giving developers more time to design and test their works. Most large projects are very complex so the key factor is a good architecture and strong project management. These skills are hard to find because the training today is still focusing on the programming aspect NOT the designing aspect and management aspect. Very few schools teach architecture, design and project management but only programming languages and that is why many companies are successful with small projects but NOT large projects. Software and system architecture are difficult to teach as it requires a lot of experiences in real works. You can not learn it from books or take a class but must experiencing it in real projects, especially large projects. The best way to learn about architecture is to be an assistant to the system architect, this “On the job training” would be good to developers that have several years of experiences. Once you experiencing it and have some basic knowledge about it then you can take few classes to strengthen your knowledge and learn more about different styles, different approaches. Only when you have mastered these techniques then you could apply for the system architect position. Remember that developers build their works upon the architecture and it is the architecture that determines whether the project will be successful or not.