On Mon, Jan 5, 2009 at 10:18, Michael Poulin <[email protected]> wrote: > Starting and applying SOA are different things. I think that SOA has to be > started in one 'place' - business - (while it may be initiated in IT) and > applied anywhere needed.
Starting it at the business level may never happen (because most businesses don't really know what SOA is) unless IT tell them why and how it is needed (to the best of their understanding of SOA), and that, by definition, would be starting it in IT, no? Why are we talking about where it starts, really? Does it really matter? I personally don't believe for a second that SOA started at or by the business has implicit value over other parts of the infra-structure. Sure, I understand the theory (focus on value and core philosophies and activities) but any domain-driven model is bound to be stuck to that domain, which even can blind you from doing the right thing or prevent you from coming up with the right design. Are we any further from the problem through the business focus? Are we loosly coupled by grounding our services in the business itself? If someone were to come up with some real arguments for the inherit business focus, then maybe, but as far as I've read it's all about "services based on what the business do" which is an easy theory that not always translates into the real-world. The separation of "service" and "software" is at best a pie-in-the-sky abstraction that I've never seen give evidence to the notion of a definite starting point, and often ends up in lofty SOA projects that don't actually get anywhere. Some people and / or organizations require non-business abstractions in order to be successful with SOA, and I've seen it again and again how the artificial "services" notion on business activities blurs rather than makes it easy. For example, the library sector at the national level uses "services" already as part of their organizational markup and these services (rooted in a very distinct library functional model with hundreds of years of backbone) disjoint from the data models is actually a harmful abstraction because these data models *can't* for the most part be based on those services. You end up with fluffy services that can't do the things they are suppose to do in name. We even tried to make "services", "data services", "interface services", "abstract services" and lots of others, which muddled it up further. these things are *not* easy, and thinking the model starts at the business can indeed have very bad effects. The lesson was to have SOA *start* at the IT level directly, and let SOA bubble up the organization which actually worked. It's not about where you _must_ start; it's about that you must be smart. Maybe if you sell apples you can do it this way without blinking, and perhaps strong merchant culture does to, but to culturally heavy models these things gets in the way. Sure, the answer is "well, define your services differently", which is trivial to say and darn hard to do. There is no black and white answer, except perhaps "be smart." regards, Alex -- --------------------------------------------------------------------------- Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps ------------------------------------------ http://shelter.nu/blog/ --------
