Planning the SOA reference architecture)

A Reference Architecture (SOA) is a framework that enables each project to have a compliance basis to promote consistency, best practices, and standardization. The reference architecture is not limited by the current IT status, but should be targeted at a well-thought-out vision. IT can be said that IT guides all future development work and serves as a reference for achieving this goal. Generally, a two-or three-year plan is suitable for service-oriented transformation. It will not be too long-term or illusory. Therefore, the reference architecture provides a method for communicating the goal vision, helping different departments and IT personnel gradually align with the goal.

Efficient SOA requires a new approach to IT infrastructure, tailored to the needs of individual enterprises, and provides service infrastructure, shared technical services, and security services, and information/data, and legacy system access services.

To meet the requirements of SOA, all companies need the SOA reference architecture and roadmap to guide the deployment of a set of industrial service infrastructure that can evolve over time, it also guides the development and management of service-oriented applications.
In addition, enterprises also need to supervise the design of individual systems involved in the SOA architecture, and establish general services where appropriate to achieve higher efficiency through collaboration. For these initiatives, standardization of connection endpoints (by establishing clearly defined contracts and interfaces) is a prerequisite for achieving IT system consistency.

The SOA reference architecture guides all SOA implementation projects and can jointly develop enterprise-level services and SOA infrastructure standards to benefit enterprises as soon as possible. In other words, the focus of reference architecture planning is to develop a feasible road map specific to the needs of an enterprise to bridge the gap between the current and vision objectives; evaluate existing systems and technologies used for development, deployment, management, and monitoring, define the target State vision, and reference the target architecture model.

The SOA reference architecture can be a blueprint for guiding SOA success. Its functions include:

• Promote close cooperation between IT and business: Based on the formulation of the architecture, this article analyzes the positive impact of SOA solutions on these driving forces based on the business drive and IT objectives, then, we will determine the implementation architecture, relevant specifications and road map for the evolution from the current IT status to the vision architecture. Therefore, the reference architecture provides traceability between business and IT goals and implementation architectures, which is an important medium for communication between businesses and IT, it is the foundation for enterprises to implement business flexibility, manageability, and change planning.
• Assists enterprises in the cultural migration to reuse, team collaboration, and resource sharing: refer to the architecture to establish the best practices for SOA Architecture Standards and Technical deployment, for future SOA implementation projects, establish architecture compliance metrics and metrics.

The reference architecture is not static. In a new SOA strategy and planning iteration, the reference architecture and standard standards of SOA may need to be directed at new business and IT situations and feedback from the implemented SOA project, therefore, the reference architecture of SOA is not only an IT template, but also a live document describing SOA principles and standards.

We can roughly divide the content of the reference architecture into two parts:

1. Establish a set of common terms and practices for services, including:
   • Formal Definition of a service-for example, a service must be composed of contract, interface, and implementation
   • Service classification (core business function services, data services, presentation services, etc.), as well as design principles and suggestions for various services
   • Interface standards (JMS, RMI, HTTP, etc.), recommended interface styles (for example, use coarse-grained and asynchronous service call modes as much as possible), and reliability requirements
   • WS-* standards to be followed
   • Security Policy
   • Service version control policy
   • Specifications for service and data model adoption
   • Service lifecycle Definition
2. Specifications related to service infrastructure, such as Enterprise Service Bus (ESB), business process management (BPM), Registry, and Repository, including:
   • What deployment configurations must be supported?
   • What capabilities are required?
   • Responsibilities of various components
   • The coupling relationship and principles between components should be avoided, for example, displaying services and business process services cannot directly call data services, but must pass through core business services; in other words, data Services cannot be directly coupled with presentation services and business process services.
   • Various components should support those technologies and standards (such as SCA, SDO ...)
   • What security concerns should be considered and how to manage permissions?
   • Products to be used

Because several types of SOA participants and stakeholders (stakeholders) have different concerns when planning the service infrastructure reference architecture, including architects, programmers, and IT personnel responsible for deployment, operation, and monitoring, we can adopt a 4 + 1 View (as shown below) adjusted for the service infrastructure reference architecture ), helps us to separate concerns, develop specifications and target architectures at different levels, and cooperate with best practices models and models through four views, including logic, implementation, deployment, and process, to describe and standardize all aspects of the reference architecture, as shown in the figure below.

Illustration: the 4 + 1 view adjusted for the SOA reference architecture originated from the graphic tural Blueprints-the 4 + 1 view model of software architecture published by Kruchten in 1997

Figure: Logical View of the service infrastructure reference architecture)

Function View in the logic View of service infrastructure)

Illustration: The Implementation view instance of the service infrastructure reference architecture (the scenario is the provisioning service of a telecom customer), depicts the products to be used, and how to use the interaction between these products, to implement the solution

Referring to the planning process of the Architecture (for example,), we should start with the business drivers analysis to help ensure that the target architecture can support business development strategies and directions, demonstrate the value of SOA construction to business, demonstrate the legitimacy of SOA investment, and obtain funding from relevant business departments. Taking the financial industry as an example, the business drivers include:

• Improve Efficiency
• Lending Process Optimization
• Call Center Optimization
• Increase sales and significantly surpass peers
• Fast and flexible launch of innovative financial products
• Expand customer relationships and integrate customer data
• Cross-selling
• Relationship-based pricing strategies
• Cost reduction

This category is value-driven. After analyzing the value-driven business, consider various IT goals and how they support these business drivers. For example:

• Shift from focusing on chimney/vertical application systems of various business lines to focusing on processes/services across systems/business lines
• IT asset Reuse
• Improve the transparency of cross-department Collaboration Business Processes

In addition, evaluation criteria should be set up as indicators for realizing various value driving forces in future assessment. Next, we can further develop appropriate SOA policies based on the business and IT driving forces and consider adopting SOA, which will generate the greatest value for those business lines and driving forces, to establish a priority level for implementing SOA projects.

Illustration: refer to the Architecture Planning Process

Illustration: from business-driven and value chain analysis, we can find out the business and IT capabilities that should be prioritized to adopt SOA to help improve.
√It represents a significant positive impact on SOA projects, and so on.

For each value driving force, we can refer to the matrix analysis method in the figure, from the value chain or business line of each major function (vertical), and each identified business and IT driving force (horizontal ), evaluate the potential positive influence of SOA one by one, and then select the business capabilities that best benefit the service solution, as the starting point for implementing the SOA project in the first phase. The example in the figure is just the starting point of a 30 thousand-foot high altitude. In actual situations, it is often refined down to one or more business lines with higher scores in the example, further analyzes the SOA value driving force for each major business capability in the business line. In other words, the various functional domains in the value chain analysis should be from rough to fine, step-by-Step drilling and drill down to an appropriate depth can more accurately determine which business capabilities of SOA need urgent improvement and bring the greatest value.

After selecting an SOA policy based on the business and IT driving force. Next, we should analyze the gaps based on the current situation of the enterprise and the goals for the next two to three years, and based on the best practices ), formulate a blueprint, roadmap, and guidelines for SOA development, and complete the planning of the reference architecture. Then, you can begin to execute one project after another in a gradual manner based on the projects formulated in the road map, gradually build the service infrastructure in the blueprint.