Communauté & magazine du management par les processus (1 jeudi sur 2) |
||||
Why SOA Needs BPMEditor's note: Our SOA in Action virtual conference is only two weeks away! Don't miss out! See the agenda here.
Glenn Smith
Recently there have been a number of articles written about the relationship between SOA and BPM. Some take a positive viewpoint and emphasize the potential synergies between them. Others are more negative, focusing on tensions between the two camps.
Both sides make some good points, but neither addresses the most fundamental aspect of the relationship, which is dependency. BPM can succeed, albeit more expensively, without SOA, but without BPM SOA is only an internal technology initiative which does not directly address any business problem. To explain this last statement, let's first review what SOA and BPM are, what value they provide to the enterprise and how they relate to each other. Proponents of both technologies make similar claims about providing greater application agility and shorter development times, and both technologies often seek to become the dominant application development methodology. Both claim to reduce traditional programming by assembling solutions from components rather than building from scratch. To a large degree, each can deliver on these promises independently. SOA is an architectural style for developing distributed systems. It is not a specific technology, but can be applied to many technologies. It encourages loose coupling of components and enables flexibility. Individual services can be modified with no impact on the consumers of those services. Services support reuse, and can help preserve and extend the value stored in legacy systems by making their capabilities more widely available. Services provide stable interface definitions, eliminating the need for consumers to understand the implementation details and isolating them from internal implementation changes. Services are intended to be reused in multiple contexts and applications, but to achieve that reuse, they must provide granular units of functionality. Therefore, a service by itself should never solve a business problem. Services are building blocks which require assembly and coordination to achieve business goals. By Glenn Smith, Principal Consultant, Appian , 10/15/2009 www.appian.com Mercredi 21 Octobre 2009
BPM -channel
Nouveau commentaire :
Ci-dessous les derniers articles de cette rubrique
|
||||




Fuzz
Digg
Del.icio.us
Blogmemes
Tape-moi
Nuouz
Blinklist
Furl
Reddit
Smarking
Newsvine
Pioche
Spurl
Y!
Simpy
Wists
Blinkbits
Co.mments
Connotea
Blogmarks
Del.irio.us
Technorati
Meneame
Wikio
Facebook
Google
MySpace
Twitter
LinkedIn
Viadeo
Scoopeo
Editeur de logiciels : une stratégie de pure player


