told him he is young, fit and brutal and will make a speedy recovery.
Here is his latest ZapFlash:
Gervas
========================================================================
SOA for Independent Software Vendors (ISVs) ZapFlash
By Ronald Schmelzer
Document ID: ZAPFLASH-2006419 | Document Type: ZapFlash
As Enterprise Architecture, Service-Oriented Architecture (SOA) is
particularly useful in large enterprises, and increasingly, to small
and midsize businesses, as well. However, those are only one part of
the IT ecosystem. What about those companies that are in the business
of building and selling software products, so called independent
software vendors (ISVs)? Generally speaking, ISVs create and sell
software products that run on one or more IT platforms. ISVs might
offer consulting services, but they typically aren't consulting
companies per se. Neither are they simply Value-Added Resellers (VARs)
or Original Equipment Manufacturers (OEMs), who embed or customize
someone else's products. Rather, ISVs sell their own intellectual
property as installable, configurable software.
The largest software vendors are responsible for the enterprise
applications that we run, the operating systems we use, and the
infrastructure platforms on top of which we conduct business think
IBM, Microsoft, SAP, Oracle, HP, and CA. However, we don't usually
refer to those vendors who provide software ecosystems unto themselves
as ISVs. Instead, this ZapFlash focuses on the thousands of smaller
software vendors who participate in the large vendors' ecosystems by
making and selling software products that run on the large vendors'
platforms. For these smaller folks, does Service Orientation even
matter? Why should they consider the intricacies of the movement to an
agile architecture if their primary objective is to the fill the
niches left open by the larger software companies?
First, Necessary Step: Don't be an Integration Headache
First, an important reminder: as we covered in earlier ZapFlash,
there's no such thing as a SOA "wizard" that is, software that can
provide SOA out of the box. Remember, SOA is architecture, which means
it consists of a set of best practices, and the discipline to follow
them. In other words, SOA is something you do, not something you buy.
As a result, there are two fundamental ways that ISVs can leverage SOA
in their products: to help their customers implement SOA for
themselves, and to leverage the principles of Service Orientation to
help make their own products more useful and valuable to their
customers, regardless of whether those customers are actively planning
or implementing SOA.
In fact, a primary reason why even the smallest of software vendors
should consider adopting Service-oriented principles in their software
is the same reason why many large companies decided to adopt SOA as
many as a few years ago to reduce their integration expense.
Distributed computing systems built on proprietary, tightly-coupled,
and inflexible technologies are much more expensive, complex, and
cumbersome to integrate with, resulting in significant customization
and configuration expense. The problem with most of today's ISV
products is that too much time and money goes into simply getting them
to work in a heterogeneous, distributed environment.
As a result, ISVs with products that participate in the increasingly
heterogeneous IT environments of their customers should at the very
least take the first step down the SOA implementation roadmap and
replace proprietary, tightly-coupled interfaces with standards-based,
loosely-coupled ones. This move will not only reduce the overall cost
of implementing their software, but also make their products more
attractive as the IT environment becomes increasingly more complex.
Software products with standards-based interfaces will not only offer
lower cost of integration for their customers and faster
time-to-market for the vendors, but will also significantly reduce the
need for consulting to get them to integrate, lowering their total
cost of ownership.
Enabling Continuous Innovation
However, simply placing standards-based interfaces on top of existing,
tightly-coupled architectures is not sufficient for ISVs to realize
the true promise of SOA for their customers. ISVs should also take the
notion of loosely coupled, composable Services to heart. Too many
software companies have jumbled their products together into a
tightly-coupled, intricate morass of software that is hard for the
vendors themselves to integrate, let alone their customers. Taking SOA
to heart will lead to making their own products better integrated with
each other, let alone with their customer's IT environments.
What differentiates the smallest of ISVs from the largest is not their
requirement to meet customer demands all software companies must do
that but rather the available resources to meet those demands. Large
software companies often have the luxury of deep pockets to fund
ongoing research and development. Small vendors all too often operate
at the edge, carefully balancing the need to continue to invest in
their existing (one could even say "legacy") technology, while looking
to innovate to meet new demands so that they can grow their
businesses. Even more so, many IT products have reached a point of
maximum complexity where adding new functionality amounts to a
zero-sum game that only serves to further complicate the software,
rather than adding to the overall value to customers.
In today's competitive (some would say "cutthroat") software
marketplace, vendors must continually and rapidly innovate their
products without introducing this unnecessary complexity and
brittleness in order to survive. Service Orientation is therefore many
ISVs best hope for survival. By abstracting their product
functionality as a set of Services that continually evolve as the
underlying implementations likewise evolve, ISVs can approach their
application functionality as a Service-oriented whole that meets
customers' changing business requirements.
Rather than trying to translate directly from sales requirements to
product implementation, ISVs should take a page out of the smartest
enterprises' SOA playbook establish an Enterprise Architecture team
that manages the Service model that mediates between business
requirements and software functionality. The more that vendors seek to
translate directly between individual business requirements and
product functionality, the more they will find themselves chasing the
tail of IT complexity. SOA provides ISVs with an overall product
development methodology that allows them to meet new customer
requirements with new functionality, stay ahead of competition by
matching existing features and introducing new capabilities, and do so
without breaking everything else they already have or worsening the
challenge of product integration. Smart ISVs will see SOA as their
ticket to long-term product success.
Make Yourself an Embeddable Platform for Growth
However, software companies have significant opportunities to benefit
from SOA more than simply making the componentization and integration
of their offerings easier for themselves and their clients. ISVs
should also recognize that SOA is fundamentally shifting the entire
landscape of distributed computing. Rather than seeking to purchase,
implement, and then integrate disparate software offerings as their
business needs change, enterprises will consider all their various IT
capabilities as composable assets they can leverage as their business
needs evolve. As a result, many ISVs of the future will no longer be
in the software product business anymore. Rather, they will be in the
Service business, providing an assortment of IT capabilities,
associated metadata, and business processes that enable the
composition of those Services on an ongoing basis. As the notions of
Software as a Service and SOA converge, ISVs that successfully
leverage SOA will provide their customers an ongoing stream of
continually updated Services and metadata, rather than selling
traditional software products on today's familiar release schedules.
In this vision of the Service-oriented ISV, vendors become independent
Service providers that provide all the necessary IT intellectual
property for a particular set of business tasks. Service-oriented ISVs
are in the business of providing Services that their customers can
embed within their business processes as needed. This shift from
self-contained, packaged software to embeddable, composable Services
will necessarily change the business of software as vendors offer
their products on a license, subscription, or even per-transaction
basis. As a result, ISVs who don't ride the SOA wave will quickly find
themselves obsolete in the face of IT Service vendors that provide the
flexible Services businesses desire.
The ZapThink Take
The most important benefit of SOA is business agility, and implicit in
this ZapFlash is the position that ISVs must become more agile by
shifting the control of IT to their customers. For far too long,
software vendors have exerted excessive control over their customers
by imposing restrictions, costs, and complexities on how their
customers consume IT functionality. In many ways, the business climate
actually rewarded this balance of power by establishing the
expectation that software licenses are but a small part of the total
cost for any particular IT project.
The shift to SOA is fundamentally changing this economic reality.
Customers are coming to expect a much flatter cost of change and the
ability to evolve their business without having to rip and replace
their IT investments. ISVs, therefore, have no choice but to evolve
into agile businesses themselves in order to enable their customers to
become agile as well. Becoming Service-oriented, therefore, is not a
matter of simply putting standards-based interfaces on top of
existing, tightly-coupled, complex, inflexible and non-composite
business functionality. Rather, in order to realize the promise of
SOA, ISVs must change the way in which they build, package, sell,
deliver, manage, and support their offerings. In other words, SOA will
radically change the ISV just as much as the end-user, and those that
can get on top of this curve will thrive, while those that don't will
be doomed.
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
