Anil John wrote: > Dan Creswell wrote: > > >I think the fundamental problem is that the business half of any > >company has heard it all before. This new tech or that new tech or this > >new approach or that new approach > > Indeed! But is the problem with the audience or with the speaker? If IT
I wasn't suggesting where the problem was although I'd say it's both sides of course. > treats SOA as another new-fangled technology innovation intead of as an > approach to solving business issues, business IS going to continue > tuning them out, for the simple reason IT is not addressing their pain > points in a language that they understand. > Obviously. > >If an enterprise _really_ wanted to achieve more for less it would need > >to ensure that it had a culture that co-operated together, discussed, > >compromised and negotiated with complete honesty. Something that just > >isn't going to happen because of politics. > > Politics IS a reality in any Enterprise. It is the art of of using > unconventional (not unethical, mind you!) means to get things done. The And the trouble is that some people are unethical. If politics were just about getting the job done, it wouldn't be such an issue but unfortunately, you have empire-building, face-saving etc. > sooner technologists realize and accept this reality, the more > productive they can be. Negotiation and compromise arise from trust, > which in turn is based on understanding the other party's motivations > and points of view. > This is how it's supposed to work......... > >I think what is critical is to get yourself into a place where you can > >have sufficient control and influence to build something that becomes > >successful. Once it's successful, people will start to ask how you did > >it and from there you get buy in and potentially positive change. > > And how does one get to this place? Comes down again to trust and shared > history. Shared history of delivering what was promised which in turn I'd have to disagree. Again, laziness, lack of ethics etc can all play a factor. I see plenty of projects that are essentially given a mission, told to get on with it and ignored after that due to a need on people's part to avoid responsibility (through laziness or politics). These projects are essentially cut adrift before they've even started at which point it falls on the project leader(s) to pick up the ball. From a management angle, that might be to go find a friendly sponsor etc. From a technical perspective, most teams fall back to what they know and attempt to get the job done with that. _Some_ teams get a bit more analytical and consider new approaches looking for advantages that will allow them to get ahead. They go with something new and make it work not needing to answer questions such as "why are you doing that?" because no-one's paying them attention. But later, when they deliver and it's good, people get much more interested in how it was done and discover something new which is given credence because it appears to have lead to a successful outcome (I'd argue of course that the real reason for success was the people). > translates to trust when you make a statement about what is needed to > deploy something. The reality is that this takes time and there is no > quick fix here. I recently heard a presenter (talking about his SOA > implemenation) make a statement that still resonates with me. He was > talking about the partnership his technology organization had with his > business units and when in the process of proposing some solutions to > his BUs, he could make the statement that (paraphrased) "Folks, we are a > world class organization and we've delivered for you before. You are not > going to find anyone else out there who can do it for you who > understands your business needs to the extent that we do. So when we say > that in order to deliver this functionality for you, its going to take > _______, we mean it". And given their shared history, his BU had no > issues buying off and executing. > And I like the strategy but it's not always going to work - I've seen many cases where the BU's did the opposite and went elsewhere, often at increased cost but with no-one prepared to admit it (often because no-one is actually tracking the real costs because no-one's really focused on improvements). > The long and the short of it is that, SOA is not about building > technology widgets but about making business much more productive and > agile. And that requires that techologists have an understanding of how > technology can be applied to solving *business* problems. > Do you think business agility and productivity is always brought about via technology? Solving business problems is what _everyone_ should be about (not just techies) and it's not about technology or even SOA it's about good business. Dan. ------------------------ Yahoo! Groups Sponsor --------------------~--> Great things are happening at Yahoo! Groups. See the new email design. http://us.click.yahoo.com/TISQkA/hOaOAA/yQLSAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
