Cultivation of System Architects

I recently applied for a System Architect and answered some questions during the interview. I found some questionsArticleI think it is necessary to summarize how to be a successful system architect?

First, what is a System Architect?

IBM engineers:

The primary responsibility of architects is to provide shared communication media between developers and project managers. They are responsible for adapting business rules and requirements to engineering practices and restrictions to ensure success

The description on the Chinese wiki is as follows:

The System Architect is responsible for designing the overall architecture of the system. Every detail from the requirement to the design should be taken into account. The whole project should be grasped to make the design project as efficient as possible, easy to develop, easy to maintain, and easy to upgrade.

The two explanations add up the definition of the System Architect.

Several books that Java System Architects should read

Thinking in Java

Valid Java

UML basics, cases and applications

UML entry-level improvement

Software craftsman

Design Pattern-Basis for reusable Object-Oriented Software

Reconstruction-improving existingCodeDesign

Agile Software Development-principles, models, and practices

Enterprise Application Architecture Model

Expert one-on-one J2EE development without EJB

 

Software Engineering-research methods of practitioners

Software leadership-Guidelines for successful software development

The next two books are actually part of the project manager's scope, but they are not very in-depth. It is very helpful to look at the successful system architects.

System Architects of enterprise applications should pay attention to several aspects

Design of Data Persistence Layer

Before Spring and Hibernate and ibatis came out, almost every company had its own method and architecture, and 50% of the architect's energy was also concentrated on it, EJB only adds the burden on architects. After spring came out, most architects were freed from the useless effort to design the wheel repeatedly. Rod's wheel is so easy to use. Basically, you just need to set it up. Or, the most important thing left is to select an open-source project suitable for the database connection pool.

Specific design of MVC Architecture

MVC is just a summary concept. There are many specific technologies to implement, and the most appropriate architecture is designed according to the project.

High concurrency access

When cache is used, cluster technology is used to prioritize the use of Server clusters when the data volume reaches a certain level, followed by hardware clusters, and finally the application itself is added to the cluster function.

results returned for massive data volumes

Use paging as much as possible, optimize SQL statements, and share objects as much as possible when processing data cyclically. Only key data is retained, release memory usage in time

reading and generating ultra-large files

read and analyze large files as quickly as possible. How to release memory in time when writing large files. Learn to use the command line resources of the operating system to complete tasks faster.


multithreading applications and management

thread pool management and monitoring, thread startup (including timed startup), end, recycle, release of thread resources


User Interface Availability design

balance speed and availability, use Asynchronous and synchronous technologies appropriately, and focus on displaying key data

Distributed Data exchange and integration

Select an appropriate data interaction method, from the most extensive and inefficient web service to the most practical file sharing

Cluster System Management

How to Ensure cache synchronization? How to Ensure the uniqueness of objects? How can we ensure synchronization between machines?

Is EJB used? How to Use J2EE features (such as JNDI)

Complex Business Rules

Scenarios and Applications of Rule Engine and workflow engine

 

In fact, as a real System Architect, it should not be limited to enterprise application systems. Such systems often have database limitations. Sometimes, we should consider whether they can be horizontally crossed, directly consider the architecture of other systems. Without rich practical experience, you can provide effective design guidance by simply looking at the systems and code of others.

For example, for a software download, consider the following:

1. unchecked and invalid URL verification. allowed for download failure, information record

2. Download an object with multiple threads. Split and splice the object, and splice the lost part of the part.

3. Download thread management

4. communication protocols between servers or P2P machines

5. Speed monitoring and restrictions

6. Monitor and display the download progress

As an online playback software, you can consider the following:

1. Guaranteed playback speed

The machine problem basically does not exist. The key is the network problem. How to detect the network speed and buffer enough content based on the quality of the video to ensure smooth playback.

2. Guaranteed playback Quality

How to Use DirectX and other technologies to achieve the fastest rendering is to write the underlying layer by yourself or use existing APIs

Since I have never done similar projects, there are still a lot of things to write.

System Architects should have the following qualities:

1. practical programming experience

For at least two years, I will not talk about it any more. In fact, if I start to study at the university,

2. written and verbal communication skills

Using structural diagrams, UML diagrams, text and code snippets to express your own design ideas, word or PPT should be a good choice.

Among developers, it is found that the most valuable standard for architects is effective communication. You need skilled and experienced developers who need to have experience communicating with the business issues in the project. Architects often have to predict the gaps in understanding before they can contribute. They must be willing to overcome the difficulties to ensure the integration of technology and business perspectives. They do not have to plan and coordinate the exchange of views; this is still the work of the Project Manager. Their task is to determine the best tools and components for expressing system design to facilitate effective exchange of views. They must be able to determine whether the current method is insufficient and the new method is required. Writing skills are also very important. You also need to be able to make a sketch or use the drawing software.

3. Be proactive and actively solve Design Problems

The architect's daily work objectives are often unclear. Many developers directly refer to the functional specifications to list tasks. Architects usually provide these developers with the structures they need to improve their work efficiency as much as possible. Good candidates not only conduct communication work, but also anticipate various design issues and solve them-they are generally consciously carried out without any specific instructions. Regardless of the assigned responsibilities, developers who actively participate in the project have the opportunity to stand out from those who work together.

4. abstract thinking and Summarization

Architects, as the name implies, must have a sketch in mind before the system is built. If you want to transform the existing system, you can summarize the architecture characteristics of the system after reading the system documents (if any) and code.

Architects must be able to understand vague concepts and turn them into project components that can be understood by relevant parties. They must be able to understand abstract concepts and communicate with them in specific languages. Good candidates among developers often require or actively explain problems that are easy to confuse during the development lifecycle. They can quickly evaluate various ideas and incorporate them into operational recommendations for subsequent work.

Developers often have strong mathematical skills, while good Architects tend to show stronger verbal skills. Managers often say that developers are "engineering aware", which is a very meaningful aspect for evaluating architects. Architects should be able to solve technical problems, but they must be able to obtain more comprehensive information about how people interact with the technology. This requires a certain form of abstract thinking (instead of code details), which may be difficult to form.

5. Comprehensive Technical Information Absorption and selection and identification capabilities

As a developer, the research capability for a specific problem (although many people have summarized it as Google) is quite good. However, the ability to fully accept and selectively gain an in-depth understanding of technical information and make the right judgment. Those technologies are nothing more than manufacturers' gimmicks, and those technologies are actually usable projects, to improve the quality of the project, this capability is indeed crucial.

 

 

Certificate ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

 

Many System ArchitectsProgramMember's dream career. Today, you may have mastered various development tools and can use various platforms for development, but as an architect, there may be a long way to go. Mr Tao Peng's accomplishments in lamp architecture have invited him to write this article. Maybe the advice of this architect can save you some time on the way to future architects.

The typical development steps of a product usually involve a series of steps such as system requirement research, system analysis, system design, development, testing, and deployment implementation, as shown in:

In this process, the System Architect plays a role in connecting with (facing business experts/system analysts) and starting (facing Software Engineers. Therefore, the System Architect is a core role throughout the product development cycle. If the market and sales determine whether a product is sold well, the system architect directly determines whether the product is developed successfully. In a sense, this is also the future dream of many programmers.

To become a good system architect, you can't achieve it overnight. "It's not just a day's cold." In addition to having deep professional skills, it also requires comprehensive technologies, mature practices, strong insights, rich experience, strategic and forward-looking thinking capabilities, good at grasping the overall situation, and thinking at a higher abstraction level. If system analysts and business experts only need to be responsible for the business of a product and do not care about a product software development language, a good professional System Architect, not only should we be familiar with the product background and business logic behind the product, but also the software development language used (such as Java/C #/C ++/J2EE ), you must be very familiar with it. Otherwise, it will not be able to take effect, and of course it will not be able to design a good software architecture. In the United States, a qualified system architect pays even higher salaries than a department manager or product manager, which is also a common reason why 30 or 40-or even 50-Year-Old programmers in the United States.

In fact, many of the problems encountered in software development may all come down to be related to the original architecture design. Therefore, it is not easy for an architect to become a target. Based on this, I believe that to become a qualified System Architect, first of all, we must start from programmers. with years of first-line software development experience, we can deeply understand the hardships and difficulties of programmers, in order to design an architecture that is easy to expand, easy to modify, easy to maintain, and "not difficult" for programmers. A System Architect must first be able to make a prototype that is "self-explanatory" in order to communicate effectively with programmers. Instead of simply designing an architecture, the System Architect should give it to programmers. In this way, the products developed later are highly risky. Taking the product I am currently developing as an example, this product is only a small part of the company's core strategic products. Of course, although small, it is the core of the company. This product is equipped with 3 System Architects (over 40 years of age, with decades of software development experience), 6 programmers, 5 tests, and an engineer responsible for product packaging. These three system architects are also involved in core code writing.

Secondly, qualified system architects should be familiar with the business background of the products to be developed. Otherwise, the products designed are not the products the customer wants, of course, it is not a successful product. Take the product I am currently using as an example. This product is an implementation of the SCA specification. One of the three system architects is the participants and creators of the SCA Standard Specification, the SOA/SCA standards have a considerable degree of knowledge. Otherwise, the products made can only be pursued by large companies every day after their ass. What do other people do, do what you do, modify the standards of others, and modify the standards as soon as possible.

Third, as a system architect, you should always read the latest books on product background and system architecture design. Although the current technical books are out of stock, there are very few excellent products, most of them are collected from the Internet, but I often read some excellent books from foreign masters, it can also bring some new ideas and design concepts to you.

fourth, as a system architect, be confident, neither conservative nor cloud-based, and never superstitious about masters and heroes. Others say that J2EE is good, and their products are developed based on J2EE; others say that. net is easy to develop and the development cost is low. net; others say Ruby is agile, and they say their products are developed based on ror. Be sure to use your own development language and design your own architecture based on the actual situation of your company, market, and project. For example, the book j2eewithoutejb puts forward the famous principle of "Don't create new wheels. If everyone doesn't want to build a wheel and use the existing frameworks and products of others, how can there be technological advances and thriving scenes? The author of spring didn't see the criticism of the classic j2eeejb framework to design his own spring wheel. Why did he persuade others not to create another wheel when he had the spring wheel? Gavinking created the hibenate wheel. Why did gavinking participate in the formulation of ejb3.0? And participate in the design of the seam wheel? I personally think that a system architect must build his own wheel to be a real System Architect, rather than piecing together a lot of open source frameworks.

fifth, critical Inheritance is required for open-source architecture design. Read the Source Code of these frameworks. Take the development of J2EE and Eclipse plug-ins as an example (because I focus on these two aspects), from the popular EJB in the past few years, to struts → j2eewithoutejb → spring/hibernate → Ajax, the popularity of each framework has a profound historical background. There are some difficult problems that the existing framework cannot solve. These frameworks are designed to solve some problems. We often read the source code of these masters, which is a kind of spiritual enjoyment. It is also of great benefit to temper our own skills. For example, when developing Eclipse plug-ins, you often encounter a problem: how can we listen to user-saved events? Although eclipse provides a resource change listening mechanism, it directly uses the mechanism, it is very primitive. Any resource change, such as adding, deleting, or moving a graph, will cause this event to be called, and I just want to listen to the instant event of the user's disk storage, in the past, when I was working on a project, I tried my best to solve it. Later, in the source code of another product, I saw a good solution from others. I saw the source code, but I really realized a lot. Sometimes, the source code of eclipse and the source code of J2EE can be referenced and supplemented in the architecture. For example, the adapter extension mechanism of eclipse is similar to the event and resource listening mechanism. We can also obtain the J2EE framework as the design pattern blueprint for designing our own products.

Sixth, excellent system architects must have excellent communication skills to persuade, encourage, and guide activities and win the trust of project team members. After a system architect designs a good framework, if he cannot communicate effectively with the programmer, he cannot provide good guidance to the programmer, therefore, this good framework cannot be well implemented in every step of product development. Some programmers may still handle some key links in the program based on their old experience. It may be very late when the architect finds the problem, persuasion, education, training, and punishment have no significance until then. In addition, if a System Architect cannot win the trust of a project team member, the architecture he designed will not be convincing. If a programmer encounters difficulties, he will complain about the Framework Design of the System Architect, the programmer's sense of responsibility and initiative cannot be fully mobilized. Therefore, a good System Architect is a good mentor for programmers, both mentally and technically.

7. The system architect shall distinguish the roles and relationships between himself and the system analyst, Project Manager, or product manager, neither be responsible for anything nor the technical architecture. As the System Architect is in an intermediate position throughout the product development cycle, it takes longer time to deal with programmers than system analysts have for programmers, sometimes it is even more familiar than the project manager and the programmer, making it easy for the programmer to think that the System Architect is responsible for all the requirements and architecture, which may lead to excessive responsibilities of the System Architect.

The road to becoming an excellent System Architect is a long and long way to go. On this road, we must constantly persuade ourselves to resist all kinds of temptations. When no one is in the middle of the night, we must be able to pick up the light to read others' source code, and be able to withstand all kinds of pressure, it can work with the project manager to resist the boss's unreasonable schedule requirements and encourage the project team members to tide over the difficulties in time. In a word, it is not easy to become a System Architect. "The road is long, and I will go up and down ".