According to a survey of 277 businesses conducted in the spring of 2013 by CIMI Corporation, about a third run...
major applications more than 10 years old, and a fifth have at least one major application that's largely unchanged for 15 years or more. Fully half of the applications reported in the survey were based on obsolete monolithic architectures or used Web services only as a front end to a large application.
Since the same survey showed 88% of CIOs believed service orientation was the single most important architectural key to a successful application, it's not surprising they thought application modernization should focus on a service approach. To make that happen, they should align application services to enterprise architecture (EA) functional/process designs. In addition, they must both think in Business Process Execution Language (BPEL) for high-level composition of services and componentize services below BPEL, based on software architecture goals.
Modern software should be broken down into components for reuse and functional agility, and made distributable for optimum resource efficiency in virtualization and the cloud. For more than a decade, this has been accomplished by defining functional software elements as services that provide support to business operations.
The most common blunder has been failing to align services to operating processes—something EA integration can provide. At the top of an as-a-service model is the functional and process design portion of EA, which (if the work is done properly) will define the high-level services that support each critical business process.
When a functional and process design review is conducted, it will identify the highest level of function aggregation in an enterprise—the system of services that combine to help workers do something specific. Most companies find this level corresponds with the notion of an application, which is a workflow composed of a number of software services or components and a set of binding rules. Your modernization of applications begins by defining the business-driven boundaries the applications must conform to.
Using BPEL in app design
Application component or service binding rules are often expressed for SOA applications in BPEL, and even companies who aren't enforcing strict SOA discipline can benefit from using BPEL-like app design of their services to help identify the way in which services and components will be grouped to create applications.
The goal in BPEL is to express business logic as workflow steering, which orders and identifies services used to create applications. As an application architect, if you think of a business process as being a set of steps, then each step is a service at the BPEL level, and that defines your first level of making a modernized application serviceable of a modernized application. Business functions decompose into applications, which decompose into BPEL services.
Below the BPEL layer, the business drivers of service and application structure diminish in comparison to the technical factors that guide service decomposition and deployment. Too much componentization of services creates excessive overhead in workflow management that can significantly impact application response times and worker quality of experience.
It's critical to test workflow or service bus engines to see how they perform at various levels of transaction activity, for each level of componentization under consideration. In some cases, lower-level services can be directly coupled to avoid bus overhead, though this will make the application less flexible.
One factor that can offset efficiency concerns at this next layer is component reuse benefits. A large monolithic service may not be as bad as a monolithic application, but the distinction isn't very meaningful. Another factor to consider is the impact of further component creation on application lifecycle management (ALM).
Increasing the number of services per application is justified if component reuse generates a significant benefit in simplification of development, and on through the whole ALM cycle. Obviously, one factor is the extent to which component reuse is possible.
Whether component reuse creates a benefit depends on how often the components are changed. If components are largely static and combined in only a few ways, it may be smarter to leave them as multiple higher-level services than to break them down. If components are highly dynamic and used in multiple places, breaking them out can generate efficiencies in ALM.
Can is the operative word because many users don't have ALM practices reflecting componentization well. Some of this is due to the fact that ALM tends to focus on testing against business processes, which demands it be elevated to the highest level and obscures componentization. If services are not properly designed, they can't be assumed to work in all contexts and thus have to be tested in context for each application that uses them.
Well-configured services have properly designed APIs. This means they have an ability to define specific services, are strongly typed, have explicit error handling and feature checked data models. In addition, they have failsafe interactions based on either RESTful processes or on processes with very clear state control.
If the service interfaces are "tight," ALM can do the following:
- fully test changed services
- check basic interface integrity on the derived applications
- be passed to production
Otherwise, a full test will be required for every application where service change is found and benefits of service reuse will be reduced.
Remember that service may mean SOA in its most general sense, but not necessarily SOAP-WS coupling. Service orientation can be created and sustained using purely RESTful interfaces, even if application architects use a BPEL-like description of high-level coupling of the business process to the application.
That description can be used to guide workflow, but can also be seen as a documentation tool to systematize the design of RESTful Web-like processes. The best result in application modernization is always created by the most structured approach.
About the author:
Tom Nolle is president of CIMI Corp., a strategic consulting firm specializing in telecommunications and data communications since 1982.