|
FYI, Happy and Safe 4th, and I am working on the next conference call to start to organize the 2nd Conference. Brand
-----Forwarded by Brand Niemann/DC/USEPA/US on 07/03/2006 02:11PM -----
To: donxmlbsc@xxxxxxxxxxxxxxxxxxxx
From: "Weiland, John R. NMIMC GS" <JRWeiland@xxxxxxxxxxxxxxx>
Date: 07/03/2006 01:26PM
Subject: FW: Debunking the myths of SOA - from LogicLibrary
If you wish to unsubscibe, go to this address:http://bumed30.med.navy.mil/guest/RemoteListSummary/DoNxmlbsc
Really liked this article.
-----Original Message-----
From: Tom Bills [mailto:thomas.bills@xxxxxxxxxxxxxxxx]
Sent: Monday, July 03, 2006 11:22 AM
To: jrweiland@xxxxxxxxxxxxxxx
Subject: Debunking the myths of SOA - from LogicLibrary
John - I thought you would be interested in this article: Debunking the
Myths of SOA by Daniel Magid; June 07, 2006.
Do you think Service-Oriented Architecture (SOA) is over-hyped? Do you think
you will just buy it and install it once the market matures? Or, do you
think your organization will pass on SOA altogether and find a better way to
accomplish the same thing?
If you answered yes to any of the above then you have officially fallen
victim to some of the most prevalent myths about SOA. Don't feel too bad,
though, because you're not alone. In fact, leaders in both business and IT
are subscribing to many of the same beliefs about SOA. Unfortunately, many
of these beliefs are misguided.
You'll want to get your facts straight now because analysts and industry
leaders all agree that SOA is the single most important IT initiative in the
last decade.
Myth #1:
SOA is a technology.
Reality:
SOA is an architectural concept. It is the way companies weave applications
and processes together in a flexible manner so that they can reuse them.
Think of SOA as a software-development style that allows applications to be
assembled from reusable components instead of being built from scratch.
If "regular" coding resembles building a house, SOA is like putting a
pre-fabricated house together in the sense that the pre-built pieces just
have to be connected. A more technical definition might be that SOA is a
collection of services that communicate with each other through standard
interfaces. The services are self-contained and do not depend on the context
or state of the other services, and they work within a distributed systems
architecture.
Myth #2:
SOA will add complexities to my already complex IT environment.
Reality:
SOA is about simplifying complexities. Rather than re-creating every part of
a software system from scratch, SOA lets you rapidly assemble pre-designed,
pre-built, and pre-tested components into powerful new applications. With
SOA, application boundaries can be extended to include functions from
anywhere inside or outside of the organization.
With SOA, you plan, develop, manage, deploy, and share automated services
from a completely open IT architecture. An SOA architecture helps you
quickly and efficiently change applications to respond rapidly to evolving
business and market requirements.
With SOA, you:
Reuse application logic.
Link business and IT through the adoption of standards.
Eliminate redundancies.
Link and leverage systems across the entire enterprise.
Through the use of interchangeable, reusable parts, standard containers, and
open interfaces, SOA should actually simplify application development and
maintenance. Any "complexities" associated with SOA aren't from SOA itself
but are more about changing how we think about software.
Myth #3:
I'm using Web services already, so I must be doing SOA.
Reality:
Even if you use Web services and apply object-oriented approaches, you may
not achieve the kind of loosely coupled, autonomous, and reusable components
that are essential to true SOA. Web services specifications have sped the
enablement of SOA by defining a common, accepted style of interaction
necessary to implement and expose services. By using SOA to design
distributed, enterprise-wide, market-driven applications, businesses can
expand the use of Web services from simple client-based functions to systems
that better harness much of the latent potential and functions buried in
legacy systems. While Web services play a role in SOA, they're just one
piece of the equation.
Myth #4:
I will have to throw out my legacy systems and start over.
Reality:
There's no need to abandon what you already have. SOA helps you leverage
existing data and application assets so that you can reuse them rather than
re-create them. Services can be introduced incrementally over existing
legacy applications, preserving your investment while letting you take
advantage of new opportunities.
Myth #5:
I should wait until SOA concepts mature before I start.
Reality:
As more and more companies begin deploying services as the preferred method
for communicating with customers and vendors, the risk rises that
organizations failing to adopt these services will be left behind. You
should view SOA like you view your application development - with a "life
cycle" - and start carefully priming your IT departments now. Your
competitors may be doing SOA to some degree. You don't want to find out the
wrong way how far ahead they might really be when they start offering
customers and partners services that you can't.
Start SOA projects incrementally with a focus on scale and extensibility.
Initial projects can be small and focused and should deliver measurable
business value at the close of each project.
First, your organization must identify an overall business process
addressing how services will be evaluated, built, tested, deployed, and
updated. Identify the most developed "service-centric applications" and
leverage them into business services that align with the goals of your
business.
Then, you need to create an IT environment conducive to crafting quality SOA
- one that provides a detailed inventory of resources as well as structured
development processes. This is easy with software-configuration and
change-management solutions, which provide visibility and accessibility to
IT resources as well as the process-management oversight required for proper
execution of SOA.
Because services can be described almost entirely by their metadata, it is
imperative to have this complete, detailed, and accessible inventory so you
can find and reuse those key corporate assets. The structured processes help
you manage the services throughout their entire life cycle rather than only
through the initial development and deployment stage.
Now you can start thinking about designing a robust, open solution for
defining and enforcing those processes that will manage all the resources
stored in legacy systems. Eventually, you can retool your applications from
the outside in.
To read all of the other myths, click on:
http://www.iseriesnetwork.com/content/f3/index.cfm?fuseaction=news.viewArtic
le&webID=1001&newsID=5021&issueID=5806&articleID=52698
Thank you for your interest in LogicLibrary!
Tom Bills
Regional Sales Director
thomas.bills@xxxxxxxxxxxxxxxx
T 412-471-4710 X215
C 412-613-3514
F 412-471-4711
KNOW WHAT YOU HAVE. MOVE AHEAD.
www.logiclibrary.com
--------------------------------------------------------
This is an official e-mail message - it is NOT unsolicited (SPAM).
To unsubscribe, go to http://bumed30.med.navy.mil/guest/RemoteListSummary/donxmlbscor send an e-mail to donxmlbsc-request@xxxxxxxxxxxxxxxxxxxx with the word "unsubscribe" in the message body.
_________________________________________________________________
Subscribe/Unsubscribe/Config: http://colab.cim3.net/mailman/listinfo/soa-forum/
Shared Files: http://colab.cim3.net/file/work/soa/
Community Portal: http://colab.cim3.net/
Community Wiki: http://colab.cim3.net/cgi-bin/wiki.pl?AnnouncementofSOACoP (01)
|