+1 Alex. -Rob
--- In [email protected], "Alexander Johannesen" <alexander.johanne...@...> wrote: > > On Tue, Jan 6, 2009 at 00:04, Steve Jones <jones.ste...@...> wrote: > > Here I completely and 100% disagree. > > Of course you would. :) > > > Most business people have a much > > better of idea what a decent service is than their IT counter parts. > > That depends on the definition of "service". And even when you mean "a > business service", why is business folks so much better at > understanding that term than IT folks who, in most other settings, > understand perfectly well what a service is? Even IT folks deal with > businesses of many kinds, sometimes even their own. Business folks > have no inherit better idea of what decent service is, except, > perhaps, their own very focused version which often is one-sided, and > that leads to the question if that really is a good or a bad thing? I > don't believe in your black and white stance on this, because the > world ain't that black and white. > > Don't get me wrong; I understand where it is coming from and its goals > of making it easier to do these things for people who lack the > experience that perhaps you yourself hold, it's easier to sell the > knowledge, easier to write the books and hold seminars, I just don't > think it's a good idea in the long run to have them thinking that > there is an absolute anywhere here. > > > 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. > > And others have other experiences, which should also be valid. When > *I* turn to talk to business people, I don't talk about technical > stuff either. I agree that these non-techie folks sometimes come up > with good models, but I tell you, it can be like pulling teeth > sometimes too; they are no more equipped to model things any simpler, > easier or more correct than other stereotypical groups we might think > of, and I've had both successes and complete failures in modeling > services with any one group. I simply don't see your corrolation. > > >> 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 > > You know as well as I do that it is extremely hard to put business > value on risk and maintainence, two things at opposite sides of the > business. I'm not attacking the stance that IT is just a branch of > supporting the business, but then, I wasn't actually saying that you > need to start in IT with your SOA initiatives either. The more I work > with this stuff and the more I learn about organizations and > businesses I see a stronger need to work from the middle and out > instead of the top-down / bottom-up easy solutions that I have thrown > around in the past. I don't believe SOA should start in *any* > particular spot, but rather that it works the best if you start from > the middle. > > I guess this is a bit hard to explain (and I recall having tried > before here as well, failing as usual :), but I see success coming > from the right amount of both focus and fuzziness, that for things to > work themselves out the easiest and possibly the best way (while > gaining acceptance by the organization in question) you need to have a > foundation not based on the business, not in IT, not in HR, not in > resources, not in any specific thing, but what they all share ... a > fuzzy, warm spot in the middle which, obviously - through hippie- lingo > that no one would take seriously - isn't easy to point to. As an > example of too focused would be domain modeling and bringing that to > the SOA table, and an example of too fuzzy would be to bring everyone > into a room and talking about it. It's a balance thing, and as such > can not be easily summarized in snazzy sentences or rules or easily be > presented on a slide. > > I've been bitten a number of times by people who are overly focused on > their business, because, as we humans tend to do, we focus on the here > and now and what is known right now, _especially_ by business people. > But we are both consultants, have lots of experience in bringing these > people together and draw the important bits that seems to make the > most sense from them, is that what you mean? That business people are > easier to harvest? (I would agree 20% with that ...) > > > Then by definition starting in other places is less likely to deliver > > these aims. > > By what definition, exactly? All you've done is shifted the modeling > exercise from "service" to "business". :) > > >> 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. > > I know value networks quite well, and one of the foundations of it is > "diversity", which in my experience means that you *cannot* harvest > big design from any one particular group. > > >> 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 > > All good points, but they don't contradict what I say about the > separation of "service" and "software". SO in itself is useful as a > tool for any venture, but people don't use SOA to architect their > business (although I'm sure you'll say otherwise :), they use it for > their infra-structure to support that business. What I'm saying is > that I don't think separating the business / what they do ("service") > from the infra-structure ("software") is a good thing even if it looks > great in diagrams. > > Hmm, I think we're talking past each other a bit here, and maybe we > should be looking at the modeling vs. actual action separation? > > >> 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". > > No, I was talking here about business folks who require non-business > abstractions as a means to understand the fuller picture of how their > "world" hangs together. Again, over-focus isn't good from either camp, > and also, contrary what I suspect you think of me, I'm not rooting for > IT. > > > [...] just because you couldn't get the business > > centric way to work doesn't mean that it is flawed. > > Of course not. Different strokes and all that. I think we agree. > > > Government is > > always a nightmare because of two reasons (IME) > > > > 1) They don't have competition > > Depending on your country, competition is replaced with political > retaliation, such as where I'm from where departments compete between > each other to be compliant with the credo. Governments have been known > to be toppled over these things. > > > 2) They Provide services whose KPIs are at best "abstract" and at > > worst contradictory to the way of working > > Maybe you just live in a very sad part of the world? :) > > > 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. > > I'm not going to say that governments wherever you go don't struggle > with bureaucracy and incompetence, but never forget that there's > hundreds and thousands of small to medium (and sometimes large) > companies that also fail miserably with many of these things as well. > You just don't hear so much about it, because, well, by their very > definition they disappear. I don't think the business world is free > from stupidity, incompetence, bad leadership, poor karma and bad > breath. > > > Regards, > > Alex > -- > -------------------------------------------------------------------- ------- > Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps > ------------------------------------------ http://shelter.nu/blog/ - ------- >
