Architecture designer and SOA (1) (2)

Guidance:
2.2 What is the responsibility of SOA architects?
So what is the role of an enterprise-level SOA architect? What is the difference between SOA architects and design and development personnel? I believe these are the most confusing problems. For example, when building a system based on the SOA architecture, system designers should focus mainly on the services that the service can provide to external users. That is to say, the system designers are concerned with the functions provided by the Service. For SOA architects, they are more concerned about what will happen when one thousand users call this service at the same time? That is to say, architects should focus on business needs and service-level needs. The roles of all architects include minimizing possible technical risks from the very beginning of building a system. Technical risks generally refer to all unknown, unproven, or untested risks. These risks are usually related to service-level requirements, and occasionally related to specific business needs of the enterprise. Regardless of the type of risks, it is easier to discover these risks when designing the overall system architecture at the initial stage of the project. If these risks are discovered when the architecture is implemented, A large number of developers may wait until these risks are properly solved. For further refinement, we can see that the main tasks of the SOA architecture designer include building the outline of the entire system solution, requirement analysis, overall decision-making on the architecture, and modeling of related components, relevant operation modeling, logical and physical layout design of system components.
As an SOA architecture designer, you must be able to lead the entire development team to ensure that the design and development personnel develop the entire system according to the built system architecture. This is important at 01:10. This requires an architect not only to have good technical insight, but also to have certain project management and project implementation capabilities. In the process of system development, the architecture designer must have good communication and expression skills, which is reflected in whether the system model built by the architecture designer has good readability and comprehensibility. If the system model constructed by the architect is not clear, it may affect the design and developers' understanding of the entire system architecture. To avoid this situation, it is very important to regularly discuss the development team hosted by the architecture designer.
　　3. issues that should be paid attention to when building an SOA Architecture
　　3.1 Integration requirements in original system architecture
When architects build an enterprise-level system architecture based on SOA, they must carefully analyze and organize the integration requirements in the original system architecture. We all know that the service-oriented architecture is the focus of current and future application system development. The service-oriented architecture is essentially a special architecture, it is built and interconnected by integrating components with interoperability and location transparency. SOA-based enterprise system architecture is usually developed on the basis of existing system architecture investment, and we do not need to completely re-develop all subsystems; SOA can reuse existing systems and resources in the system by utilizing existing system resources (developers, software languages, hardware platforms, databases, and applications. SOA is an adaptive and flexible architecture. A system architecture built based on SOA can shorten product time to market during system development and maintenance, therefore, the cost and risks of enterprise system development can be reduced. Therefore, when an SOA architect encounters a very complex enterprise system, the first thing to consider is how to reuse existing investments rather than replacing legacy systems, because if a limited budget is taken into account, the cost of overall system replacement is very high.
When the SOA architect analyzes the integration requirements in the original system, it should not be limited to the integration of existing applications built based on components. The real integration is much broader than this. When analyzing and evaluating the integration requirements of an existing system architecture, we must consider more specific integration types, which mainly include the following aspects: application integration requirements, end user interface integration requirements, process integration requirements, and existing system information integration requirements. When the SOA architect analyzes and evaluates all possible integration requirements in the existing system, we can find that all integration methods are actually reflected to a certain extent in any type of enterprise. For different enterprise types, these integration methods may be simplified or not clearly defined. Therefore, SOA architects must fully consider all possible integration requirements when starting to design a new architecture framework. For example, in some enterprise system environments, there may be only a few data source types. Therefore, the requirements for message integration in the system may be very simple, but in some specific systems, for example, the Electronic Data Interchange (EDI) system in the shipping system has a large number of electronic data exchange and processing requirements, so there will be many different data source types, in this case, the entire system requires more complex integration of message data. Therefore, if the SOA architect hopes that the system architecture can be successfully maintained as the enterprise grows and changes, the integrated functions in the entire system architecture should be provided by the Service, instead of specific applications.