A whimsical neologism composed of the juxtaposition of "Marketing" and "Architecture," used to refer to a marketing strategy employed by various product vendors in which new products -- e.g., various vendor's software "architectures" -- that are not particularly technically or theoretically innovative are marketed to naive buyers as if they were something radically new. First seen (?) on TheRegister, noted for imaginative language. E.g. a "Seattlement" for a sell out disguised as a settlement. The word has been in currency before this and has been used about most industry offerings in the last few years. For example, some might argue that ServiceOrientedArchitecture (or products that claim, in their marketing literature, to employ this BuzzWord) are merely straightforward implementations of ClientServer architecture or DistributedComputing, and are therefore of no particular theoretical or academic interest. In that case, ServiceOrientedArchitecture, as implemented in a given product by a given product vendor, might be considered a MarkeTecture. Some vendors are particularly overt about this, explicitly using terms like "innovative" or "radical" and so on to describe products that obviously use conventional or mundane technology. ---- ''Probably a wrong example. SOA is a baby with a lot of dirty bath water. Suggest you to watch ZapThink on Google, even though they are in the consulting business, they poached a few young talents from my workplace recently.'' It could well be a wrong example, hence my use of "might be considered" rather than "should be considered," but "poached a few young talents" is not an argument in favour of considering ServiceOrientedArchitecture anything but MarkeTecture, nor is claiming that it is "a baby with a lot of dirty bath water." These arguments -- and I use the term loosely -- are entirely content-free and do absolutely nothing to counter my point, as they say nothing about ServiceOrientedArchitecture itself. If you wish to counter my argument, then do so with verifiable facts rather than vague opinions. In particular, please indicate the '''theoretical framework''' that distinguishes ServiceOrientedArchitecture from ClientServer or DistributedComputing. Headhunting activity by a consulting business doesn't count. -- DaveVoorhis DeleteWhenCooked '''Lets relax'''. The "poaching" stuff is just a side comment. It does serve to suggest that business for that company is expanding, for now. I am the one who claim "there is a baby in lots of dirty bath water", not you. I am probably more uptight re: tolerance of this community towards MarkOfCostin behavior, even though the person concerned is obviously talented. It destroys CommunityBuilding efforts. At this moment, ComplexEventProcessing (I unnerved DM for creating it) serves as a better example. It is related to SOA, the CIOs got attracted to it at conferences, and I can only dig up barely enough to see what it alludes to. * But you can learn from MarkeTecture too. Several aspects are listed: ** what "deep seated" needs are being addressed and what alternatives (have to research) exist? ** how do they sell their solution? (if you have to counter their pitch you need your own) ** what can we learn? If MarkeTecture becomes more prominent, then different people would eventually come out to comment (for/against/other). These comments may have insights that sometimes can be applied in a totally different area. What do you think? ''I think you've completely failed to address my points about ServiceOrientedArchitecture. Furthermore, the moment I start to regard the activities of technically naive CIOs or profit motivated consulting businesses as important to ComputerScience, is the same moment I quit my job and take up gardening as a living. Your bullet points are valid, I am sure, for those whom the associated issues are a concern. They may even be of academic or theoretical interest to people who study business, as they are business issues. Thankfully, after fifteen years of spending every day thinking about these things, I now have a job where I have the freedom to ignore them. If ComplexEventProcessing has any interesting aspects at a theoretical level (which I doubt) then I will pay attention to it. Otherwise, you're right -- it lands in the MarkeTecture bucket with just about everything else that the major vendors have coughed up in the last decade.'' -- DV