Lists Home |
Date Index |
I'd say that was what you were trying to implement, not what you were
attempting to specify. How could you create an object-oriented program
without the implementation? We could always Booch up our UML, but at
some point, "bytes must change state". OOP went South every time we
tried to sell that concept to the businessmen. It was only when we
described the reports that could be generated and the business rules
they could configure that we finally sold a system implemented with
objects over relational DBs. Viewpoint matters.
Given an SOA, the business guy should be able to specify what they want
without knowing how we did that. Unfortunately, they try to know both
and that slows us down; hence, the very long and odious RFP to Proposal
to Contracts to Implementation cycles. If one can specify a Business as
a set of outward and inward facing services, then it is faster and most
of the choices can be made by the customer. In business environments
where the critical requirement is to enable ever larger groups to
coordinate actions, this is a good approach for well-known reasons.
Weirdly enough, just as I am writing this, I get email about how
"business objects will revolutionize my applications".
I didn't say it was precise. Just that is isn't meaningless.
From: Michael Kay [mailto:firstname.lastname@example.org]
Sent: Thursday, May 11, 2006 3:54 PM
To: Bullard, Claude L (Len); 'bryan rasmussen'
Subject: RE: [xml-dev] Re: Major Historical SOA Milestone Today
> The focal point of SOA is when one decomposes a business into requests
> for services by type regardless of implementation. That is why an
> object oriented architecture is not an SOA.
Well "decomposing a business into requests for services by type
of implementation" sounds exactly like what we wre trying to do when I
working on IT architectures in the 1980s, and we called it object
then. But perhaps we were just trying to be fashionable.