--- In [email protected], "Kirstan Vandersluis" <[EMAIL PROTECTED]> wrote: > > --- In [email protected], "Rob Eamon" > <reamon@> wrote: > > > > SOA is not an architecture. It is a style. > > I would maintain that SOA is a "thing", an architecture with a > particular style.
I don't disagree that architecture is a thing. Where we may disagree is whether or not "SOA" is an architecture. I contend it is not. The architecture of interest is the BA, EA, AA, etc. I'm beating the same drum over and over, but those architectures will not only be SO. They will incorporate other principles as well (e.g. EDA, data management principles, portions might be process-oriented, etc.). The continued fawning over SOA as the umbrella that covers *everything* has got to end. SO is *one* set of characteristics in an architecture definition, not *all* of them. > It has identifiable characteristics, and can be documented and > modeled, just like non-service oriented architectures. Companies > want to evolve to an SOA to achieve identifiable goals like > business agility and IT cost savings. Agility, I'm on board with. Cost savings, not so much. Cost savings is one potential benefit, but revenue growth is another. An architecture will need to support business activities at the "right" cost. The assumption that we must always focus on "IT cost savings" is something of a widespread, constraining issue, IMO. It's a view that positions IT as only a cost-center--which is right some of the time, but not all of the time. > These goals are ultimately achieved because of the *architecture*, > not because of a particular way the architecture was built > (although the way it was built will contribute to its success). We agree. That's the whole point of the SOA mania, no? That it is *the* cure for all that ails us (I'm exaggerating). :-) > I will agree architecture is also something you do. But the end > resulting architecture seems ultimately much more important, and it > is what provides the value. The architecture has to perform and > achieve its goals, and its success will be measured against those > goals. An SOA that brings business agility and cost savings won't > be judged a failure simply because some services were designed > around data. We agree on the fundamentals. The question is whether or not that is "SOA" or something else. As Steve pointed out, I don't think anyone has any issues with the validity of taking a data-centric approach. There may be some disagreement as to how effective it can be compared to other approaches but it's still valid. The opinion that I have (and Steve too, it seems) is that a data-first approach isn't SO. It's DO. Wrapping a service interface around data isn't SO, IMO. Function/capability first, data to perform that capability second. -Rob
