I agree with Rob and Steve on "data-first" topic, it is DO. I disagree on presentation layer is not a part of SOA. What any User Journey is if not an implementation of a business process or an aggregation of business services/functions/features? Well, I posted my comments on this already.
I think that the easiest way to find what in IT is not SOA is to analyse ITIL v.3 (not v.2). It still does not identify SOA very well but it clearly defines non-SOA things in IT. - Michael ----- Original Message ---- From: Kirstan Vandersluis <[EMAIL PROTECTED]> To: [email protected] Sent: Sunday, September 28, 2008 4:32:19 AM Subject: [service-orientated-architecture] Re: Linthicum on Metadata & SOA --- In service-orientated- architecture@ yahoogroups. com, "Rob Eamon" <[EMAIL PROTECTED]> wrote: > 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. I do agree that SOA doesn't cover everything. An SOA would consist of services, software components, supporting tools, infrastructure, policies and procedures (governance) . Certainly there are other aspects of the enterprise and IT that would not be part of an SOA. This is easy to see with various app architectures (e.g. presentation layer). And, as we've seen in the Shulte thread, there may be multiple, disjoint SOAs at the project level within a single organization. > > > 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. Is there something else you would add to the list besides agility? How about "cost efficiencies for a particular desired strategic, long term outcome"? The goals of SOA should give a company a high level idea of whether they are interested in pusuing it. e.g. if you don't need agility, as some businesses don't, then don't bother with an SOA initiative. This oversimplifies, but on the other hand, if we don't agree on the goals of SOA, then any vendor of any product or service will make a case that a prospect needs SOA. And of course, this is what has been happening. > The opinion that I have (and Steve > too, it seems) is that a data-first approach isn't SO. > It's DO. In general, its data oriented, but just as object oriented systems have controllers which are largely procedural, SOA will have components that are data oriented. That doesn't mean you no longer have an SOA. I think data oriented services will always have a place in an SOA. But I understand we won't agree here at this point in time, as we don't currently agree on the definition of a service. I see more people on my side of this argument (entity services, business object services, data services, are all examples of prevalent definitions) , but I'll admit that doesn't make us right. > Wrapping a service interface around data isn't SO, IMO. You would define the service around an entity/business object, achieving a desired level of granularity, and align with definitions in the vocab of a business analyst. You align with the business on both functional and information fronts. I agree, slapping an interface on an existing data interface would lead to a poorly designed service. -Kirstan
