 | Level: Intermediate Scott M. Glen (scott.glen@uk.ibm.com), IT Architect, IBM
Jens Andexer (andexer@uk.ibm.com), Certified IT Architect, IBM
04 Oct 2007 Over the last few years, Service-Oriented Architecture (SOA) has received a
lot of attention, bringing with it a new age of software development and business
agility. However, SOA alone doesn't solve the world's IT problems. We still need
solid and effective software engineering practises, as a poorly managed SOA
implementation can go as wrong (if not more so) as any other architectural
approach. This article presents a practical view to SOA, from both the technology
and business perspectives, and presents a case study drawn from real-world
experiences, showing the benefits that can be achieved through a successful SOA
implementation.
Behind the myth
There is currently no single definition of an SOA, but the architectural goals of
flexibility and business agility give rise to the following broadly accepted,
high-level definition:
The architecture style defining an SOA describes a set of patterns and
guidelines for creating loosely coupled, standards-based business-aligned services
that, because of the separation of concerns between description, implementation,
and binding, provide a new level of flexibility in responsiveness to business
threats and opportunities.
| |
In Darwinian terms, SOA is the natural evolution of previous distributed
architectural styles, such as distributed component object model (DCOM), Common
Object Request Broker Architecture (CORBA), and Enterprise JavaBeans (EJB), but
embraces standards, particularly those based around XML, to provide a greater
degree of interoperability. There's also an explicit emphasis on business
alignment, which wasn't prevalent with previous architectural incarnations. This
lets SOA provide an ideal platform for business process-driven development,
enabling business analysts to truly participate in the software development life
cycle—one of its biggest differentiators.
However, simply adopting SOA alone doesn't guarantee a successful project (ESB
does not stand for enterprise silver bullet!), and some projects should not adopt
an SOA approach at all. We've heard people describe bad architectures and failed
projects and say "SOA would have fixed that." But it's just as easy to misuse SOA
as it is to create a clunky Java™ 2 Platform, Enterprise Edition
(J2EE)-based architecture. If the early implementations of EJB failed, it was
because some architects didn't really understand the limitations of the technology
(those who have witnessed an application load hundreds of container-managed
persistence [CMP] entity beans into memory as the result of some kind of database
search know what I'm talking about). But it's just as easy to do the same with
SOA. Adopting a similar carte blanche philosophy with services has led to
applications that use Web services internally for every single application
function call—not exactly a performant solution!
Thankfully we seem to be learning from those painful lessons of the past. For
example, the knowledge gained in creating patterns and associated antipatterns
that emerged from J2EE experiences has been used to construct similar best
practices around SOA. IBM® has been successful in developing reusable
patterns and blueprints for SOA applications and industry-specific models that aid
in architectural decision making and provide methodologies for service
identification.
Using such artifacts can have a dramatic impact on the costs of introducing an
SOA. As with any new technology, there are associated start-up costs, and SOA can
appear to be additionally front loaded. The emphasis on reuse and flexibility
comes at a cost, and this can provide little motivation to evangelize SOA at a
project level, where the benefits won't necessarily accrue to the project.
Pattern-based accelerators and off-the-shelf assets can help reduce lead time, but
ultimately there needs to be a degree of investment in an initial SOA project.
Evidence does, however, suggest that organizations embarking on the SOA journey
will see those costs returned in the medium term as subsequent SOA projects across
the enterprise extend and reuse elements of the service catalogue, reducing their
development costs.
SOA perspectives
When trying to answer the question, What is an SOA?, it's important to
consider the perspective of your intended audience, which generally falls into one
of two categories: IT or business. Depending on where they stand, they'll
potentially have different motivations for adopting service-oriented concepts and
see a very different set of potential benefits and pitfalls.
Each perspective provides a set of on-ramps outlining the approach and
justification for adopting the technology. There's no definitive way to start the
SOA journey; SOA isn't prescriptive, it's all about flexibility, not only in the
end result, but in the path that should be followed.
Let's look a little closer at these two viewpoints.
The IT perspective
From an IT viewpoint, an SOA defines a software architecture that comprises
loosely coupled distributed components cooperating through a communication
conduit, which enables the construction of composite applications. SOA aims to
bring about component reuse, irrespective of implementation language or host
platform, and as such can be thought of as simply an extrapolation of good
software engineering practices, taking us from class reuse to service
reuse—a true component architecture.
If services are a natural step forward in the development of component-based
architectures, then the enterprise service bus (ESB) that links them can be seen
as an evolution of the hub-and-spoke integration style. The ESB removes the hub as
a single point of failure and brings scalability, intelligent routing, security,
and mediation, all based on SOAP and WS* open standards.
So what does this new technology give the IT professional?
-
Component architecture: This provides a flexible, platform- and
language-independent means of building scalable and reusable software
components.
-
Loose coupling: The use of an ESB provides an ideal vehicle to loosely
bind the service consumer and provider, removing all traces of point-to-point
interfaces.
-
Utility services: These let you build libraries of reusable IT services
providing, for example, an e-mail service, credit card service, and so on, which
become enterprise assets with the SOA.
-
Legacy enablement: Whilst the norm is to use SOAP/HTTP, a service
doesn't necessarily have to be a Web service. Native applications and legacy
systems can be full participants in an SOA, using, for example, Java Message
Service (JMS) to hook into an MQ cluster on an IBM iSeries® platform,
revitalizing a legacy RPG application.
-
Platform independence: The adoption of standards has been key within
SOA, enabling previously incompatible technologies to work cooperatively across
a range of platforms.
These features provide immediate technical advantages that can often create an
on-ramp for the introduction of SOA thinking, particularly in the small and medium
business (SMB) space where IT often drives the introduction of SOA. This approach
can be realized at an individual project level, and whilst some SOA aspects may
not bring immediate benefits, the success of a single SOA project can lead to the
organic proliferation of the technology throughout the enterprise.
Indeed, the adoption of SOA in this way benefits not only IT, but indirectly aids
the business. As more SOA projects are deployed, the benefits of this approach
will become apparent:
- Greater component reuse should lead to a reduction in development effort and
an improvement in IT project delivery.
- The use of interfaces to isolate specific operational systems should provide
greater flexibility in business planning.
- The removal of point-to-point connections should ease the introduction of new
business systems.
These factors reduce risk and cost, and lead to greater business agility; however
these are ultimately IT lead initiatives—the business is not in control.
The business perspective
|
Business process management
In
November 2006, Gartner predicted 2007 would see "business process management become the
driver for SOA implementations," with analysts urging "business to adopt process
architecture" now if they want to take a leadership role in this trend (from
"Garner Predicts 2007: Align BPM and SOA Initiatives Now to Increase Chances of
Becoming a Leader by 2010"). |
|
The
2006 IBM Global CEO survey (see Resources for a link),
encompassing over 750 CEOs from around the globe, found that 87% of CEOs believe
that fundamental change is required in the next two years to drive innovation. Roy
Schulte, a distinguished analyst at Gartner, captured these sentiments by
suggesting that "applications were built to last; now they are built to change."
So what does SOA offer business to manage this change? If you refer back to the
definition of SOA earlier in this article, it might be
difficult to see how to ignite business interest; loosely coupled,
separation of concerns, and architectural style are all very
IT-centric terms. However, the key word in the definition from a business
perspective is flexibility.
More than ever before, business must be able to adapt quickly to changing
business conditions. IT architectures are moving towards an integration model,
building business processes that span multiple operational systems, and linking
off-the-shelf products with legacy systems. SOA provides the flexibility to
support that model and, in particular, provides an ideal platform for embracing a
key differentiating technology: business process modeling (BPM).
Through tooling such as IBM WebSphere® Business Modeler, business analysts
can graphically define and model business processes. But this is more than a
documentation exercise; the artifacts generated by WebSphere Business Modeler can
be expressed in the Business Process Execution Language (BPEL), an XML vocabulary
that can be imported into tools, such as IBM WebSphere Integration Developer.
Here, solutions can be assembled by wiring together business services (or more
accurately their interfaces) to the tasks in the business process. The process
doesn't care about the implementation of the underlying services or the
technicalities of their interface, simply that it fulfills its requirements.
This approach to building software solutions provides clear benefits to the
business, which is evident through the following elements:
-
Business-driven development: Business analysts lay the foundations for
the software development without concerns for technicalities.
-
Enterprise-wide solutions: The solutions are explicitly designed to
span multiple lines of business rather than being driven by the availability of
specific IT systems.
-
Reusable business components: You ultimately construct a portfolio of
reusable off-the-shelf business services (try asking the IT department of a
typical insurance company how different implementations of the create
policy function they have).
-
Performance indicators: Although not mentioned in this article, the use
of BPEL enables key performance indicators (KPIs) to be embedded within the
process. These can be used to provide business with intelligent feedback on the
state of the system.
-
Business agility: IT is focused on providing business value and
agility. The impact of changing demands on the business can be minimized and
absorbed by rewiring business components rather than wholesale application code
changes.
The end result is business analysts effectively defining software processes that
are aligned to the needs of their business units and built on an agile
environment, thus capable of absorbing the impact of change. Business is in
control.
Industry models
Along with the development of business process models has come a number of
supporting industry standards aimed at simplifying interoperability and promoting
process and service reuse between IT systems and business partners. The finance,
insurance, and healthcare sectors have all seen developments in this area, but
this article examines a number of telecommunications-related standards, which are
of particular interest to the case study explored later
in this article. These initiatives, some outlined in the following sections,
provide detailed guidance, at both business and technology levels, on industry
best practices and enable software tooling to be aligned with industry models.
Enhanced Telecom
Operations Map
The enhanced Telecom Operations Map (eTOM), part of the Next Generation Operation
Systems and Software (NGOSS) program governed by the TeleManagement Forum (TMF),
is fast becoming the accepted standard for business processes in the
telecommunications industry. It serves as a domain analysis reference map and is
emerging as the common business language of the telecom industry.
The eTOM uses a hierarchical model, repeatedly decomposing business components
through a number of levels until they can be expressed with a suitable level of
detail. At the highest conceptual level, eTOM defines three broad functional
areas:
- Operations
- Enterprise management
- Strategy, infrastructure, and product
By decomposing these entities through three successive iterations, you can build
a component map of the enterprise, identifying the basic building blocks and
ultimately the processes, required by a service provider. Within each of the above
functional areas, eTOM provides the following three levels of decomposition:
-
Level 1 refines the level 0 entities, such as operations, into more
specific functional areas, such as customer relationship management (CRM),
service management, and resource management.
-
Level 2 provides a further level of decomposition into specific
processing areas, such as order handling or loyalty retention.
-
Level 3 begins to define the typical business activities that may be
conducted within the level 2 entities, such as issuing customer orders,
authorizing credit, and tracking order handling.
This hierarchal approach is illustrated in Figure 1, which presents a level 2
decomposition of the operations model, highlighting the order-handling component
within the Customer Relationship Management level 1 entity.
Figure 1. eTOM operations level 2
decomposition
eTOM V6.0 levels 1 to 3 have been fully implemented in WebSphere Business
Modeler, as shown in Figure 2. Here you again see the hierarchal decomposition
within the operations area, focusing on the same Customer Relationship Management
level 1 entity highlighted in Figure 1.
Figure 2. eTOM operations level 2
decomposition
The WebSphere Business Modeler project hierarchy view shows the four level 1
components, and expands Customer Relationship Management to ultimately display the
definition of the Determine Customer Order Feasibility level 3 process. Each
modeled artifact is associated with an identifier that follows a standard TMF
naming convention.
As these processes have been modeled within WebSphere Business Modeler, they can
be assembled and ultimately deployed as part of an SOA. Furthermore, they have
been extended to include a fourth level, which defines the service interfaces
necessary to fulfill the requirements of the associated level 3 processes, as
highlighted in Figure 2. Together this provides a skeletal
implementation for an entire telecommunications operation and provides a blueprint
to an accelerated SOA development path.
Shared Information/Data
If the eTOM helps standardize the processes within telecommunications operations,
then the Shared Information/Data (SID) model, also part of the NGOSS program,
provides a common vocabulary defining more than 1,000 industry standard business
entities. Initially defined using the Unified Modeling Language (UML) and later
through an XML Schema Definition (XSD), these definitions are now available as
business items within the IBM SOA tooling, enabling them to be used within process
models and provide a basis for defining service interfaces.
The benefit of using the NGOSS SID and its common information language is that it
enables business benefits relating to cost, quality, timeliness, and adaptability
of enterprise operations, letting your enterprise focus on creating value for its
customers.
Telecom Application Map
The Telecom Application Map (TAM) effectively provides a bridge between the NGOSS
framework building blocks (eTOM and SID) and real, deployable, potentially
procurable operational systems by grouping process functions and information into
recognized Operation Support Systems (OSS) and Business Support Systems (BSS)
applications or services.
Whilst there can be no categorical solution in this area, the TAM provides a
common frame of reference that allows suppliers, consumers, and business partners
who operate in this area to understand one another's viewpoints. The TAM has been
built on observations of typical systems available today within the fixed, mobile,
and cable sectors and will evolve naturally as these systems develop.
From an integration perspective, TAM provides a canonical model of the underlying
operational systems and provides generic endpoints for the business functions and
processes defined within the eTOM. It acts as a facade, isolating business
services from technical implementation details associated with underling
operational systems, thereby further reducing the impact of change in this area,
fulfilling a key objective of an SOA-based solution.
IBM WebSphere Business
Services Fabric
The IBM WebSphere Business Services Fabric provides an end-to-end SOA platform to
model, assemble, deploy, manage, and govern composite business services. It
provides design-time tooling, a runtime environment, industry reference models,
and prebuilt SOA assets to enable rapid development of industry-focused composite
business services.
WebSphere Business Services Fabric is also available with an optional
telecommunications pack, which builds on the above NGOSS standards and WebSphere
Business Modeler extensions to provide a configurable collection of prebuilt
reference business services templates specifically tailored to the
telecommunications industry. Using prebuilt assets in this way helps reduce the
maintenance costs of telecommunications operational services through reuse,
standardization, and consistency of support across IT assets.
Governance
Although the concept of governance isn't new within the construction and
management of distributed architectures, past failings to successfully implement
or adhere to governance have led it to take on increased importance within SOA.
Perhaps the result of lack of governance in this area can be demonstrated by the
chaos surrounding some of the early uses of shared libraries, such as
Microsoft® Windows® dynamic link libraries (DLLs). Windows is built on
a plethora of DLLs, which are system-level libraries of commonly used
functionality that are accessed dynamically at run time by many consumers. Desktop
applications can also use these DLLs and may, depending on factors such as the
current patch level of the operating system, actually introduce new versions of
those system DLLs when the applications are installed.
You need to carefully analyze the impact of updating the version of a shared DLL,
as the implication of introducing bugs is wide ranging and difficult to quantify.
You need to preserve interfaces, deprecate proposed out-of-service APIs, publish
changes in functionality to the relevant audience, and test the applications and
DLLs that depend on the current version of the library against the new version
before its release.
Without performing this kind of due diligence, it's easy to find yourself
immersed in a web of cyclic dependencies; releasing one DLL may fix a problem, but
ultimately creates two new ones.
SOA attempts to address the similar problem of governing shared services through
a combination of education and management technology, providing processes,
templates, and best practices through the concept of an SOA Centre of Excellence
(CoE). The CoE provides a central body for governance, controlling all aspects of
the SOA life cycle, including the following:
- Developmental procedures
- Operational issues
- Service ownership
This builds upon the remit of the traditional project-based design authority
role, but elevates it to the enterprise level, promoting reuse, consistency, and
standardization across all SOA projects.
Client case
study
Whilst an SOA is clearly applicable to a greenfield development, it is perhaps
the area of reengineering where it can provide the most immediate impact. The case
study below outlines a business problem faced by many existing IBM clients and is
typical of the issues experienced by organizations that have undergone rapid
organic growth. This often results in business needs being implemented through
tactical IT initiatives involving the procurement of specific systems rather than
strategic enterprise-level planning. The introduction of an SOA provides an
opportunity to align IT with the business after this type of growth.
Problem
The customer's business relies heavily on customized off-the-shelf products to
run its telecommunications operation. Each application within the customer's
infrastructure has performed well in isolation, but the lack of an enterprise
vision led to poor integration between these products, resulting in a very siloed
landscape. From an IT perspective, this wasn't necessarily a major issue; each
system worked well and was perceived to manage a business process. However, these
processes were, in fact, only subprocesses, participating in a larger transaction
that crossed multiple lines of business.
As a result of this, users suffered the following symptoms:
-
Multiple authentication: Users were required to maintain numerous login
credentials to multiple operational systems.
-
Poor integration: Little or no automation existed between related
processing systems; where integration did exist, it used inflexible proprietary
APIs, meaning that change was painful.
-
Manual processing: The lack of integration led to a high degree of
manual activity, causing data duplication and manual reconciliation.
-
Data inconsistency: The degree of manual intervention inevitably led to
inaccurate data representations between production systems.
-
Poor visibility: The lack of an overall business process meant that it
was difficult to generate accurate MIS information.
This study focuses on the integration between the following three operational
systems, which highlight the above problems:
-
Order management system: Used to record and manage customer orders
-
CRM: Acted as the main source of customer information
-
Provisioning system: Used to activate the customer's desired network
services (that is, roaming, 3G, and so on)
Each system contained application-specific business logic, which executed in
relative isolation, as shown in Figure 3. This logic was often interspersed with
presentational information, meaning that there was no clear separation of concerns
within the architecture, further restricting flexibility. Where systems did
communicate, they introduced tight dependencies by using proprietary APIs, which
proved unreliable and reduced visibility.
Figure 3. Business subprocesses
These systems were actually utilized by overlapping user groups, with some users
ultimately required to sequentially access all three systems to gather the
necessary information. This required them to perform multiple logins, interact
with different presentations styles, carry out repetitive tasks, and manually
reconcile information from each system.
Solution
By introducing an SOA, the goal is to unify these disparate systems within a
layered reference architecture, as shown in Figure 4.
Figure 4. SOA layered architecture
Each layer provides the distinct set of benefits outlined below, which together
provide a customizable and agile business-driven architecture. Let's look at these
layers in more detail:
-
Presentation layer: Introducing a portal provides a unified user
experience across a range of business activities. Its personalization
capabilities let us tailor the interface to the user's role, providing the user
with relevant content through a single sign-on browser-based environment.
-
Business process layer: Although the majority of the existing business
logic still resides within the operational systems, the business process layer
choreographs the way in which these systems now work cooperatively. It provides
a business-centric view, documenting the end-to-end process without
technicalities.
-
ESB: Think of the bus as the glue in this scenario. It provides a
degree of indirection between service provider and consumer (which may be the
business process or a portlet). Whilst there's no business logic within the bus,
it can perform dynamic routing (for example, to select one of a range of
activation services based on some service level agreement [SLA]) and perform interface mapping,
effectively unifying disparate underlying data objects.
-
Services: This provides a standards-based interface, enabling
consumers to access the functionality contained within the service in a
platform-independent manner without knowledge of its implementation.
-
Service components: These contain software components that implement
functionality specified by the service. Service components conform to the
contracts defined in the services layer and guarantee the alignment of IT
implementation with service description.
-
Operational systems: The operational systems are left largely in
tact. However, any dependencies between them are now clearly evident within the
business process layer. The goal is not to migrate business logic from these
applications, but to preserve their production-tested capabilities and, indeed,
increase their visibility by exposing them in a standard manner across the
enterprise. Providing the service interface doesn't change, the underlying
operational systems may change without affecting the service consumer. In this
way it's possible to completely replace one operational system with a separate
implementation (for example, replacing PeopleSoft with Siebel), enabling business
requirements to drive the selection of systems, rather than IT-led vendor
considerations.
The service portfolio
When identifying services, there are a number of modeling techniques available
(such as the Service-Oriented Modeling and Architecture [SOMA] approach used
within IBM) that are beyond the scope of this article. But at a high level,
the services identified fall into two broad categories:
-
IT services: These typically contain no intrinsic business logic, but
are used to provide service-based access to existing operational systems. Often
referred to as atomic services (as they generally don't depend on any other
services), they are usually provided directly by the underlying operational
system—although it may be custom built using whatever interface mechanisms are
available. The methods exposed are typically general purpose and fine-grained
(for example, a CRM service might provide a
getCustomerRecord endpoint), as they are
primarily designed to be reused by other services. Whilst this
interface could be accessed by the ESB, it's a best practice to allow this
to occur only if the service interface is sufficiently generic and doesn't introduce
an element of tight coupling between consumer and provider.
-
Business services: These services contain the business logic that will
be used by the business processes, and are often referred to as composite
services, as they may delegate processing to a number of other business or IT
services. Unlike IT services, the methods exposed are generally coarse-grained
and typically relate to a specific business activity (such as
provisionNetworkService).
There is often a third category of service, the information service, which
provides direct access to data contained within a (typically federated) data
source. However, in this case, all data access was performed through the relevant
operational system.
Industry compliance
The use of industry-specific business-process templates and data models not only
accelerates development within WebSphere Business Modeler, but provides verification on the structure of
the business itself, identified gaps, and areas of overlap. However, of potentially
greater importance is the level of future proofing it introduces,
particularly in the application integration space.
Due to their diverse and complex technical requirements, many telecommunications
operators have a heavy reliance on off-the-shelf systems, controlling everything
from billing to the physical operation of their networks. These systems must
communicate effectively for the enterprise to succeed, and building to industry
standards is one of the best ways to achieve this.
At present, the ESB is required for performing mediation operations, translating
between the different data representations used by related operational systems.
But as standards compliance increases across the industry, this will become
increasingly unnecessary. Embracing a common data vocabulary is key in this
area, helping to standardize product interfaces, improving performance, removing
specific product dependencies, and bringing us back to one of the key goals of SOA,
namely business agility.
The solution stack
This solution is based on the following runtime stack and development
environment:
- IBM WebSphere Process Server (including WebSphere Enterprise Service Bus) V6.0.2
- IBM WebSphere Portal Server V6.0.1
- IBM Rational® Software Architect V7.0
- IBM WebSphere Business Modeler V6.0.2
- IBM WebSphere Integration Developer V6.0.2
- IBM WebSphere Business Services Fabric V6.0
Aside from the specific features provided by each of the architecture layers, the
stack introduces a range of nonfunctional benefits, including inherent scalability
(through the capabilities offered by the IBM WebSphere Application Server, which
underpins the SOA stack) and a degree of platform independence within the range
of operating platforms supported by the stack.
Although we use a number of WebSphere-branded products in this solution, it
ultimately represents an architectural paradigm and carries with it a degree of
vendor neutrality. IBM's participation in standards bodies—such as W3C, OASIS,
and their subsequent implementation of TMF, BPEL, XML, and WS* standards—ensures
that this doesn't represent yet another bespoke solution.
Summary
This article has shown how you can address real-world
business problems through the introduction of an SOA, both from a technology and business perspective. The addition of a
complementary technology, such as BPM, adds a further
dimension to the benefits of an SOA, enabling your business to actively participate in
the software development life cycle.
We've also given some insight into one future direction of SOA, showing how IT
patterns have evolved into industry templates, providing technology and process
blueprints for the entire enterprise. One of the key objectives for any SOA is to
align IT with business needs, but SOA is now going further; by embracing
emerging industry models, you see how the SOA philosophy can help business align
itself with industry, adopting standards and best practices to provide improved
interoperability and future agility.
Acknowledgements
Thanks to our colleagues Bob Laird and Paul Baker for their input, as well as to
Scott's wife, Jackie, for proofreading the article (payback for
making me read her 300-page Ph.D. thesis on tuberculosis!).
Resources Learn
Get products and technologies
- Innovate your next development project with
IBM trial software, available for download or on DVD.
- Download the following
free trial software:
Discuss
About the authors | 
| | Scott Glen is an IT architect with IBM's Advanced Technology Group (ATG). He has over 15 years of experience in the architecture, design, and development of object-oriented systems, providing consultancy to the finance, government, telecommunications, and media sectors. With a particular interest in WebSphere, J2EE architectures, and associated design patterns, he now specializes in SOA, providing consultancy and implementation services to clients across EMEA. |
| 
| | Jens Andexer is a certified IT architect with IBM's SOA Advance Technologies team. He has been developing software for 25 years all over the world, specialising in financial systems, public sector banking, and insurance. Starting his career as a PL/I maintenance programmer, Jens has gone on to have leading architect rolls in many large and complex software development projects. After a mid-career M.Sc. in computer science (software engineering), he joined IBM in 1998 and now brings his experience in host technologies, software development, and software maintenance to SOA customers in EMEA. |
Rate this page
| |
