SOA Reusability: Shrinking the Lag between Business and IT
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, i.e.
business 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
"Figure 1. Evolution of reusability" width="447" height="350" />
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
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
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
"Figure 3. Application integration using middleware" width="448" height="76" />
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
"Figure 4. Loan approval business process before SOA" width="451" height="169" />
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
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.
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
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
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
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" width="453" height="262" />
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" width="453" height="208" />
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
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" width="453" height="208" />
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
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.
- " "http://today.java.net/pub/a/today/2006/04/04/understanding-service-oriented-architecture.html">Understanding Service Oriented Architecture"
and Web Services"
|width="1" height="1" border="0" alt=" " />|