This is starting to get really interesting because I think we are starting to understand the fundamental people problems that we face as practitioners. I think our role in this is to inform up the chain to those that make decisions so that they are better informed as to how software systems are and can be constructed and show them it is in their interest to do it in a more controlled way. Only by understanding how we construct software systems and how we gather the business requirements can we close the fundamental gap that exists between the software practitioners and the business decision makers. After all we are paid as a result of a business need and not just because we have cool ideas about how to write a piece of Java or how to use the next coolest bit of software.
My earlier thoughts on the roles is targeted at all of us in the software practitioner world with a view to informing those in business of the roles that need to be played out in order to better organise ourselevs. It is perhaps an interesting thought to ponder that most software systems fail because of a lack of organisation - true of many software startups too - and only by better organisation can we hope to achieve alignment with business. Keep the ideas rolling. Cheers Steve T On 18 Mar 2006, at 15:23, Jerry Zhu wrote: > Hi Keith, > > I can see what you are saying. We are in a > interesting time not only we are facing unsolvable > complexity but also we often do not learn from what we > created for the long systems cycle. Things get worse > when politics get involved. Most politicians are > linear thinkers and see only five feet far in sight. > The issues we are facing today can not be solved > without an outright change in philosophy current > methodology and practices are based. > > All business models and methods are based on > Newtonian_Cartician worldview today. The world is a > machine the complete understanding of which is > possible. The way to understand it is analysis. > (three step process: take what you want to understand > apart, understand the parts separatly, and the > assemble the understanding of the parts to the > understanding of the whole) Enterprise information > systems are complex systems. When we take a complex > sysetm apart we loose the property of the whole as > well as the property of the parts. The whole is the > product of interaction of the parts. By taking the > whole apart, we loose rich relational information as > well as the systemwide properties arised from these > relational information. The way RUP deal with this > missing information is to use wastefull iterations. > These iterations do not add new value or new parts but > only fix these old parts already being created. > Average coders spend 50% of their time correcting > errors. Correcting errors may well be themselves > source of more new errors. A sustaining fact that > cancelled projects and correcting bugs cost $59 > billions in U.S. alone yearly is a direct > manifestation of these wasteful iterations. > > The tragic thing is that, for most part, all these > wastes are avoidable when things are done right the > first time. This can only be done when we change at > the level of philosophy, our worldview, the way we > conceptualize the world. This is the hardest not in > terms of economics, but in terms of peoples' "will" > and habbitual patterns. > > Jerry Zhu > > www.knowledgegoods.com > > "First, the taking in of scattered particulars > underone Idea, so that everyone understands what is > being talked about... Second, the separation of the > Idea into parts, by dividing it at the joints, as > nature directs, not breaking any limb in half as bad > carver might." - Plato, Phaedrus, 265D > > > --- Keith Harrison-Broninski <[EMAIL PROTECTED]> > wrote: > > > I was recently approached for help by a large > > company who had a problem > > with architecture. Their problem was that they had > > over 50 "architects" > > and no means to synchronize what they were all > > doing. What is more, > > whenever they had tried to develop such a means in > > the past, the > > attempt had broken down for political reasons - > > no-one wanted their > > fiefdom eradicated and so by implicit mutual assent > > none of the > > architects would co-operate. > > > > This was understandable from each individual's point > > of view. As things > > were, not only was each architect in the powerful > > position of being > > effectively the only person who fully understood > > their own domain within > > the organization, but their systems worked well - it > > was senior > > management who not only faced integration costs they > > suspected could be > > reduced, but felt generally out of control of their > > technology > > infrastructure. > > > __________________________________________________ > Do You Yahoo!? > Tired of spam? Yahoo! Mail has the best spam protection around > http://mail.yahoo.com > > > > > YAHOO! GROUPS LINKS > > ▪ Visit your group "service-orientated-architecture" on the web. > > ▪ To unsubscribe from this group, send an email to: > [EMAIL PROTECTED] > > ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of > Service. > > 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/
