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