Anne, What you stated makes a lot of sense, but the downside of what you present below is that SOA ends up resembling the "cure for cancer" solution. It slices, it dices, it takes care of your kid and solves all your corporate problems all for the low cost of just, $9.99, but wait there's more....
Is it not better to present the role that SOA can play in delivering each of these goals rather than saying that these are the goals of SOA. I believe we would all agree SOA is a part of the former, not the driver of it. Or would you disagree with that statement? JP > > A SOA initiative should focus on business outcomes. What can you > do > that will deliver measurable benefits that the business will > appreciate? > > Example deliverables include: > - better quality data > - improved operational efficiency > - optimization of complex business processes > - simplification of B2B processes > - channel consolidation > - single view of the customer > - more consistent enforcement of policy > - better visibility into processes for compliance requirements > - reduced redundancy in the application and/or data portfolio > > Anne > > > On Sat, Sep 27, 2008 at 11:32 PM, Kirstan Vandersluis > <[EMAIL PROTECTED]> wrote: >> --- In [email protected], "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 >> >> >
