An SOA that is built without a reference to business context or the integration of IT assets often leads to hindered compliance, impeded information flow and decreased worker productivity. This can subsequently result in a chaotic SOA implementation process with little business relevance and an inability to respond quickly and effectively to changing business needs. I think business architecture is the input to SOA desgn. Business and technology are both needed to have successfuly SOA design and implementation. ALl the best
Ash Galal --- JP Morgenthal <[EMAIL PROTECTED]> wrote: > Okay, I'll be the first to say it since we're all > thinking it. Ron, > Jason, you guys are the biggest threats to SOA! J > (only kidding) > > Seriously, I think this article is premature. > There's not enough > evidence of successful REAL SOA projects to help > steer the tide one > way or another. Personally, we experience a 50% > reduction in typical > integration projects due to using an SOA-based > design with Web-based > Services. Ultimately, this works out to be a more > evolved form of a > model view controller with services representing the > model, but > still, using WSDL to quickly generate proxies and > knowing that the > services abstract the data allows us to drive > implementations in a > rapid and incremental manner. > > I know, SOA has nothing to do with technology (beat > me with my own > whipping stick)! Still, I've always said SODA is > using SOA for > application development and there we are achieving > great results. I > was lucky enough to work on designing a corporate > reporting structure > using SOA, but the company never got to execute > because the > management got canned before they could. But, this > is to my point, > we don't have enough solid and diverse applications > of SOA to state > that it's threatened. If anything is threatening > SOA's existence, > it's the lack of diverse proof-points. > > JP > __________________________________ > JP Morgenthal > President & CEO > Avorcor, Inc. > 46440 Benedict Drive > Suite 103 > Sterling, VA 20164 > (703) 649-0829 x 101: Office > (703) 554-5301 : Cell > [EMAIL PROTECTED] > __________________________________ > > Confidential: The information in this e-mail message > (including any > attachments) is intended only for the use of the > recipient(s) named > above and as such is privileged and confidential. If > you are not an > intended recipient of this message or an agent > responsible for > delivering it to the intended recipient(s), be > hereby notified that > you have received this message in error. Any review, > dissemination, > distribution, printing or copying of this message is > strictly > prohibited. If you believe you have received this > message in error, > please notify the sender immediately by return > e-mail and delete this > message from your system(s). > > > > > On Oct 1, 2007, at 12:09 PM, Gervas Douglas wrote: > > > > > > > -------- Original Message -------- > > > > Subject: [ZapFlash] Who's Killing SOA? > > Date: 1 Oct 2007 15:58:25 -0000 > > From: ZapThink <[EMAIL PROTECTED]> > > Reply-To: ZapThink <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > > > > > > > > > Who's Killing SOA? > > > > Document ID: ZAPFLASH-20071001 | Document Type: > ZapFlash > > By: Jason Bloomberg > > Posted: Oct. 01, 2007 > > > > Service-Oriented Architecture (SOA) is now well > past its hype > > phase, and is fast approaching a critical > crossroads. Will > > enterprises resolve their current architectural > challenges, > > allowing SOA to become the predominant approach to > Enterprise > > Architecture worldwide? Or will it succumb to the > pressures of > > confusion, misdirection, and ignorance that assail > it, and become a > > tired label that signifies little more than a set > of product > > features? We've seen this sad conclusion before > with Enterprise > > Application Integration -- once a promising > architectural approach, > > now a euphemism for expensive, inflexible > integration middleware. > > Will SOA suffer the same fate? > > SOA, fortunately, has not yet gone down this path, > although the > > crossroads that will determine SOA's future is > fast approaching. > > And yet, the forces that assail SOA are assembling > on all sides. It > > is time for a rallying cry! Let us recognize the > threats that SOA > > faces, in the hopes that shining light on them > will help overcome > > them. It is not yet too late to save SOA, but time > is running out. > > > > Threats from All Sides > > ZapThink, of course, has already recognized > several of the threats > > that assail SOA today. Other challenges may come > as more of a > > surprise, and may raise the hackles of individuals > who may never > > have thought they were part of the problem. > Nevertheless, by > > understanding the greater forces that impede SOA's > success, we can > > better overcome them. Here, then, are the forces > that ZapThink > > believes are killing SOA. > > > > Integration platform vendors. You're a software > vendor with a > > product line chock full of proprietary, > tightly-coupled integration > > middleware. License revenue is suffering as > customers look for more > > flexible, less expensive ways of leveraging their > diverse > > information technology (IT) resources. As a > result, you are looking > > at SOA. Your software, however, does not lend > itself to SOA best > > practices -- loose coupling, composable Services, > and flexibility > > in general are all capabilities that you failed to > build into your > > software. What to do? > > > > Reinventing your company and rearchitecting your > software from the > > ground up is far too expensive and time-consuming, > and after all, > > you already have the older middleware in the can. > The only option > > is to slap Web Services interfaces on your stuff, > call it an > > Enterprise Service Bus (ESB), and sell it as SOA > middleware. > > Hopefully your customers won't notice the old wine > in new bottles. > > After all, that's what marketing is for! > > > > Not every integration vendor has taken this route, > but many have. > > You can identify them when their sales people make > statements like > > "ESBs are necessary for SOA," and when their > marketing deemphasizes > > the more significant SOA infrastructure challenges > of governance, > > quality, and management, in favor of distracting > information like > > "underground" videos that convey no indication of > a true SOA value > > proposition. > > > > Enterprise architects. EAs are supposed to have a > comprehensive > > perspective on the business and the role that IT > plays in > > supporting its varied and changing needs. While > many EAs do have > > the rare combination of business and technical > acumen === message truncated ===
