SOA – Strategy? Technology?

Or just another business opportunity…

Daniel Schnaider, IT Strategy Consultant

Background
Many articles have been written about Service Oriented Architecture from an organizational
point of view. However, there are tens of thousands of ISVs (Hi-Tech companies) worldwide
that could benefit from the SOA concepts as well. The objective of this article is to explain why
managers at ISVs companies should build SOA- enabled versions of their products.

Before getting straight to business, I would like to share with you my motivation for writing this
article. As a consultant for hi-tech companies focusing on ISVs willing to build software
applications that will be distributed world wide, I have had the privilege of meeting more than
500 companies with original solutions to the different industries in the market.

After many years in this business, I feel comfortable in saying that many companies are not
achieving an optimal combination of their business – technology strategies. In this article, I
would like to show how to synchronize business and technology strategy and how SOA
specifically has a fundamental influence on business strategy while giving flexibility and agility
to the dynamic business environment we are living in today.

Why SOA
The SOA concept is not owned by a specific organization. SOA is a concept of enterprise
software development which centers on combining and integrating IT applications to maximize
their benefit to the organization.

For instance, it doesn't matter if we are dealing with a core banking application, or a VOIP
(Voice over IP) system, compliancy assurance software or an internal threat solution. The
bottom line is what is common to all business applications is the fact that they should assist in
increasing revenues and/or decrease costs and/or improve profitability and/or foster a better
relationship with the customer. As you will perceive in a moment, SOA enhances the business
value of off-the-shelf applications giving you an advantage over your competitors. Whatever
you do today, SOA can assist you to do better.
What is the evolution that brought us to SOA
In order to understand what SOA is, it is advisable to remember the development of previous
technologies. This is the opportunity to say that SOA is not a revolution, but rather a natural
evolution of technologies that have been around for a couple of years. However, this
development is significant as well as essential regarding the techniques used to build our
software and especially in the way our customers will use them.

So, how did we get here?

In the beginning we wrote mechanisms for communication and mediation ourselves. Usually,
those mechanisms were written again and again for each customer; so that actually we were
obliged to define and solve the same problem again and again. Obviously these facts did not
contribute to product development cost, focus on business logic and fast time-to-market.

Very soon, the market introduced a number of infrastructure tools for Messaging and Queues
which were developed in order to create links between applications while using an abstraction
mechanism along with known communication protocols. Rather than having two applications
"speak" directly with each other, they will handle a "conversation" through a message queue,
which is like a "pipe" which delivers "messages" between applications. The applications "listen"
to the message queue, while each application will "read" their designated "messages".
The message queue mechanism solves many problems, such as support for a number of
communication protocols, differences in hardware platforms, miscellaneous operating system
and programming languages. In addition, the Asynchronous programming methodology is
born, allowing two applications to communicate without the requirement of being available at
the same point in time. Finally, part of the responsibility of the Messaging infrastructure is to be
sure of the message delivery without mistakes in the content or duplications.
But who said that two applications installed in a bank in the US for instance, one developed in
Germany and the second one in Chile, will "speak" the same "language"? The message queue
system cannot understand the content of the "message" and make decisions. Thus we require
an additional mechanism in order to "translate" the messages to the application layer.

To avoid the mechanism development need, Brokers were created. Brokers have
transformation logic ("translation") and routing of messages. Brokers can actually read the
content of a message and make decisions, so applications that expect those messages will
receive them in a known format. That's the beginning of the Enterprise Application Integration
(EAI) era.
 This is a sketch of applications within the IT department of one of our
customers. This company has around 5000 employees. The sketch describes
the business applications from different ISVs and self- development.
Every rectangle is an application; the lines are the relationship and
dependencies between the different applications.

Despite all the technological development in the last decades and perhaps precisely as a result
of them, IT departments of today have become cumbersome, complex and worse – resistant
to innovation. Organizations can hardly adapt themselves to customer requirements. Even
when a business opportunity or a competitor threat is recognized, the response time is slower
than required. Operation departments, Marketing, Finance and sales can adjust faster than IT
departments. In IT departments, everything is complex, complicated, requiring analysis, design,
integration, testing, - and when it "finally works", - "don't touch something that works!" This
reality is not acceptable to business departments and must not continue. Changes, flexibility,
dynamics, adaptation and innovation – those are business requirements - a constraint for IT
departments and not the opposite.
What is SOA?
The SOA approach doesn't see an application as a whole unit, but as a collection of "services".
"Services" is a software unit which represents a business task, such as interest calculation,
buying a book, etc. Every service can "consume" other services within the organization; for
example, a service that consumes customer information received from another service in order
to define customer credit ratio. In addition, a service can be a "provider" to another service: a
customer credit ratio service is the "provider" for short period loan service.

A service is a task within the business process; nevertheless, a service can be reusable across
a number of business processes within an organization. At SOA, business processes cross a
number of applications and departments and even pass over the organization boundaries to
share a customer or a supplier.

Today Tomorrow
on

pp

s
e
c
i
v
r
e
S
ati
lic

A
s

Discreet Applications Basket of Services

A business process is not defined by technology but by the business consumers within the
organization. A service should report the QoS (Quality of Service) provided. For instance, can
we expect a specific service to be available 24x7, when we can expect a service to finish its
work (in a second, hour or maybe a working day? In addition, a service should be able to report
about its own cost and revenue linked to its activation. Working this way, we actually receive a
business process that can be measured and on this basis we decide whether to improve it.

If until this point, I haven't succeeded in explaining the strength of the problems existing in IT
departments or the significant potential latent in its solution, try asking your bank (assuming
you have more than one bank account in the same bank) whether they can tell you the amount
of money you have in the bank (the whole bank and not a specific account), or your insurance
company can tell you all you’re the policies registered in your name . In general, how many
organizations can benefit from a horizontal view of the whole business operation, across
departments, customers and business partners?

The SOA approach includes perspectives on business process management, business logic
approach for applications, federated data source access like access to Legacy system, and bi-
directional communication with business partner systems.

Additionally, the SOA outlook is very clear regarding business innovation and optimization of
services. The nature of the mechanism is of simplification, analysis and improvement of
business processes in real time. The SOA approach enables the benefit measurement of
business processes and their components in respect to revenue growth, cost savings and profit
improvement.

Is your company SOA- enabled?

In order to understand where you are today and your level of readiness for SOA, the following
model can help you.

SOA readiness model (for ISVs only)

During my work with ISVs, I have developed what we call SMI, a SOA Model for ISVs. The SMI
is a model which links the technology readiness of your product and the business value to your
end- customer. The model considers those parameters that business applications have in
common.

The model checks the following parameters:

1) Product deployment period (PDP)
What is the period of time required in order to deploy the product compared to
benchmarks of the same category of products. Many companies ignore the PDP of
their products, as if it was the integrator challenge, and it has nothing to do with them.
A good PDP product is most probably a product easy to install, it is easy to ensure
solution effectiveness (for instance in a POC) in a fast and successful approach, it is
 easy to learn and use; but more than anything it is a product that can straightforwardly
be combined with existing systems within the organization.

2) Percentage use (PU)

What is the relation of the relevant business processes of the whole
organization which is using services from your application? The principle
behind this parameter is that an organization is a collection of business
processes, and an application is a collection of services. This understanding is
the essence of the true potential of the alignment between your business
solution and the target organization. The alignment between services and
business processes will bring the highest correlation compared with the
alignment of a monolithic application and one department in the organization.

In order to map the organization into business processes and services you
may choose to consult google regarding the following models:

 IAA – Insurance Application Architecture, IFW – Information Framework for Banking

 TDW – Telecommunication Data Warehouse, RDW – Retail Data Warehouse.

3) Measurement ("You can't manage what you can't measure")

Many companies among those I have had the great opportunity of knowing have
reported the impressive returns on investment of the application they developed and
the way they have saved costs with human resources, increased revenue and actually
improved profit. But most of them were embarrassed when I asked them whether they
could prove that, for instance during a POC. This parameter refers to the application
ability of reporting about Key Performance Indicators (KPI), the business performance
indicators which are important to the organization. Whether your application has the
ability of measuring its own benefit, of reducing troubleshooting in manufacturing , of
optimizing human resources (Effectiveness and efficiency), reducing warehouse
conditions (Measurement: Warehouse height), optimizing prices (Measurement: price,
cost, profit percentage), managing investment (Measurement: risk, chance) or actually
any parameter that is correlated with the revenue, expenses, profitability, quality and a
 better customer relationship – the organization has an interest in being backed up by
results to broaden the use of that service.
4) Flexibility
As we emphasized previously, flexibility and better response to changes on demand, business
opportunities, and external threats are constraints that IT departments must cope with. This
being so, it is clear that software systems developed by ISVS which are not flexible, and can
not adapt to changes harm the IT departments abilities and therefore the whole organization.

At this point, you can classify all the parameters and add them to the SMI model.
The result will show you where you organization is, and where it should be, in order to
maximize the business value you provide to customers.

SMI –SOA Model for ISVs

Maximizing Business Value for your customer

Easy Deployment

Max Penetration Max Measurability

Optimum capabilities
Flexibility
Resize the quadrilateral to fit
current capabilities
How to implement SOA?
There are many approaches to implement SOA. Whatever approach you choose, remember
that it must be a top-down methodology. By that, I mean that it comes from business
requirements down to technology and not the other way around. The SOA implementation
should start from the business modeling of the business processes you want to support, with
business monitoring (Key Performance Indicators) in mind.

Summary
The SOA methodology can help you decrease the sale cycle, increase the application benefit
to the organization, improve customer bottom line and, last but not least, your application
functionality can be simply and easily used by more departments. SOA gives the opportunity of
becoming integrally part of the formal business processes which exist in the organization.

To summarize, SOA is a strategy, is technology, but beyond all doubt – it is a business

opportunity – don't miss it.

Daniel Schnaider is a senior IT strategy consultant to the High-tech sector. With 15

years of experience in the software market – development, design, architecture,
project management, sales and business development, Daniel is a consultant to many
leading international IT corporations.
You can reach him at: dschnaider@yahoo.com