2009/1/5 Alexander Johannesen <[email protected]>: > 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?
Here I completely and 100% disagree. Most business people have a much better of idea what a decent service is than their IT counter parts. Firstly most modern companies and indeed according to the folks at places like HBS the whole modern economy is based around a "value network" which is really just a series of collaborating services. When I turns up and talks ESB, WS, REST and the like the reason that the business doesn't "get it" is because you aren't talking in their language. My experience has been that business folks tend to be able to model better services i.e. ones that will _actually_ be reused and which will _actually_ have decent governance and actually have a real business case. > > 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. Here I disagree about 80% ;) Sure you can start elsewhere and there is value in those approaches (e.g. Service Oriented Delivery) but given that surely the objective is that IT is 1) Looks like the business 2) Evolves like the business 3) Is Costed in line with its business vale Then by definition starting in other places is less likely to deliver these aims. > 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. Go and read up on "Value Networks" and you'll see that services isn't just what a business does, its what the modern economy does. > 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. Again I have to disagree. Having delivered business centric SOA projects since 2000 the key of having that business focus has been to 1) Align the KPIs at the start of the project 2) Help with requirements trimming 3) Keep the separation of teams high and hit the agile sweet spot (SOD) 4) Reduce the latency and impedence between business and IT by creating joint working practices > > 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. IME this is normally because the IT department thinks they understand the business and the business belives them because its "all technical mumbo jumbo". > 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. Which is great that it worked. > > 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." This I agree with, but just because you couldn't get the business centric way to work doesn't mean that it is flawed. Government is always a nightmare because of two reasons (IME) 1) They don't have competition 2) They Provide services whose KPIs are at best "abstract" and at worst contradictory to the way of working IME commercial organisations are much better at doing business centric SOA because of the more cutting edge nature of their business and because of the greater degree of clarity over what is, and isn't, important. Steve > > regards, > > Alex > -- > ---------------------------------------------------------- > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > ------------------------------------------ http://shelter.nu/blog/ -------- >
