Re: Application design & architecture

Joe,

Trevor
System i evangelist

Subject: RE: Application design & architecture

From: Trevor Perry

SOA zealots claim that SOA is the 'best practices' of everything we have
been doing. SOA is not claiming "new" - that is the sales machine of
certain vendors we know and love. Don't learn SOA from a sales pitch,
would be good advice.

Interesting. SOA is not a technology. It is a best practices, sort of like

CUA back in the 90's.  We'll get into it more in a moment, but let's nail
this right down: SOA is not about a specific technology.  (If it is, then
please tell me which technologies.)

> You may be able to put new
> faces on things, but you won't be able to extend your business without
> writing new features.  SOA doesn't help with that in the least.
SOA is designed to DO this, given the past failures of such approaches.
This is one of the reasons for SOA. You are exactly right, except for
the last sentence.

Again, SOA isn't actually a technology, it's a way of using existing
technology better.  So even though we've been doing this for decades, SOA

will now make it work. There are no specific tools, no measurable way that things get better. If the company gets results, it's because of SOA, but if it doesn't, it's because they didn't adopt SOA properly. There is really no

quantifiable way to say what SOA is doing for a company.

I begin to see why this appeals so much to consultants.

> I suggest you take a long look at the abject failure of the UDDI
UDDI.com being closed down is not an abject failure. The concept of UDDI
is very important - what happened was that it evolved.

Oh pshaw. The UDDI registry closing down marked the failure of the concept

as clearly as the falling of the Berlin Wall marked the failure of
Communism.

Companies did not want
to publish their web service information to a global catalog. UDDI now
works
in a smaller capacity - where industry groups have their version of a
UDDI,
companies have internal UDDI in the form of Registry/Repository.

Yes, and in that regard Web Services are exactly what we've been calling
them for ages: EDI for the Internet.  The only place where WS is more than
EDI is when you can get data from public sources, and that's pretty much
limited to weather reports and stock quotes.

We do not see the partner's code, simply their business process that they
allow us to use. If you think with your programmer cap, this concept can
scare you. If you think about working with trusted business partners to
leverage what they can do, that is less scary. And the key is the word
"trusted".

If you think about this with a businessman's cap, you laugh yourself silly
and send the consultant who suggested it packing.  There are damned few
companies whose business processes I trust more than my own.

As SOA evolves, so will the concepts. UDDI has not failed, but evolved.

Uh huh.  Just like the dinosaurs.

No one would consider creating a web service to expose your private
corporate information with anyone but trusted partners. This would be
thinking from three or four decades ago, and is no longer an assumption -
security is inherent to your web application.

You miss the point... in order to USE a Web Service in the way you insist
will happen, you have to share your private corporate information with
someone else.  I don't care how close your trusted partners are -- do you

tell them what your profit margins are? In the real world, my clients hold

that sort of information dear.

With any standards, there are going to be complexities and inherent
problems. Picking on web services and SOAP are easy targets.

Yeah, because they stink.

Did you realize
that SOA does not advocate that web services have to be used for your
transactions?

Yet there isn't an SOA consultant out there selling anything but Web

Services. Please give us an example of a wide scale SOA implementation not

based on Web Services.

You see, it's this sort of talking out of both sides of the mouth that makes

me start thinking "more snake oil."

SOA requires only that there is a standard in place.

Back to this: SOA requires no software. SOA advocates no architecture. SOA

works with whatever standards you have.

Your SOA Architect will build that into the architecture.

It just needs a person to coordinate your existing standards.  And guess
what... this can be a consultant!

The only model? I don't understand how you can see this. The internet has
opened our world so much, and so many companies are taking advantage of
it.

They sure are. With EDI. Some with FTP. Many use PDFs, others use faxes. Some of them just email flat files to each other. It's working quite well,

and interestingly enough none of this requires an SOA Architect.

Where does Walmart fit into an "intra-company" model?

Walmart uses Web Services for EDI-INT, EDI over the Internet... nothing
more, nothing less.  There are no "processes" that are shared, so they're
not implementing any level of SOA.  I'm reasonably sure they don't have an
SOA Architect, nor do any of the companies that work with them.

SOA brings all the best practices together. It does seem that you are
hearing a narrow perspective of what SOA is and what it can do. And that
is sad.

SOA as you use it has almost zero semantic content.  It doesn't mean a

particular technology or platform or communication methodology. Whenever a consultant talks about "implementing best practices", I put my hand over my

wallet and run.

I know what SOA can do.  The same thing a good client server approach can
do, or a nice inter-company data transfer like EDI.  It's just that SOA
doesn't bring anything to the table except a really bad standard, and an
opportunity for our poor clients to get taken for yet one more
buzzword-laden ride.


Joe