*/You can read the following article at:
/*
*/
http://www.soainstitute.org/articles/article/article/soa-readiness-a-perspective.html
/*
*/Gervas
/*
*/
<<What is SOA?/*
To be ready for something you first need to understand what it is. SOA
is often defined in technical terms about the composition of services.
Whist technically correct this encourages people to become caught up in
technologies and constraints very early on.
I prefer to think of SOA as a solution approach that helps IT solve
business problems by sharing and re-using:
* Information and data e.g. user directories
* Functionality e.g. quote generation
* Know how e.g. this data lives here and is looked after by X
This is achieved by investing in sustainable system interoperability
which allows you to:
* Consolidate your maintenance costs around a smaller number of
shared services
* Reuse existing services and avoiding unnecessary development
The main benefit of this sharing and reuse is a reduction in your Total
Cost of Ownership (TCO).
*/What's the problem?/*
Since SOA is a form of solution it can only be effective if it solves
the problem at hand. So the second step /"in being ready"/ is to clearly
understand the problem that you are trying to solve.
If your problems are things like:
* We have really useful data trapped in legacy systems that we would
like to release to new user groups to increase customer satisfaction
* Our admin processes are manual, inefficient and costly as we
continually re-key the same information in multiple systems
* We find it really difficult to get our existing systems to
communicate with new supplier systems
* Our business systems cannot scale to meet our continuously growing
user community
Then the SOA may well be appropriate for your organization.
If on the other hand your problems are things like:
* We need to get a Web presence ASAP to support our sales staff
* We need to be able to change content on our website on a daily basis
Then the case is less clear. The solution to these problems may work
well within an SOA context. But these requirements in themselves do not
justify a SOA approach.
A rough rule of thumb is if your business problems are strategic rather
than tactical in nature then SOA could well play a significant role in
IS delivery. If your business problems are short-term in nature then SOA
is unlikely to represent a value for money strategy in that time span.
*/How will SOA impact me?/*
Most of the basic tenets of good requirements gathering, system design
and implementation are just as true for SOA as they are for OO, web or
procedural development. However, a SOA approach is unique because of its
emphasis on cross organizational sharing. Consequently, it does
challenge an organization to change how it thinks, communicates,
delivers, supports and manages. Understanding the impacts of these
changes is an essential step in being ready.
*Organizational Change*
SOA requires people to share information across the business. This
requires people to change fairly significantly in how they think and
operate. People tend to think that if they share they will:
* Gain dependencies and become less effective
* Lose control
* Become redundant
Change is likely to be opposed both explicitly and covertly as people
look to protect their interests. People will only embrace this change
when they feel there is a clear benefit for them. A significant amount
of education will be required to achieve this.
*Communication Channels*
An organization will have to invest in both informal and formal
communication channels to promote information sharing.
*Governance*
SOA will initially require a Governance function as you will not achieve
business wide coordination without some degree of control. The challenge
here is the same with any management function. Keep it at the
right-level and mentor your stakeholders so they become self-governing
as much as possible.
*Budget*
Sharing information and processing across an enterprise means a single
initiative may involve multiple departments. A budgetary approach that
allocates budgets on a departmental basis may struggle to encourage the
level of collaboration necessary to deliver an optimised solution.
*/Business Process Re-engineering/*
SOA enables business process re-engineering. Your analysts must be
skilled in gathering business requirements so they can analyse a process
and remove redundancy. This is very different to taking a list of
features and implementing them on a SOA friendly technology stack.
For example, a legacy process may have a sales team selling using system
A and an admin team processing using application B. The newly optimized
process may have the sales team also completing a large amount of the
admin tasks at the point of sale via a single interface so rendering
application B redundant.
*/SOA and Messaging/*
Messaging is at the core of SOA. It should become the new single
enterprise wide language for your systems. At a minimum this requires
your team to be proficient with:
* Messaging standards, technical and industry
* Messaging patterns
* Message versioning
* XML and XML definition language
It is unlikely that your team will have all these weapons in their
armoury on day one. This must be addressed through formal (e.g. training
courses, enterprise message repository) and informal (weekly meetings,
best-practice workshops) means. Otherwise, your SOA initiative will
flounder as it grows.
*/Building Services incurs costs/*
Services offer an alternative interface to GUI applications for
accessing business functionality. Consequently, the following costs will
be incurred:
* Implementing and supporting a Service Registry to publish and
manage your services
* Implementing and supporting a security layer to secure access to
your services
* Implementing remote invocation, error handling and transaction
handling mechanisms
* Implementing message validation and translation layers at each
client and service
* Providing the necessary bandwidth to minimize latency issues in
accessing your services
Some of these are up-front costs which can be borne over the life-time
of a program. Others will occur repeatedly. The right choice of tools
can help to minimize some of these. But, implementing a function as
service will always prove more costly than implementing a function as a
local library.
*/Services have technical limitations/*
All technologies have limitations and services are no-different. The
principal limitations of distributed services are:
* Transaction control
* Exception handling
* Latency
If your designers and developers do not understand these they will end
up implementing services that do not function or 'fail' gracefully.
Moreover, given the natural latency of services and their ^1
distributed nature certain exception types are more likely to occur than
with homogenous tightly coupled systems.
*/XML development requires specific expertise/*
XML is complex and has just as many pitfalls as any other form of
development. Many XML based applications end up being significantly
re-written because of crippling performance or quality issues. A vast
array of XML development tools exist, each suitable for a different
problem. It is essential that the development team is appropriately
skilled in these technologies.
*/SOA Platforms & Tools/*
SOA isn't short of feature rich platforms and tools. Typically these are
expensive and functionally rich. Unfortunately, the teams that use them
are often not adequately trained in their usage. As a result hacks are
introduced and wheels re-invented at great cost to the overall
implementation and subsequent maintenance.
*/Services require testing/*
Testing a programmatic or message interface is often alien to
traditional QA teams. It is unsatisfactory to rely on user-interface
testing alone to validate a service as fit for purpose. Also, services
require very specific types of concurrency and disaster recovery
testing. The QA team must be up-skilled to provide this function;
otherwise system maintenance will prove expensive.
*/Client applications require repeated Testing/*
If an interface affecting change is made to a service then all client
applications with a dependency on that interface must also be regression
tested. Automated testing needs to be adopted early and systematically.
Otherwise, the test effort will start to inhibit the ability of your
organization to react to change.
/*SOA Deployment*/
SOA encourages separation of concerns and partitioning. Consequently,
you will initially invest in more hardware and software than a
traditional architecture. The upside of this investment in computing
resource is a real ability to scale to meet increased business demands.
If the 'ability to scale and grow' is not a real requirement then this
investment may not be appropriate.
/*Services need Maintenance*/
New services will tend be deployed on a new technology platform. This
will require support staff to be trained in its maintenance and support.
If old systems are not-deprecated in tandem with the release of new
systems the overall TCO will increase.
*/Vendor Lock-in/*
SOA (and ESB's) ability to offer loose coupling between systems is often
promoted as a way to avoid vendor lock-in. In reality, the various
applications and services that comprise a SOA will still need to be
vitalized on a regular basis. Also, every ESB on the market today has a
finite support life time so they in themselves just provide another lock
in point.
Vendor lock-in is unavoidable in any enterprise IS. The best strategy is
to pick the vendor that best suits your profile, adopt popular industry
standards where possible and try to be smart about how and when you
upgrade.
*So are you ready for SOA?*
Being ready for SOA means you have defined your problem and understand
the costs, benefits and limitations of this approach.
SOA does have upfront costs and does encourage an 'economies of scale'
mindset. But the good news is that you can and should embrace SOA
incrementally.
In all likelihood you will have already delivered some services in your
business and can probably look at re-using these more. If not,
integrating with a specialist service provider is a reasonably low-risk
way of introducing services into your enterprise.
^1 Often a service may be provided by an external supplier or
different department to the client application. As a result they will
have different support windows and/or may not be as reactive as desired
in the event of a system malfunction.>>
