Re: [service-orientated-architecture] Trolling for flames

[Keith Harrison-Broninski]

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. Why am I saying this to you all?  Because it's a bad case of an almost universal problem. We could go on forever providing definitions of different types and levels of "architecture".  In these terms, a definition such as Steve's (for example) is perfectly adequate, though all such definitions are inevitably founded on a particular technology vantage point - they assume some kind of standard current approach to enterprise technology.  However, this is not the fundamental problem.  The real-world issues organizations face with architecture can only be solved by recognizing that "architecture" is not primarily about individual work products - a process map, a network diagram, a set of components and services.  Architecture is about processes - the management processes by which a technology infrastructure is maintained - which in a large organization can be very complex indeed. A much richer viewpoint than arguing about who produces what type of document, or the content of each type of document, is to focus on the means by which systems are introduced, supported, replaced or retired.  Not only will this permit you to place proper controls on the evolution of a technology infrastructure, but it can remove some almost universal blinkers: The knowledge of, and preference for, certain technical approaches with which certain individuals happen already to be familiar The tendency to separate the activities of technicians from those of "the business" (whatever that supposedly independent entity may be) Based on experience in companies of all sizes, in all sectors, in all part of the world, I would argue that very few companies see architecture in these terms.  This is not only because technicians see architecture as a function rather than a process (witness this discussion thread), but also because architectural effort is usually managed in a hopelessly inappropriate way (probably because of the historical FUD with which senior management tend to view IT). If you want to do architecture well, first you need to make sure you know how to properly manage human collaborative effort.  Then apply this to the maintenance of your technology infrastructure. -- All the best Keith http://keith.harrison-broninski.info SPONSORED LINKS Computer software Computer aided design software Computer job Soa Service-oriented architecture 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.