Kirstan said: > 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.
I contend that each organization must identify its own goals for its SOA initiative. Those goals should be established based on business needs, and the goals should drive the direction of the initiative. Non-specific goals such as "increase agility and reduce costs" aren't particularly useful because they are so difficult to measure. 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 > >
