SOA Reusability: Shrinking the Lag between Business and IT Blog


    Today there is no shortage of articles, case studies, and analyst research concerning service oriented architecture (SOA), discussing the benefits of exposing existing IT capabilities as services and reusing these services to create composite applications. However, in their articulation, they are missing how these benefits will be useful to the ultimate end user, analysts. Since SOA projects are all about business and IT alignments, support from these business end users is a key to successful SOA adoption efforts in any enterprise. Many SOA projects fail when IT doesn't look at the business side of an SOA solution and business doesn't see SOA as important.

    This article articulates the vision of reusability with a different spin around the business users, the ultimate end users of SOA. The objective of this article is to help the SOA architectural team in two ways: understanding the significance of creating generic and configurable services, and explaining reusability benefit of SOA to business users. This article delivers the message that an ultimate goal of SOA should be a near-zero dependency of business users on IT teams to implement new plans, products, or services based on information-based systems.

    The Evolution of Reusability

    Reusability has been a goal of application development for the last three decades. This evolution of reusability, as shown in Figure 1, started with mnemonics used to represent opcodes, machine instructions executed by the processor. Then came the subroutines, where a repeatedly used set sequence of steps in a larger program are put into independent and reusable modules, and then logically related subroutines are grouped into subroutine libraries. This was followed by object oriented programming and software components with stronger emphasis on modularity and offering more advanced form of reusability. The latest design architecture in this evolution of reusability is service oriented architecture (SOA).

    Figure 1. Evolution of reusability
    Figure 1. Evolution of reusability

    The major difference between service oriented architecture and previous design approaches is that the implementation of design architecture as compared to SOA was tightly tied to the specific execution environments, and reusability was mostly limited within the boundary of the IT department. However, with SOA, for the first time in history, this goal of reusability has spanned over the heterogeneous execution environments, crossed the traditional boundaries of the IT department, and reached the business analysts, the ultimate end users.

    The Lag Between Business and IT

    There has always been a lag between today's business needs and its IT deliverables tomorrow, as shown in Figure 2. Let's take a closer look at the current status of business systems to understand this lag.

    Figure 2. IT lags behind business
    Figure 2. IT lags behind business

    Traditionally, each business unit in an enterprise initiated and worked with IT to develop solutions to perform a specific business activity with a specific implementation. Due to a lack of centralized control within the organization, these solutions were reinvented over and over across business units, with the end result that none of them are really reusable. Mergers and acquisitions further fragmented this isolated monolithic architecture.

    As a result, the enterprise ended up with multiple stovepipes having duplicate functionalities. This traditional application landscape of multiple stovepipes was extremely complex and expensive to maintain or extend. So when the business needed a change in systems, IT seemed slow to deliver it.

    Since the applications could not collaborate with each other to exchange data in a business process, both business and IT needed to perform resource-intensive manual processes for tasks like loading data from different data sources, transforming data into the right common format, and checking the accuracy of these data.

    The time lag between business and IT was further fueled by long planning and design cycles due to siloed business owners, and the availability of subject matter experts.

    Thus the maintenance of multiple rigid stovepipes, resource intensive manual processes, and long planning and design cycles caused the lag between today's business needs and tomorrow's IT deliverables.

    Business Processes Before SOA

    In traditional IT organizations, business processes were hard-coded and hard-wired to integrate monolithic applications. Integration of these monolithic applications to enable collaboration and to exchange data was done using middleware, as shown in Figure 3, which shows the integration of a bank's loan approval application with its customer account management system.

    Figure 3. Application integration using middleware
    Figure 3. Application integration using middleware

    Imagine a typical business scenario in the banking industry: an automated loan approval process. In order to frame the business process for the sample scenario, individual applications such as the credit history system, credit score computing application, loan approval application, customer account management system, etc., are integrated to collaborate using middleware, as shown in Figure 4.

    Figure 4. Loan approval business process before SOA
    Figure 4. Loan approval business process before SOA

    Since these business processes were aligned to software functionality, more customization was done to fulfill specific business needs. Hence, business analysts required help from IT to define, change, or optimize business processes. However, changing these rigid business processes required substantial IT effort.

    Thus, changing the business process was a tough business in itself.

    Why SOA?

    SOA is aimed to shrink this lag between today's business needs and when IT can produce deliverables. SOA enables many of these time-sensitive deliveries by eliminating many of the traditional IT hurdles to change, such as rigid business processes, inflexible IT architectures, and incompatible data representations with commitments to continue supporting existing IT operations.

    As the name suggests, SOA is a solution architecture revolving around services, where a service is a standard-based interface encapsulating either a logical unit of functionality or data to facilitate need-based access to computational resources and promote their reuse. These standards-based service interfaces are often described using Web Service Description Language (WSDL), which provides a homogeneous layer of abstraction, hiding implementation specifics of business logic and data for seamless collaboration across the enterprise. The goal is to be more agile by enabling a mix and match of services and connecting them with contextual information to create new discrete business services.

    Service Reuse

    Software reuse is not new inasmuch as the core idea is to get more value from what has originally been built. For the optimal reuse of services, the first step is to find services that will be of value to business. This involves finding where a duplication of effort exists at the enterprise level, and where services should be introduced. The next step is to ensure service flexibility. SOA-based services may be require to expose inflexible business logic or data that were originally developed to solve a specific business issue. In this case, it will take some work to turn these pre-existing business assets into flexible services.

    Now comes the million-dollar question: since there are limited possibilities one can preview or imagine of various contexts in which a service can be used, how do you ensure flexibility? The flexibility of a service is ensured primarily by its three characteristics: genericity, configurability, and extensibility. The generic characteristic promotes service reuse in different business contexts. Being configurable makes a service adaptable to each specific business context. And extensible services help an organization to add to existing services. Services can also be aggregated by other services collaborating together, making it possible to assemble higher-level composite services or business processes.

    The next step is to promote service reuse. Prior to SOA, a lack of centralized control and communication between business units within organizations caused same solutions to be reinvented over and over again. To ensure that duplicate services are not created across the business units in an organization, SOA stakeholders such as business analysts and architects should be able to find existing business services and evaluate their usefulness for reuse in a well-known and systematic way.

    Hence, a centralized registry of services is required for easy discovery and promoting service reuse at the enterprise level. An entry in such a registry provides functional information such as the name of a service, service operations, and service location for its invocation.

    Since services in SOA encapsulate IT assets and represent its business view, the description of a service should include functional information (such as operations, location of WSDL document, etc.) useful to IT, and non-functional information (such as QoS, SLA, and security) understandable to business analysts, without crawling through the WSDL document. Hence, elements of the service are as shown in Figure 5.

    Figure 5. Service Elements
    Figure 5. Service elements

    Since the functional information available in the registry and the metadata in the WSDL document are not sufficient for promoting service reuse to business analysts, an enterprise needs a service repository that provides information about the non-functional offerings (such as QoS, SLA, etc.) of services. The service registry and service repository are integrated together to provide one logical location for the enterprise to categorize and organize services, to browse and search for existing services, and to publish new services.

    The Ultimate Goal of SOA

    The reuse of services and integration of heterogeneous systems are really interim goals of SOA. The ultimate goal of SOA should be that a business user doesn't have to always come to IT to launch new plans, products, or services, or even generate reports based on IT systems.

    Imagine how business would be without IT integration obstacles and with significantly reduced lag between the business needs and IT deliverables. The ultimate goal of SOA should be that an end user needs near-zero help from IT to define, configure, change, or optimize business processes. This lag between business and IT objectives should let the business user actually help design and modify composite applications or business process, in some instances, using graphical tools. Since many business solutions are composed of multiple services that could work well together, let's now think about SOA in the context of defining and changing business processes.

    The Business Process After SOA

    Using a graphical business-process-management modeling tool connected to the service registry and service repository as shown in Figure 6, a business analyst can either go through categories or define the search criteria on various parameters such as keywords or SLAs to locate the available services that can fulfill the needs of the business process. Then he or she can use these available services as building blocks. An easy-to-use, drag-and-drop graphical user interface of this modeling tool enables business analysts to build composite applications or business processes by graphically wiring services together and can orchestrate them as per business needs.

    Figure 6. Business process modeling tool connected to service registry and repository
    Figure 6. Business process modeling tool connected to service registry and repository

    We will now explore the binding pieces in SOA architecture with examples. Let's take the same business scenario we discussed in the Business Processes Before SOA section above, of an automated loan approval process in the banking industry. In order to frame the SOA solution architecture for the sample scenario, we will first list the individual services required, such as the services "get credit history," "calculate credit score," "loan approval," "customer account management," and so on.

    Once these services are identified and placed in the correct sequence, using a modeling tool, the business analyst connects them together and orchestrates the movement of information and the flow of control between services, in a non-programmatic manner, to attain larger business objectives. Since every transaction of fetching a credit history from a credit bureau costs the bank, the business analyst orchestrates business activities in such a sequence where first the SSN and then the address provided by the loan requester is validated before going to the next activity of getting credit history, as shown in Figure 7.

    Figure 7. Loan approval business process after SOA
    Figure 7. Loan approval business process after SOA

    Since SOA abstracts the complexities of the technical integration using open standards providing homogeneous service interfaces, now the business analyst orchestrates the business process without knowing or worrying about technical feasibility, underlying IT infrastructure, or how two applications will exchange information.

    Now let's say that after several months, business analysts discover that the address provided in loan requests are more often invalid as compared to the SSN. So, to optimize the business process, using the graphical tool, the analysts swap the "Verify SSN" and "Verify Address" services. Now the address is validated before SSN. Due to the standardized and loosely coupled integration between services for these two activities, the business analysts can now optimize business processes without any help from the IT staff. The optimized loan approval business process is shown in Figure 8.

    Figure 8. Optimized loan approval business process
    Figure 8. Optimized loan approval business process

    A business analyst may also be able to respond to shifting compliance regulations or business strategy by making minor adjustments to predetermined services parameters rather than moving to new, and expensive, solutions.

    Picture the impact of being able to respond to changes in hours or days rather than weeks or months. Business users will become champions of SOA, because they will finally have the ability to mix and match services to suit their business processes. Freeing business users from the IT department to quickly react to business changes is what makes SOA effective. Don't forget that a governance model is the key to making this happen.


    Buy-in from business owners and management is critical to successful adoption of SOA. The more business relies on IT to get a competitive edge, the more valuable SOA becomes in an organization. Monolithic applications, manual processes, and rigid business processes hindered the productivity of IT in delivering business changes and caused the lag between business and IT.

    We saw that SOA is an architectural solution with key characteristics that distinguish it from previous architectural designs. We also saw that the key principle of SOA is providing business agility by making IT flexible to adapt to changes. Flexible services in SOA, along with the service registry and service repository, provide uniform means to offer, locate, and interact. This promotes and maximizes reuse of services at the enterprise level.

    Thus, the combination of business-process modeling tools and SOA enables business analysts to define, configure, change, and optimize the business process with near-zero involvement of the IT staff. This helps organization to respond and adapt quickly to ever-changing business requirements by shrinking the lag between business and IT.