- The target service-oriented architecture can be reached by means of several realization scenarios
- Multiple business aspects need to be addressed
- Non-functional aspects of a SOA need to be addressed while procuring and deploying packaged applications
- Non-functional business need can be articulated using a trade-off model
- Criteria can be derived based on several aspects of SOA reference architectures
- Downloadable resources
- Related topic
Selection criteria for packaged applications in service-oriented architecture environments
Towards packaged application selection for service-oriented architecture
Packaged application implementations in service-oriented architecture (SOA) environments are often based on consensus decisions. This does not always result in meeting the business need to the full extent. The consensus is often a balance between a make versus a buy scenario. On the one hand, the make scenario allows for a full functional match and business agility implemented by custom developed components. On the other hand, the buy scenario facilitates the use of standard and matured processes that are incorporated by off-the-shelve packaged applications.
Due to the complexity of describing all aspects of the business need in an unambiguous way, it is a challenge to set selection criteria for packaged applications in SOA environments. This leads to the following question: how should criteria for selecting packaged applications be set for SOA environments to cater for all business needs in order to make the deployment of packaged applications a success?
Selection criteria for packaged applications in SOA environments need to cover non-functional business aspects on top of the functional business aspects. There are a couple of reasons to take the non-functional business aspects seriously. Firstly, target service-oriented architectures can be reached by means of several realization scenarios; each introducing specific non-functional business aspects. Secondly, multiple business aspects need to be addressed to achieve true service orientation. Thirdly, during procurement and deployment of packaged applications, the non-functional aspects of service orientation need to be addressed as well in order to realize the promises of service orientation.
These aspects will be treated separately by next three sections. The last section provides for practical guidance to set selection criteria for packaged applications in a SOA environment.
The target service-oriented architecture can be reached by means of several realization scenarios
More architectures become service-oriented. There are several ways to realize the target—or to-be—service-oriented architecture, being: developing new components, reusing applications of the existing enterprise landscape and deploying packaged applications. These three ways can be combined to reach the target service-oriented architecture. However, there are several, different aspects that need to be thought of.
When developing new components it is important to adopt SOA standards, for example, in the area of interoperability and security. A lot of results have been achieved in the SOA arena to standardize development and integration of components that become part of the architecture.
The reuse of existing enterprise applications and the deployment of packaged applications introduce architectural decision points. These architectural topics initially appear in the integration and interoperability domain, where decisions have to be made regarding integration styles—or better integration options.
When integrating existing applications, the integration styles can vary from—without being complete here—screens scraping, batch-oriented processing, message-oriented integrating and service wrapping. Interfaces are considered as a given when re-using existing enterprise applications. When procuring and deploying packaged applications, it seems that there are more possibilities to set the integration style of the overall architecture. However, the ambition level of integration must be communicated in the form of selection criteria when procuring packaged applications in order to be successful in realizing the target integration style.
Multiple business aspects need to be addressed
It is good to realize that multiple business aspects need to be addressed to achieve service orientation. Benefits as business and IT alignment and business agility are not reached by functional decomposition only. There is no doubt that process-based functional decomposition is a pragmatic technique to identify the services and components needed to meet the function business requirements. However, there are certainly more aspects in meeting the expectations of the business. These other aspects have often a non-functional character.
This article introduces terminology to distinguish between several business aspects: functional and non-functional business requirements. The word business before the word requirements is carefully chosen here. This distinction between functional and non-functional business requirements is not the traditional distinction as meant between functional and non-functional requirements.
Functional business requirements are the traditional functional requirements expressing the wants and needs to be fulfilled by the system. These business requirements are oriented towards processes and use cases. The services can be identified by process and use case analysis and can be mapped to repeatable business tasks.
Non-functional business requirements describe other needs that are at least of equal importance to the business. They describe the ambition level for aspects like business agility, business concept extendibility, and business auditability. These non-functional business requirements results in decisions regarding the granularity of, for example, process orchestration, repeatable business steps (services), the service component deployment model, and the service test plan. Besides the non-functional business requirements, traditional non-functional requirements like availability, security and performance still play an important role. The non-functional business requirements should be seen as additional aspects to be addressed to achieve full service orientation. Figure 1 shows a categorization of requirement types. Here the positioning of the mentioned non-functional business requirements is illustrated in relation to other types of requirements.
Figure 1. Categorization for requirement types
An established viewpoint in today's industry is that well defined functional business requirements is a pre-requisite for obtaining a successful solutions. Defining functional business requirements using modelling and definition language is getting common practice. Examples of functional modelling and definition language are use case modelling based on UML and process definition language based on Business Process Management Notation (BPMN), respectively.
However, the need for adequately articulated non-functional business requirements in order to execute successful projects is not always perceived as critical yet. The availability of modelling and definition language to articulate non-functional business requirements is lacking behind. The next section will introduce some guidance for it.
Non-functional aspects of a SOA need to be addressed while procuring and deploying packaged applications
From a helicopter view, there are basically two approaches to bring the description of non-functional business requirements to a higher level. One approach is using value trade-off models like manifestos and application integration paradigms. The other approach is to articulate the qualities and constraints of the new business system based on the aspects that a SOA reference architectures introduces. These two approaches will be treated in the next sections.
Non-functional business need can be articulated using a trade-off model
The SOA manifesto is selected here as trade-off model to better understand the non-functional business requirements (The SOA Manifesto Authors). The SOA manifesto describes the trade-offs of several design dilemmas. These design dilemmas are expressed by means of putting two design values in front of each other. The dilemma includes a statement which value is preferred for SOA environments. Subsequently, principles are derived from these SOA manifesto dilemmas.
The following principles of the SOA manifesto are relevant during the process of selecting packaged applications:
- Separate the different aspects of a system that change at different rates.
- Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change.
- At every level of abstraction, organise each service around a cohesive and manageable unit of functionality.
- Pursue uniformity on the outside while allowing diversity on the inside.
These principles are treated in relation to non-functional requirements in next subsections.
Separate the different aspects of a system that change at different rates
Separating parts of a system based on different change rates can be achieved by layering the architecture of a system. If the overall system includes packaged applications, the layering and components of the architecture of the packaged application is a point of attention. Ideally, the layers and components of the package application can be configured individually. Then, different parts of the packaged application can be adapted to the varying business needs without changing the whole constellation of the packaged application and deploying a new configured set-up.
Due to different reasons, some parts of the packaged application are required to be changed or reconfigured at a higher rate than other parts. Therefore, layering and componentization of packaged applications is an important non-functional business requirement. In this way, business agility for the total system scope can be obtained.
Reduce implicit dependencies and publish all external dependencies to increase robustness and reduce the impact of change
Reducing implicit dependencies and especially publishing external dependencies is a very important non-functional business requirement for packaged applications. In this way the robustness of the overall system can be achieved and the impact of changes can be decreased. While applying this principle in the SOA environment, it is important to understand the constraints and implicit dependencies that packaged applications introduce to the rest of the architecture. Examples of dependencies can be the mandatory order of invocation of services of the packaged application. These dependencies need to be expressed by adequately defined pre-conditions of the services.
Package application selection criteria need to include the statement that dependencies of services are articulated adequately using a uniform and comprehensible description language.
At every level of abstraction, organize each service around a cohesive and manageable unit of functionality
Organizing services around cohesive and manageable units of functionality is about layering and componentizing systems in order to obtain separation of concerns. The packaged application should ideally be componentized as mentioned earlier. This goals of this principle is to achieve an overall system—including the packaged applications—that consist of units around highly related functionality. In this way the packaged application is manageable and less vulnerable for change.
Pursue uniformity on the outside while allowing diversity on the inside
The reason to pursue uniformity on the outside while allowing diversity on the inside is to obtain an environment where components can be invoked in a uniform and standard way without compromising implementation variety. The guidelines for implementation of the internal functionality can be loosened as long as the invocation standard is used. This principle is very applicable for packaged applications, since implementations of functionality can vary. As long as the invocation standards are adhered to by the packaged applications, the functionality can be utilized by external components in a uniform way . An example of a standard to specify outside uniformity is the standard and best practices established by the Web Services Interoperability Organization (WS-I).
Criteria can be derived based on several aspects of SOA reference architectures
Another important source for deriving non-functional business requirements and selection criteria are SOA reference architectures. With the help of a layered architecture several non-functional aspects can be addressed. In this way the layers of the reference architecture can be used as an aid for identifying non-functional business requirements. The layering can also be used as a categorization of the list of non-functional business needs and respective selection criteria.
The first subsection will introduce a SOA reference architecture. Then typical non-functional business aspects addressed by several architecture layers will be treated.
Introducing a SOA reference architecture
Figure 2 shows an overview of a SOA reference architecture consisting of 5 horizontal and 4 vertical layers being the resources layer, service components layer, services layer, business processes layer, consumer interfaces layer, integration layer, quality of service layer, information layer and the governance layer. This layered reference architecture is based on The Open Group Reference Architecture. Refer to SOA reference architecture website of the Open Group for a detailed description of the layers of the architecture (The Open Group SOA Reference Architecture Authors 2009). This architecture is well adopted in the industry. The layers of this architecture can be used to identify and categorize non-functional business requirements.
It is important to note here that packaged applications itself are positioned in the resources layer. Nevertheless, the layers of the reference architecture are used here to derive non-functional business requirements for the selection process of packaged applications. In other words, the reference architecture is used as a thinking model to identify applicable non-functional business aspects and respective selection criteria. The following sections describe examples of non-functional business aspects which can be mapped to a certain layer of the SOA reference architecture.
Figure 2. Layered SOA reference architecture
The process management aspect is treated by the business processes layer of the introduced SOA reference architecture. Process management plays an important role in both business agility and business optimization.
With respect to business agility, the invocation of repeatable business steps is orchestrated by a process engine defined by process templates. Adaptation to the invocation order of business steps and applicable business rules can be implemented by changing the process templates.
Regarding business optimization, the process management capability includes an optimization cycle consisting of process modelling, process orchestration, process monitoring and process model adaptation.
When applying packaged applications, two scenario's can be distinguished to achieve business agility and business optimization.
The first scenario is that the respective package application includes an internal process management capability. In such a case it is important to derive non-functional requirements for this internal business process management capability. The internal processes and business rules of the packaged application should be adaptable by means of configurable models and parameters. It is also important that the internal process of the package application could be integrated with the end-to-end processes of the overall system. End-to-end process integration enables overall chain monitoring and optimization. Note that the respective packaged application itself could cover the majority of the end-to-end process. This will introduce the variance to the described scenario where the process engine of the packaged application orchestrates the end-to-end process.
Selection criteria that need to be derived from this non-functional business need is that internal processes of the packaged application are adequately described by standard process notation like the Business Process Modelling Notation (BPMN) and standard process implementation language like Business Process Execution Language (BPEL). In addition, the packaged application should be able to send business monitoring events according the enterprise event infrastructure standard—or receive business monitoring events in case the packaged application process engine orchestrates the end-to-end process. Exchanging business monitoring events with the process monitoring engine, that are according predefined process definitions, enables tracking of the end-to-end process including the part that is encapsulated by the packaged application.
The second scenario is that the packaged application exposes repeatable business steps that can be invoked by an external business process management engine. In such a case, it is important that the package application offers repeatable business steps by means of well described services. Service definitions is the subject of next section.
Service definitions are treated by the services layer of the SOA reference architecture. Service definitions describe the functionality of the repeatable business step, the invocations details and pre-conditions. Well described services are a key factor in achieving re-use. Therefore the clear definition of functionality itself is an important non-functional business requirements.
A selection criterion for a packaged application, that can be derived from this non-functional business requirement, is the use of standards to describe the services offered by the packaged applications. An example of a standard for defining services is Web Service Description Language (WSDL) (The Web Services Description Language Authors). An example of services access protocol is Service Object Access Protocol (SOAP) (The Service Object Access Protocol Authors).
Service components are treated in the service components layer of the SOA reference architecture. Service components are realizing the functionality as defined by the service interface. Service components itself can rely on other functional and technical components. In general, componentization of a system brings agility within the business solution, because it enables adapting and configuring components.
The success of achieving business agility highly depends on the granularity of the components structure. General statement is that a finer grained component structure provides more opportunities to configure and to align with repeatable business steps than course grained structures. The extent in which the component structure can be augmented with new components is an important aspect as well in achieving business agility. It depends on the business ambition whether packaged applications should have an adaptable or configurable componentized structure. It is in most cases a trade-off between deploying standard off-the-shelve solutions or developing a custom business services landscape.
When the business ambition is to extent component level agility to the packaged applications, selection criteria must be set that express the need for adaptability or configurability at component level.
Future development is an aspect as well. Ideally, the packaged application will fit the overall release management philosophy. When the overall release management and test philosophy demands a software promotion process at component level, the packaged application should facilitate a testing and a production-live process at component level, as well.
The data aspect is positioned at the information layer of the introduced SOA reference architecture. In SOA data is encapsulated by services. Nevertheless, a conceptual enterprise entity model is often a first step in understanding the business objects and their interrelation. The entity model is the basis for deriving the canonical message model consisting of all exchange messages between the service component architecture (SCA) elements of the solution.
Since packaged applications introduce a data model as well, business entity model alignment should be considered. From an integration perspective, the canonical interchange message model needs to be extended to reflect the new business entities that the new packaged application introduces. Middleware technologies—like message brokers—or master data management solutions help to overcome these challenges. At a more technical level, the format and implementation of the exchange messages needs to be considered too. When the exchange messages are implemented by Extensible Markup Language (XML) and defined by XML Schema Definitions (XSDs), the declaration style of elements and types—global versus local declaration—can become an aspect depending on how strict the packaged application should adhere the enterprise-wide preferred declaration style.
The major part of the service integration subject is dealt with by the integration layer of the SOA reference architecture. The integration mechanism of SOA is based on discovery of services—either statically or dynamically. It requires well definition of services in the first place as described in the section on service definition.
The implementation of service discovery and binding is based on a service registry capability within a SOA. Therefore non-functional requirements must be set for a packaged application to deliver service definitions that can be listed in the enterprise-wide service registry—or cooperating service registries. The criteria for the selection process are typically similar as the criteria that were introduced in the section on service definition.
In case the packaged application has the role as service consumer and invokes enterprise services, it must be able to utilize the enterprise-wide service discovery and binding mechanism.
In a heterogenous environment the activity coordination between services can become an issue. When the packaged application collaborates in such common activity, it is important to agree a coordination framework at enterprise level. All parties including the packaged application should adhere to this coordination framework to maintain integrity of the transactions. An example of a widely established framework in the industry is the cooperation of Web Service Coordination (WS-Coordination), Web Services Atomic Transaction (WS-AtomicTransaction) and Web Service Business Activity (WS-BusinessActivity) accepted by OASIS Web Services Transaction (The OASIS Web Services Transaction Authors).
Besides regular quality aspects like availability, scalability, throughput and reaction time performance, the quality of service layer deals with security aspect of services.
Service security requirements could be set at enterprise level according an identity authentication and authorisation philosophy, like single sign-on (SSO) implemented by means of identity and authorisation passing between services using tokens. A decision must be made whether packaged applications should adhere to the enterprise-wide security implementation style strictly. If so, the selection criteria should reflect these security requirements. It is recommended to make use of industry standards when defining the selection criteria. An example of a widely accepted standard is the Web Services Security published by OASIS (The OASIS Web Services Security Authors).
The service governance aspect is treated in the vertical governance layer of the SOA reference architecture. The key elements of service governance is the definition and deployment of the service ownership model, service funding model, service change model and the re-use stimulus model. For the SOA environment it is important to assign owners and sponsors to (groups of) services. It is advised to define the re-use and change model aligned with the business goals.
A successful deployment of service governance model must be considered as a non-functional business need. These non-functional business requirements are applicable to the deployment of packaged applications as well and need to be expressed by selection criteria to be applied during the procurement process. An example of a selection criterion is that the service structure of the packaged applications can be mapped to the granularity of the service ownership model. Another example of a criterion is that the services structure of the packaged application can be integrated in the service life cycle that is managed by the enterprise-wide service repository.
The author would like to gratefully thank Gerard Alderden for reviewing this paper thoroughly.
- The OASIS Web Services Security Authors. OASIS Web Services Security (WSS) TC. Organization for the Advancement of Structured Information Standards (OASIS). (accessed June 15, 2010).
- The OASIS Web Services Transaction Authors. OASIS Web Services Transaction (WS-TX) TC. Organization for the Advancement of Structured Information Standards (OASIS). (accessed June 15, 2010).
- The Open Group SOA Reference Architecture Authors. 2009. The Open Group SOA Reference Architecture. The Open Group. (accessed June 15, 2010).
- The Service Object Access Protocol Authors. SOAP Version 1.2 Part 1: Messaging Framework (Second Edition). World Wide Web Consortium (W3C). (accessed June 15, 2010).
- The SOA Manifesto Authors. SOA Manifesto. http://www.soa-manifesto.org (accessed June 15, 2010). The Web Services Description Language Authors. Web Services Description Language (WSDL) 1.1. World Wide Web Consortium (W3C). (accessed June 15, 2010).
- Web Services Interoperability Organization. (accessed June 15, 2010).
- Evaluate IBM products in the way that suits you best.