Business-centric SOA design-missing the greatest advantage of SOA

Project-based SOA solutions are generally developed in a bottom-up and technology-centric manner. Through these solutions, you can get started with SOA and provide practical experience in SOA design and development tools. However, from the perspective of enterprise architecture, such benefits are usually rare. Organizations that lack an enterprise-level SOA method can still successfully implement SOA, but they will lose hands with the benefits of SOA.

From IBM WebSphere developer technical journal.

Enterprise Architecture and SOA

Looking back at the many SOA customer cooperation projects, I found that almost all customers will think of their Service-Oriented Architecture (SOA) the solution is designed and deployed in a bottom-up manner. In general, they have done quite well in analyzing existing assets, supporting (or simply "packaging") related items (or items that they think are relevant), and developing service catalogs to handle requirements. Generally, business departments require SOA as an architecture model for it-centric integration. The positive side is that this method provides flexibility and basic reuse, but the biggest return of SOA is not that.

To achieve SOA at the enterprise level, you need to integrate the SOA concept with the business (and technology) strategy and governance of the enterprise architecture, and support top-down (and bottom-up) analysis and Design of SOA solutions. By focusing on the business aspect and making it an indispensable part of SOA design and development, organizations can better obtain practical value from their SOA solutions.

In this article, I hope to enhance the concept of combining SOA design with business-centric design. This document is not intended as a tutorial on Enterprise Architecture or SOA design methods. If you want to learn more, see the information about ibm soa methods provided in the references section.

Back to Top

From project level to enterprise level

Before we begin, let us clarify that there is nothing wrong with SOA adoption at the project level. In fact, most Enterprise SOA activities usually begin with a project that is properly defined. In addition, organizations adopting the enterprise architecture will want to verify the SOA solution through experimental implementation. The key is to gain experience at the project/test level and promote it to the enterprise architecture level.

I had an interesting conversation with the chief enterprise architect of a large company a few weeks ago. Although we initially discussed the technical aspects of SOA and the SOA design patterns, we spent a lot of time discussing SOA and enterprise architecture. In the customer's IT strategy, SOA is implemented on a project-by-project basis. This project-centric development method is a feature of most enterprises that currently implement SOA-contributed by the traditional corporate culture and project-based capital investment model. Although project-centered SOA activities provide certain benefits, enterprise-level SOA support can provide greater flexibility and service reuse, it also promotes better correlation between business and IT. Unless SOA becomes part of the enterprise architecture and enters the development, design, deployment, and governance methods of the Organization, the highest return of SOA cannot be fully realized.

Successful implementation of SOA at the enterprise level (and other subsequent successes) can bring more benefits, this includes quickly adapting to market trends, shortening the time to market for new solutions, providing connections to business needs, and reducing long-term it costs. The IBM Institute of Business Value Survey conducted in 2006 can support these conclusions.

On the other hand, a challenge for project-driven SOA implementation is to improve the solution so that it can not only work on a set of service calls. By integrating SOA at the enterprise architecture level, you can make it part of the business/It ecosystem. This method serves as the basis for creating a new solution, and provides cohesion between business needs and IT solutions.

In Figure 1, business and IT strategies promote the definition and specification of enterprise architecture. From a downstream perspective, the enterprise architecture supports planning at the organization level centered on information, applications, and organizations. This framework implements enterprise-level governance and provides guidance and support for IT solution design and delivery. Enterprise-level SOA design usually requires SOA to become the main support framework of the Strategy, Planning and Implementation Layer of the enterprise architecture.

Figure 1. Comparison between projects of interest and enterprises of interest

Figure 1 contributor: Gil long, distinguished IBM engineer Source: IBM Global Services-ea method class.

Back to Top

Break down services

To enable SOA as an inaccessible part of strategy and specification in an enterprise architecture, you usually need to understand the core competitiveness of the organization to ensure a close connection between business objectives and architecture requirements. The process for analyzing the core functions of an enterprise can be completed through various technologies. For example, IBM Global Business Services uses Component Business Modeling (CBM) to evaluate the competitiveness of an organization. Ibm.com provides documents on the CBM process for reference.

At a higher level of abstraction, CBM is a relatively intuitive concept. The basis of the CBM solution is the definition of core business components in the Organization. Business Component isGroups of people, technologies, and resources that provide specific business values, and can perform operations independently.. Sales Management and Product Management/marketing as well as personnel, processes and technical aspects (rendering or executing functions) are business components. Business components support the identification and design of business functions and services from the perspective of analyzing and recording the business services used and the services provided by the components. For example, the "Sales Management" business component may use services from account management and may provide services such as sales order processing to other components (such as "Shipping.

After a business component is derived, CBM allows us to classify it based on its overall cost relative to the business, and evaluate whether the business department considers these functions to be sufficiently competitive. By grouping the competitiveness, you can identify the areas to be improved and optimized. Figure 2 shows a sample CBM work product that highlights components identified as areas for continuous analysis and design.

Figure 2. Example component business model

The identified "Key Areas" may be inputs to SOA design activities such as process modeling. For example, if we decide that account opening is an area to be improved, we can clearly describe the business prospects, business objectives, and user specifications related to account opening to determine initial requirements.

As an example of this process, we used CBM internally when working with large retail banks. During the analysis, we realized that account management is a core competitiveness of the bank and an important factor in determining customer satisfaction and reducing the loss of a large number of customers. CBM activities believe that the account opening process can benefit by converting to multiple business departments across banks to support simpler and standard process sets (such as services. By delivering this enhanced feature, you can reduce costs and increase customer satisfaction. By combining CBM analysis with information warehouse information and process modeling, the Bank is actively developing enterprise-level solutions to switch the account opening process across business departments.

The CBM technology provides a framework for determining the main competitiveness of an organization and providing guidance on organizational optimization in subsequent steps. In addition, almost every major vertical industry can obtain CBM templates through the IBM Global Business Services cooperation project. The Business Component Design Process defines strategic areas for improvement at the business level, coordinates these objectives with the business service view, and combines the service view with IT planning, this provides inputs to the enterprise architecture.

Back to Top

Service-oriented modeling and architecture

The service modeling method is very important for obtaining optimized service models to implement solution design. Service-oriented modeling and Architecture (SOMA) technology provides rigorous analysis and design methods with relevant records for determining SOA solutions. Soma is IBM's end-to-end SOA solution development method. I will not discuss soma in detail here, but will focus on the concept of business-centric SOA design. However, Soma was discussed in detail in an excellent article by Ali Arsanjani. (See references .)

The three basic structures of the SOA model are services, service components (implementing entities of these services), and orchestration service flows (or flows ). Soma is mainly used to analyze and design all three structures. As described in Rational Unified Process (RUP), Soma actually consists of three main steps, as shown in 3.

• Service ID:Derive and define candidate services.
• Service specifications:Establish and verify the decision-making and advanced service model.
• Service implementation:Determine attributes from the perspective of overall component design and expand the advanced service model.

Figure 3. Three Steps of Soma

Although Soma establishes a connection between SOA and business in multiple ways, service identification and service litmus test (the first key step of Service Specification) are the areas that we will focus on.

Service ID

As mentioned above, the main output of the service identification step is a set of candidate business services. Three techniques can be used to generate a list of candidate services during service identification:

• Top-downMethod, called domain decomposition.
• Bottom-upThe IT center approach focuses on discovering and describing existing IT assets.
• Intermediate meetingMethod, called target-service modeling.

Domain Decomposition provides top-down business-driven technologies to capture information about important business domains, functions and concepts subsystems, and business processes of an organization. Domain decomposition is implemented through Business Requirement Specifications designed by business components. In addition, you can use tools such as Websphere Business Modeler to create and verify the process model to enable domain decomposition.

Business Process Modeling is usually performed after the major business activity identifiers in the business component design. Process Modeling is usually first done by business analysts using tools to model the existing (current) Status of business processes. In the process model, analysts give work activities or tasks as steps in the process. As the process model develops and other business stakeholders review it, the "task" will become a project similar to the candidate service. In some modeling tool implementations (such as Websphere Business Modeler), business analysts can design existing and future models and simulate processes to determine runtime features, including costs, resource requirements, and process bottlenecks. Some tools also support defining and standardizing Key Performance Indicators (KPIs. One of the Business KPIs for opening an account can be: the average time required for opening an account should not exceed 18 hours. Through continuous design and simulation, process modeling can establish a connection between business needs and business services to help identify candidate services.

The existing asset analysis technology can be used through tools or by reviewing the existing documents and knowledge of existing IT assets. This activity check may consider existing IT assets that are used to implement the features required by future processes. The source of existing assets may include the following:

• Transaction Based on the mainframe (such as CICs/IMS/batch.
• Commercial applications (such as SAP and Siebel) connected through APIS, message passing, or service interfaces ).
• Customize internal applications, such as J2EE,. net, and client/server applications.
• Services and interfaces of external services and components obtained by the partner.

One tool that can be used to support this function is WebSphere asset transformation workbench. This tool helps it staff scale, reuse, and convert existing applications, and supports dependency analysis for applications in mainframe and/or distributed environments.

For domain decomposition, the result of asset analysis activities is a list of potential candidate services. It should be clearly pointed out that the discovered assets (and the first iteration of potential candidate services) are not equal to the service. In fact, most operations are fine-grained, even for combined services (such as through sap idoc or bapi interaction. These candidate services are generally not ideal in compliance with SOA design principles and may be encapsulated using more abstract services.

Finally, the goal-service modeling derives from the top-down and bottom-up methods and promotes the identification of other candidate services using business and IT requirements. This activity helps identify services that are consistent with the business and ensure that services that are not identified during domain breakdown or existing asset analysis are found. Target-service modeling starts from the business target identification, which is subdivided into sub-goals, and then determines which services are needed to accomplish these sub-goals.

Service Specifications

The second major stage in soma is the Service Specification. This technology involves a series of steps, but for text, we will mainly discuss two activities:

1. Apply Service litmus test to determine whether candidate services are suitable for public use.
2. Determine service model specifications from the perspectives of dependencies, combinations, non-functional requirements, message definitions, and status management requirements.

Service litmus testIs a set of standards defined to determine whether candidate services should be made public. These standards are classified into four major fields:

1. Business consistency:Focus on service business relevance, whether there is a capital investment model for supporting development and maintenance, and the ability to share services throughout the Organization.

2. Integrations:Focus on consistency with non-functional requirements at the combination level, precautions for status management, identification of service dependencies, and support for technology/platform independence.

3. External Service Description:Check whether external service descriptions (such as WSDL) exist, support service discovery and binding through service descriptions, and provide metadata as part of the service description.

4. Redundancy Elimination:Focus on the ability to reuse candidate services across multiple combinations of specific functions.

Through this set of questions, the design team can make appropriate architectural decisions on which services should be developed, made public, and managed as services.

As an example of service litmus test, our seminar with a large transportation and logistics company identified over 400 business-related sap interactions (bapi and IDOC) initially considered candidate services ). In addition to this set of services, there are nearly 400 other services publicly available in custom applications. There are more than 800 candidate services in total. Although this analysis continues, we expect that the number of public services will not exceed 200.

Service ModelThe definition consists of multiple steps. Generally, the results of UML are created accordingly. You can help with this step by using architecture tools such as Rational Software Architect and UML Profile for software services. During this step, the service model is designed by recording service dependencies, defining service combinations, recording non-functional aspects of the service, defining the advanced service message model, and specifying the status management requirements.

Service implementation

As the last major activity in Soma, service implementation defines the service allocation of components and the distribution of these components to the implementation solution. For example, a service may be implemented by using an EJB exposed as a web service, while another service may be implemented by packaging one or more CICs transactions, in addition, services may also be implemented by providing the j2c interaction mode adapter.

Back to Top

Practical Application

During the discussion, we have covered three core areas: Enterprise Architecture, business component design, and SOA analysis and design through Soma. The relationships between these three fields are shown in the following figure:

Figure 4. Three core fields of Soma

The relationship between strategy and evaluation in the enterprise architecture and core organization competitiveness analysis will lead to the emergence of a group of advanced business and IT requirements. These requirements, in turn, form the initial step basis for SOA design business requirements.

As shown in figure 4, this process is actually iterative. As new market trends start to shape the enterprise architecture or change the organization's core competitiveness, these changes require an analysis of their impact on the overall service design. In addition, the steps in the Soma service modeling process are iterative. As we develop service models or begin to consider various aspects of service implementation, we may eventually return to the decisions made in the previous design work.

In Grady booch's developerworks blog, he gave a very incisive comment:

In my opinion, the value proposition of SOA comes from a: architecture ). It has reliable and proven value in terms of the governance and development system architecture. In addition, it must make some difficult choices, many of these decisions cannot be viewed as forward-looking (for this reason, the process is so important to release executable versions with regular incremental iterations ).

Conclusion

Project-based SOA solutions usually adopt a bottom-up and technology-centric approach to help you get started with SOA design and development. However, from the perspective of enterprise architecture, its benefits are very limited.

By designing an SOA solution using a business-centric approach, business needs can be linked with the IT development process at the enterprise level. By defining SOA as the main supporting architecture, it can provide a reliable basic platform for enterprise solution development. This implementation of SOA as a core enterprise solution allows you to define requirements and determine their scope based on the core competitiveness of your organization. Using these business and it needs as inputs, you can use service development methods such as Soma to design SOA solutions in the best way. This method of designing an SOA solution provides an enterprise-level view of services, shortens the time to market new applications, and reduces the reuse of public IT resources through services. More importantly, business-centric SOA solution design ensures the relevance between SOA and the organization and its value to the organization.