http://blog.gmane.org/gmane.comp.web.services.soa.yahoo-1 hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8992 New layer? If this is a new layer, where do folks feel that it fits? IMO, SOA isn't a new layer of abstraction. It's an approach applied to various existing layers of abstraction. -Rob ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Rob Eamon 2008-11-20T15:57:47 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8991 Kool-Aid is something that you don't get any value from. Topic Maps provide the language translation needed to get things to talk to each other. A namespace, no matter what form, presents a language barrier that you somehow have to negotiate through. We still don't have one language or one marshaling format... Gregg Wonderly ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Gregg Wonderly 2008-11-20T13:48:15 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8990 [Cross-posted in REST-Discuss Yahoo Group] Two Gartner colleagues and I just published a note on WOA -- a term I coined a couple of years ago and finally got around to nailing down. I've posted some highlights from it on my blog: http://blogs.gartner.com/nick_gall/2008/11/19/woa-putting-the-web-back-in-web-services/ . Let me just repeat the essential definition here: WOA is an architectural substyle of SOA that integrates systems and users via a web of globally linked hypermedia based on the architecture of the Web. This architecture emphasizes generality of interfaces (UIs and APIs) to achieve global network effects through five fundamental generic interface constraints: 1. Identification of resources 2. Manipulation of resources through representations 3. Self-descriptive messages 4. Hypermedia as the engine of application state 5. Application neutrality I am especially interested in this list's feedback on the addition of a fifth constraint to Roy's four "uniform interface" constraints: "application neutrality". Reactions to the change from "uniform interface" to "generic interface" are also welcome. (As are any other reactions -- except to the choice of the name "WOA". <grin>) Nick Gall 2008-11-20T03:29:38 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8989 <<Call for Speakers MIT 2009 IQIS is actively seeking speakers for presentations and panel discussions. If you would like to submit your presentation for the Symposium, please forward your submission via email to: submission-mitiqis-3s7WtUTddSA< at >public.gmane.org In the body of your email submission or in a separate attachment, please include the following information: * title and abstract of your presentation (150 words maximum) * bio (150 words maximum) for each coauthor * any additional information you would like to provide to the Program Co-Chairs (500 words maximum) in consideration of your presentation (optional) * statement indicating that the information included in your presentation has been authorized and cleared for publication by your firm or organization* IMPORTANT DATES FOR SUBMISSIONS December 5, 2008: Deadline for Submission January 5, 2009: Acceptance Notified February 15, 2009: Camera Ready Copy of Presentations Due TOPICS The Symposium offers presentations and panel discussion that focus on Information Quality related methodologies and best practices. These general IQ topics include: Enterprise Architecture, Data Governance, Business Intelligence, Master Data Management (MDM), Data Integration, and Data Warehousing. In addition, the Symposium scheduled to offer three parallel tracks on Government, Healthcare, and Business (1-day tracks on Day 2). These tracks are intended to address industry-specific topics and at the same time promote cross-industry learning. For example, Dr. David Alberts from the Office of the Secretary of Defense, the author of Network Centric Warfare and Power to the Edge, will discuss how U.S. Department of Defense and its partners are leveraging information by adopting innovative and non-traditional approaches to command and control and to organizations. The lessons learned could benefit other civilian government agencies as they transition toward a citizen-centered results oriented paradigm as well as helping business firms meet information sharing demands in a networked world. Government Track: * Implementing key goals of DOD's Network-Centric strategy * Overcoming information sharing barriers * Understanding the Data Quality Act and what it means to federal agencies Healthcare Track: * Compliance with regulatory requirements, such as HIPAA and 21 CFR Part 11 * Improving data submissions to health insurance companies or for public reporting * Using data for strategic planning and evaluation of patient care quality and efficiency in healthcare organizations * Ensuring data availability and integrity in the context of new information system implementations in healthcare organizations Business Track: * Enterprise-level data integration of application "silos": Master Data Management (MDM) * Governing information quality for restructuring, mergers, or acquisitions * Engineering business process to dramatically improve productivity. * Managing data and information quality in supply chain management *Authorization to Present and Publish It is the policy of MIT IQ Industry Symposium that authors must obtain all appropriate authorization and clearance for materials submitted to, presented at, and included in the Symposium. It is the responsibility of the authors and presenters to obtain any internal authorization and clearance before submitting papers and presentations to the Symposium for consideration and inclusion in the Proceedings. Once accepted for presentation and inclusion in the Symposium Proceedings, all documents shall become permanent records of the Symposium, and will be made available to the public internationally via the Symposium's website and the Proceedings electronic distribution.>> You can find this at: http://mitiq.mit.edu/IQIS/2009/CFS.aspx?mtcCampaign=4756 I learned about this from Burton Group (Anne's employer). The programme looks as if it might well suit many of you despite the lack of specific mention of SOA. Gervas ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Gervas Douglas 2008-11-19T12:55:57 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8988 IMHO the latest technologies offer good solution for the problems described by you. Implementation is just a matter of wise thinking, money and time. Sample possible scenario 1. Make research for typical ways of working in the schools. Such research can outline several models that can be automated 2. Make (web based) applications that follow these models. Multilanguage support can be included for more users 3. Schools pay small fee(about $100) or use ad-supported free software like Yahoo and Google If the project attracts many schools(users) can be profitable like Yahoo and Google :-) Kamen --- In service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, Todd Biske <toddbiske< at >...> wrote: 8 a and big typical the could decisions. Poulin is an a ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ kaburov 2008-11-19T09:29:36 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8987 No, not really. I am trying to say that it is enough SOA concept interpretations from OASIS, OMG, W3C, etc. We do not need new SOA concept for Telecom, Healthcare, and so on. At the same time, there may be implementation specifics in the domains, and quite significant. I think, it should not be a Telecom SOA but rather a Telecom specific SOA adoption or implementation framework. This is why I propose the name DOSOM ( for DOmain Service-Oriented Model/Methodic/ Method ) that promotes SO Principles in the specific (Telecom) domain modeling and implementation. - Michael ________________________________ From: htshozawa <htshozawa-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> To: service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org Sent: Tuesday, November 18, 2008 12:48:17 PM Subject: [service-orientated-architecture] Re: Stuart and Richard about SOA for Telecom Are you implicitly trying to tell us that Domain Oriented Model/Methodic/ Method is DOOM? H.Ozawa --- In service-orientated- architecture< at > yahoogroups. com, Michael Poulin <m3poulin< at >.. .> wrote: domain specific SOA implementation standards: for ... Telecom, Kindergarten or Ice-cream Kiosks SOA for Telecom Magazine about initiative in creation of SOA for Telecom: http://www.soamag. com/I23/1108- 3.asp tells me that I better to start a SOA for Michael Poulin 2008-11-18T15:25:30 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8986 For now, I'm getting paid to do this for clients. When the time comes when my employer won't mind, I will. :) H.Ozawa --- In service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "Nick Gall" <nick.gall< at >...> wrote: one ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ htshozawa 2008-11-18T19:47:54 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8985 While the SOA for Kindergarten comment was made in jest, having a K-8 grade school principal for a father-in-law, I claim that there is a need for SOA for Kindergarten, or really SOA for elementary school administrators. Technology is a part of school administration, and given the very, very constrained budgets of most schools, it's a big challenge to use technology effectively. Add to this that the typical school's IT staff is lucky to contain any full time staff besides the technology instructor, and you have a BIG challenge. Some standards business architectures for school administration could really help these administrators make appropriate technology decisions. -tb Todd Biske http://www.biske.com/blog/ Sent from my iPhone On Nov 18, 2008, at 5:16 AM, Gervas Douglas <gervas.douglas-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> wrote: Todd Biske 2008-11-18T15:09:03 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8984 I'd love to hear more about how you link business-driven SOA and technological realization. I'm sure the rest of the list would too. Nick Gall 2008-11-18T14:21:28 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8983 <<For years, the industry has struggled with the emergence of the new layer of abstraction that's been called SOA… it's been very slow to be born SOA evokes WB Yeats and his poem "The Second Coming", the idea of a "Rough beast, it's hour come round at last". In the enterprise, things have fallen apart. The center is not holding at all. What is the center? Enterprise Applications? SAP? Oracle? The Mainframe? IBM? The desktop? Microsoft? The data center? HP? Java was a system at it's core that was elegant–sure purists will attack it for all of its compromises. But it was filled with elegant compromises. I know that sounds oxymoronic, but the enterprise is by it's nature a compromised creature. What made Java interesting is that it recognized a few things–that the sacrifice made in speed by introducing the virtual machine was made up for by creating a language that was familiar and productive to folks who previously used C and C++ syntactically. Human speed became more important than machine speed. Strong types made it reasonably conversant with enterprise structured data, while late binding enabled it to be flexible and dynamic. But of course the market wants alternatives even to alternatives. The alternative to Java is pretty clearly .NET. But of course once the initial cracks were formed in the foundation, it invites many other alternatives. I think Bill Gates was absolutely right about "many languages" up to and including domain specific languages. Languages are part of the "user interface" and different languages are better at expressing different thoughts. But JVM bytecode is Turing Complete–so you could bring PHP, Ruby, Groovy and anything else into bytecode the way you can bring Visual Basic, C# and others into IL for the CLR. Turning and turning in the widening gyre The falcon cannot hear the falconer; Things fall apart; the centre cannot hold; Mere anarchy is loosed upon the world, The blood-dimmed tide is loosed, and everywhere The ceremony of innocence is drowned; The best lack all conviction, while the worst Are full of passionate intensity. Surely some revelation is at hand; Surely the Second Coming is at hand. The Second Coming! Hardly are those words out When a vast image out of Spritus Mundi Troubles my sight: somewhere in the sands of the desert A shape with lion body and the head of a man, A gaze blank and pitiless as the sun, Is moving its slow thighs, while all about it Reel shadows of the indignant desert birds. The darkness drops again; but now I know That twenty centuries of stony sleep were vexed to nightmare by a rocking cradle, And what rough beast, its hour come round at last, Slouches towards Bethlehem to be born? In Boston, I spoke with a SOA Naysayer, Rachel Chalmers from the 451 group. I was very sympathetic to her views because she is probably on the side of history–that technological revolution typically comes from the outside of the enterprise and goes in. Client server, the web application server, mobile technologies, social software, cloud apps, Saas, all have their revolutionary origins outside the enterprise. Why subject yourself to the complexity of SOAP when you can just build elegant web apps in the cloud? You get scalability for free. You get availability (we hope) for free. The google app outage this week shows you dont always get availability for free–but the availability is pretty darned good, certainly as good or better than most Enterprise apps. Her objection was that SOAP was flawed from the get go, and that everyone should embrace REST. In time, perhaps this will be true. The preference of SOAP style over REST style is really based on the notion of a world where resources are limited and controlled, not a world where they are unlimited and free. On the web, the Google style is to assume that the system is always going to be scalable, always available and free. At the heart of the Enterprise there are antiquated systems that manage financial reporting, accounting, supply chains, human resource management among other things. Some of these are packaged apps like SAP and Oracle, but others are custom apps like IBM mainframe apps. To date, efforts to rip and replace these core systems at the heart of the Enterprise have failed. The paradigm in Enterprise is fraught with requirements to secure these systems, ensure reliability, meter and regulate scalability and enforce interoperability when possible. As soon as SOAP headers appeared, all of these complex agendas that were handled by internal systems and tightly coupled legacy apps started to regurgitate themselves out into the headers and the endless spawn cycle of WS standards began. It's not a pretty sight, admittedly. SOAP is inelegant and you can end up with very large SOAP payloads and cumbersome headers that delivery systems dont always fully support as you go across enterprise boundaries. But as I've said before, short of abandoning the core systems, Enterprise is stuck. Perhaps the tax of dragging these legacy systems is so large that large enterprise is finished and will be overwhelmed by more efficient small and midsized companies that run everything, financials, transaction processing, custom apps, business processes in the cloud. Perhaps. But this will take time and there's not much historical precedent (doesnt mean it wont happen). Historically, large enterprise has become larger, legacy and all. In the meantime, SOA continues to slouch towards Bethlehem, to be born.>> You can read Miko's blog at: http://www.soacenter.com/ Gervas ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Gervas Douglas 2008-11-18T14:19:47 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8982 First a general point. I write to this list as a private individual so will not point to specific company references that I have done with my employer. 2008/11/18 Nick Gall <nick.gall-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>: Gartner did not provide the content for the approach that I wrote about, it might have happened in line but it is not the same stuff. Out of interest what are Gartner's clients using for software design? I agree, which is exactly the reason to have a clear business service architecture as it helps restructure the application into its constituent services at the start of the programme which is exactly what stops the interfaces being a "lipstick on the pig" after thought. Oddly I can't just publish client interfaces on this forum. A traditional application approach with technical services is what leads to application centric interfaces, or can you explain how it doesn't? I just do not see this. I see scalability issues where people build big applications and then lob Web Services et al on top as an after thought thus disconnecting the external SLAs from the internal structure of the application. The systems I've personally worked on always had tight requirements around this sort of thing (find something that needs to be more available than Air Traffic Control). Services add a complexity in network effects but they also enable you to implement advanced approaches such as graceful degradation which isn't possible in an application centric model. Yes, HUGE fan of Waterfall I am, always pushing it. Of course there is the alternate view... First off I AM a technology troglodyte, its what makes me good at doing Business Architecture. I've said a huge number of times that the key skill is knowing the technology but not exposing it to the business until its genuinely applicable. Secondly I created the method originally on technical delivery projects because we didn't have a way (Use Cases aren't it) of outlining the solution to clients and the organising the teams so they matched the solution. And tell me Nick, how do you get those people working together? The answer is of course that you need to split down the problem quickly in order to have your co-operating teams. You can't do this by having 20 business people, 20 programme managers, 20 architects, 40 analysts and 100 developers all in a room. So what you need to do is quickly sketch out the business services (from experience we are talking about 4 weeks or less) so you understand the overall problem context then assign people to those different services (and establish an integration and technology team to work on the platform) these individual teams then work on the detail around the service. A normal approach is to define the service interfaces early to help drive the independence of the teams (Mythical Man Month on communication challenges in large teams). This sort of approach then gives you a series of small teams working within constrained environments. This of course means that you are much better able to hit the Agile sweetspot. So in fact a business service approach actually helps companies that are currently using Waterfall to switch to Iterative/Agile approach (I posted a couple of years ago how this can work) by making the "Waterfall" projects short (after all if you do 18 x 1 month "waterfall" iterations then its at least iterative). It also helps companies to understand where different approaches are required. Waterfall works (IME) in exactly one place... Vanilla Package implementation with a business change programme, Agile tends (again IME) to kill package delivery. So a business service approach quickly helps to split these areas so you can do the package delivery from the development extensions (e.g. what goes in Fusion Middleware over Oracle package). Steve ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Steve Jones 2008-11-18T13:24:38 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8981 You can find the following article at: http://www.soamag.com/I23/1108-2.asp Gervas /<<Abstract: As many enterprises currently carrying service-oriented initiatives have learned the hard way, SOA governance isn't a "nice-to-have" option. Instead, it's vital to the long-term health and effectiveness of the undertaking. What makes governance particularly challenging is the sheer number of interacting software assets found in a typical service-oriented architecture. Forward-thinking organizations have turned to SOA governance automation to help manage this daunting task. This article offers a series of simple tips and tactics to bolster the likelihood of being successful when selecting and implementing SOA governance technology. It also points out the interplay between governance solutions and the major phases of a service-oriented initiative. / *Introduction* For many organizations, embarking upon an SOA initiative involves a significant investment in staffing, training, hardware, and software. Unfortunately, far too many of these enterprises overlook the importance of protecting their investment by deploying a well-planned, robust SOA governance infrastructure. In this article, I point out a few best practices that you can employ to help bolster the chances of being successful when bringing SOA governance technology into your organization. I begin by attempting to explain the paradox of how so many organizations are managing to implement their SOA without investing in governance technology, as well as the unpleasant surprises that await those types of entities. With that out of the way, I point out the relationship between the major phases of the service lifecycle and associated governance technology. The remainder of the article is dedicated to itemizing 10 tactics that should improve the likelihood of a happy SOA governance outcome. *SOA Governance Today* The majority of IT organizations are muddling through either without any formalized SOA governance technologies, or with a collection of home-grown solutions. In addition to the ever-popular word-of-mouth approach, examples of internally-developed governance applications include: . Wikis . Spreadsheets . Emails Given that governance is so important, how is it possible that many of these enterprises would describe these manual tools as meeting their needs? Reasons for this perceived satisfaction include: . No overarching SOA vision . A relatively small number of deployed Web services . Small design teams . Re-use and re-composition aren't a priority As it turns out, this peace-of-mind is likely to evaporate upon the first serious governance-related crisis, which often leads to a panicked search for technology to halt the conflagration. *Governance and the Service Lifecycle* Before delving into the governance tips, it's worth noting that from a governance perspective, the service lifecycle can be broken down into three major phases: 1. Design-time 2. Testing and Quality Assurance 3. Run-time Each phase introduces unique governance process and technology requirements. It's imperative that the selected governance solution be capable of addressing the needs of all service lifecycle phases. During design-time, solid governance technology can help with: . Meta data management . Service discovery . Service composition and modeling . Disseminating organizational policies During testing and quality assurance, governance can be of assistance in: . Service unit validation & composition interaction . Policy adoption . Security compliance . Service performance prediction Finally, governance has a major role to play at run-time, including: . Service level agreements . Version control . Error reporting and management . Performance monitoring *Ten Governance Technology Tips* Strategy 1: /"Include governance technology as part of your overall SOA roadmap."/ Scope: All service lifecycle phases Many organizations fall into the trap of deferring any governance arrangements until after services are being employed to run a significant part of the business. Waiting to make this decision often means that you'll need to incur additional effort, cost, and overhead once you've selected a governance infrastructure. Retrofitting always takes longer than expected, and siphons off valuable resources. These added burdens can jeopardize the entire SOA initiative. For all of these reasons, it's crucial to avoid the temptation to wait until you have "enough" services before thinking about governance. Since many SOA initiatives rely on the vision of an architectural committee, governance topics should definitely have a place on the agenda of these working groups. Strategy 2: /"Make sure your governance platform is agnostic with regard to service development technologies."/ Scope: Design-time When speaking to a collection of software developers drawn from different organizations, one sure way to trigger a donnybrook is to initiate a debate on the relative merits of .NET vs. Java. These religious wars can be amusing to observe, but they can also wreak havoc on an enterprise's governance initiative. Consequently, when choosing a governance platform, it's important that the selected technology work, at a minimum, with services developed in Java and .NET. If your governance platform only supports one style of development technologies, you'll end up living with multiple governance software installations. The next big decision when selecting a governance platform is to decide between an open source solution vs. a proprietary product. Open source benefits include: . Reduced likelihood of vendor "lock-in". . Compliance with the "open source only" policy for infrastructure software regulation found in many enterprises. . A reduced financial outlay, which makes it more likely that the organization will elect to implement this kind of governance software. Proprietary solutions benefits include: . Solid integration with design, development, and management tools. . Simpler "one-stop shopping" that simplifies things, while yielding a better "out of the box" experience. . Growing trend of software vendors delivering their solutions as open source. Strategy 3: /"Make sure your governance platform is able to support a full range of service deployment technologies."/ Scope: Design-time Although many people make the mistake of viewing Web services as the only way to implement a Service Oriented Architecture, there are other technologies that can get the job done just as well. These include Java objects, CORBA, and other service implementation approaches. With this reality in mind, it's vital that your governance platform be able to recognize and work with a broad range of services, regardless of the chosen implementation strategy. As a bonus, the governance solution should be as non-intrusive as possible, since there's a good chance that it won't be possible to alter the pre-existing services present in your organization. If you fail to select a governance solution that meets these criteria, odds are that you'll either only govern a portion of your enterprise, or will need to deploy multiple governance platforms. Neither of these outcomes is desirable; partial governance is not much better than no governance at all. Many administrators and developers have wasted copious amounts of time going down the wrong paths when trying to overcome a governance-related problem when a comprehensive picture of all software resources would have pinpointed the issue. Strategy 4: /"Recognize the importance of testing as part of your overall SOA governance responsibility."/ Scope: Testing & Quality Assurance It's an unfortunate fact that quality assurance often takes a back seat to its more glamorous software development sibling. While this may be tolerable when building traditional siloed applications, it doesn't work in an organization that's undertaking a Service Oriented initiative. Given that services form the foundation for multiple applications, it's vital that testing receive the proper amount of time and attention. The overall scope of quality assurance expands as well: it's essential that your testing go beyond individual services to include complex compositions of multiple services. Composition testing often requires significant performance-driven regression testing. Since run-time composition usage can be difficult to decipher, it may be necessary to employ scoping or other monitoring technologies to determine true service interaction. Finally, since testing and governance are so closely related, it's wise to give serious consideration to integrating your chosen testing software into your overall governance environment. Figure 1 shows an example of service testing software being utilized in a governance-related capacity. In this case, we're measuring service test coverage to ensure that our quality assurance efforts are as far-reaching as possible. /Figure 1/ Strategy 5: /"Collect important governance-related metrics and review them regularly."/ Scope: Run-time Modern governance platforms can capture enormous amounts of operational data. The sheer quantity of this information can be overwhelming. Unfortunately, when faced with a statistical flood of biblical proportions it's natural for administrators to simply ignore the data, unless there's an immediate problem that needs rectification. The lesson here is that gathering metrics isn't enough -- you need to review and possibly take action on them. It's common for these metrics to contain intelligence that can be used to predict future issues. This means that astute governance experts may be able to prevent these anomalies before they even occur. To help enable this predictive, pro-active problem solving, make sure that you gather and review the information provided by your governance package. While many governance solutions are not known for the quality of their graphical capabilities, there are several best-of-breed business intelligence products that you can employ to make sense of the mountains of data that you're likely to generate. Figure 2 illustrates how governance software can be used at runtime to monitor service level agreements (SLA). Since these contracts often carry a financial penalty for breaches of their terms, it's incumbent upon administrators to pro-actively monitor service performance. /Figure 2/ Strategy 6: /"Track activity through multiple IT resource layers."/ Scope: Testing & Quality Assurance/Run-time While a service-oriented initiative is aimed at centralizing business logic into a collection of reusable, composable services, it's important not to forget that these services often simply place a facade over existing resources such as databases, application servers, objects, and so on. The result is an architecture made up of many "moving parts". With all these potential points-of-failure, it's natural that issues become more difficult to resolve -- simply identifying the source of the problem can be an overwhelming burden. In many cases, the issue isn't the fault of the service, but the underlying resource. However, users don't care where the problems initiate: they only want them solved (or prevented!). If only to address this reality, it's vital that your governance platform be able to monitor and interact with assets other than traditional Web services. By providing administrators with a comprehensive overview of all technology resources, a well-designed governance solution can help prevent problems from occurring, as well as assist in rapidly resolving any issues that do take place. Strategy 7: /"Break down the barriers between repositories and registries."/ Scope: Run-time There's a great deal of confusion between these two types of product; different definitions and delineations of responsibility abound. However, regardless of the exact description of these products, both have a role to play in an effective SOA implementation, including the design and run-time phases. The following describes how each product is typically utilized in these two critical phases. Service registries answer these design-time questions: . Where is the service? . What is its purpose? (generally in brief) Service registries answer these run-time questions: . What is the service's version? . Where is the service's contract? . What policies are in effect for the service? Service repositories answer these design-time questions: . What is its purpose? (generally in more detail) . What are the versions (including code) of the service? Service repositories answer these run-time questions: . Who's been using the service? . What kind of responsiveness is the service providing? . What's gone wrong with the service? Finally, it's important to note that significant numbers of vendors are actively combining registries and repositories. Whether or not you deploy an integrated solution, it's wise to make sure that whatever investments you make are capable of addressing the responsibilities I just described. Strategy 8: /"When selecting a governance technology product, write a well-planned, formal RFP."/ Scope: All phases Although evaluating and selecting a solution from all of the available governance technologies can be a daunting task, there are time-tested patterns that you can leverage when making this momentous decision. To begin, it's vital that you know what you need: there is no substitute for homework and preparation. Follow the same discipline and processes that you did when selecting a database, application server, or other key infrastructure technology. Resist the temptation to employ a boilerplate RFP; make sure it reflects your organization's needs. If you're not comfortable writing these kinds of documents, give serious consideration to hiring a vendor-agnostic external consultancy to write one for you. However, remember that if you're using outside help to design and/or implement your SOA, try to keep the RFP creation process separate from the technology vendor; it's easy to imagine for a serious conflict of interest. Next, to get vendors to take your RFP seriously (and respond accordingly), focus on quality, not quantity. Finally, once you've narrowed down your potential governance suppliers to a short list, it's common to ask these prospective vendors to participate in a pilot project or proof-of-concept. Strategy 9: /"Avoid governance tools that require code modifications."/ Scope: Design-time and Run-time In order to be effective, certain governance products necessitate code alterations such as incorporating special headers, configuration files, or linking with proprietary libraries. This requires complete developer compliance, which is difficult to obtain even under the most favorable conditions. If even one service is deployed without these added components, you won't be able to get a true picture of your environment, which can lead to erroneous decisions based on incomplete, inaccurate data. In addition to complicating the lives of your developers and reducing the likelihood of effective governance, these kinds of proprietary extensions can also seriously damage your chances of being vendor-agnostic. For all of these reasons, it's crucial that any governance solutions that you deploy do their work as non-intrusively as possible. Strategy 10: /"Make sure that the governance tool fits into your existing IT governance landscape."/ Scope: Run-time For most organizations, undertaking a service oriented initiative introduces a host of new toolsets, processes, and methodologies. Governance is just one of the added considerations, but it's important to note that this topic is not new for the majority of these enterprises. In fact, IT-focused governance technology has existed for many years: some of the best-known products include Tivoli, OpenView, and Unicenter. These packages are frequently used to monitor the health of servers, client computers, networks, and software applications. IT organizations have extensive knowledge of these solutions and rely on them to keep operations running smoothly. As services become a larger part of your computing infrastructure, it's unwise to force your IT organization to learn and maintain completely different toolsets: ideally, your SOA governance tools should cleanly integrate with other IT management platforms. Excessive complexity and training requirements lessen the chance that governance software will be used. *Conclusion* It's important to realize that while certain already-deployed SOA initiatives may appear to be successful in the absence of formalized governance methodologies and supporting technologies, it's quite likely that sooner or later events will transpire that challenge this perception. For those enterprises that are now commencing their own SOA undertaking, it's wise to factor in governance considerations from day one, rather than waiting for a crisis to arise. Selecting necessary governance technology will be much more successful if the organization commits to using a formalized, vendor-agnostic RFP process. No matter what governance technology is chosen, it's imperative that it be able to recognize and manage services constructed on any of the popular development platforms. In fact, many real-world services will be built upon traditional application components: the governance solution should be able to adapt to this reality. Given the close relationship between quality assurance and SOA governance, governance technology should be able to interact with relevant QA solutions, as well as team with mainline IT governance platforms. By following a few, relatively simple SOA governance technology guidelines, the odds are definitely on the side of the progressive IT organization as it seeks to protect the substantial investments in people, process, and technology mandated by a service-oriented initiative.>> Gervas Douglas 2008-11-18T13:12:16 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8980 I think that's the major problem faces also by many clients. It's one of the service I offer. :) H.Ozawa --- In service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "Nick Gall" <nick.gall< at >...> wrote: and coming of ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ htshozawa 2008-11-18T12:30:30 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8979 Are you implicitly trying to tell us that Domain Oriented Model/Methodic/Method is DOOM? H.Ozawa --- In service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, Michael Poulin <m3poulin< at >...> wrote: domain specific SOA implementation standards: for ... Telecom, Kindergarten or Ice-cream Kiosks SOA for Telecom Magazine about initiative in creation of SOA for Telecom: http://www.soamag. com/I23/1108- 3.asp tells me that I better to start a SOA for ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ htshozawa 2008-11-18T12:48:17 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8978 The topics you've mentioned isn't because of B-SOA. If the end interface is application specific, it probably because the person who designed an interface actually didn't take SOA governance into account and designed an interface in the old fashion manner for a particular application. The first step should be to define the goal and to assess the current situation (As-is in EA) which includes the current technology. SOA does not necessary mean developing an new system - it may be more of making better usage of the current resources. :) H.Ozawa --- In service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, "Nick Gall" <nick.gall< at >...> wrote: wrote: OASIS (so goes and still successful constant refrain the end of the service ref=g_search&id=797713> service of providing business. the "top that "bottom up" innovative Internet. to be Do all after all transom to tweak the refrain designs work ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ htshozawa 2008-11-18T12:44:15 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8977 I propose to use following acronym for those who want to build domain specific SOA implementation standards: DOSOM – standing for Domain Service-Oriented Model/Methodic/Method for ... Telecom, Kindergarten or Ice-cream Kiosks Other variations are: •SOFDOM – standing for Service Orientation For Domain •SOFOD – standing for Service Orientation For Domain •(SODOM) :-) - Michael ________________________________ From: Michael Poulin <m3poulin-/E1597aS9LQAvxtiuMwx3w< at >public.gmane.org> To: service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org Sent: Tuesday, November 18, 2008 10:42:06 AM Subject: [service-orientated-architecture] Stuart and Richard about SOA for Telecom I have noticed an announcement from OASIS and publication in SOA Magazine about initiative in creation of SOA for Telecom: http://www.soamag. com/I23/1108- 3.asp If people are going mad around me, the instinct of self-defense tells me that I better to start a SOA for Kindergarten or SOA for Ice-cream Kiosks. How about you? - Michael Michael Poulin 2008-11-18T11:31:25 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8976 Given that Gartner has provided all of the above (with the possible exception of how to use UML -- haven't needed it) to its clients and still seen "there's many a slip 'twixt the cup and the lip" from successful business design to successful technical design (which is my constant refrain in this discussion), I'd love to see the following: 1. Examples of the actual service interfaces that come out at the end of all the business-analysis falderal. Far too often, I find that the service interfaces that come out of lots of business analysis are far to application-specific. The best service interfaces are application neutral<http://www.gartner.com/DisplayDocument?ref=g_search&id=797713> . 2. Examples of the service provider architectures behind the service interfaces. Again, far too often such architecture is incapable of providing the continuous availability and other SLAs required by the business. 3. Examples of the quantitative impact on the business of these business-driven services. Since they were business-driven from the "top down", we should expect them to have far more impact that "bottom up" services, ie services that opportunistically took advantage of innovative technology, eg Wal-Mart's adoption of AS2 for EDI over the Internet. Now that I think of it, having written all this out, what you seem to be suggesting, Steve, is using classic waterfall methodology for SOA: Do all the business design completely independently of any technology considerations (which is why I called it "free floating"), and after all that design is completely finished, throw it over the technology transom to the technology troglodytes, with perhaps a tickle of feedback to tweak the business design to fit the technology. Nice dream. IME, Waterfall doesn't work in dynamic environments (esp business environments) whether it's SOA or not. The best approach (here's my refrain again) is to have the best business designers and technology designs work jointly in a series of creative charrettes<http://en.wikipedia.org/wiki/Charrette>at the earliest stages of design among all the stakeholders to ensure a truly unified design. Nick Gall 2008-11-18T11:21:49 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8975 --- In service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org, Michael Poulin <m3poulin< at >...> wrote: Magazine about initiative in creation of SOA for Telecom: http://www.soamag.com/I23/1108-3.asp tells me that I better to start a SOA for As always, Michael, if you can make the business case - go for it! Traditionally (i.e. from about 15 years ago to about 3 months ago) Financial Services and Telecommunications were seen as two, rich, early-adopter major sectors. Whatever meltdown Financial Services goes through in the near term, it isn't going to disappear in a hurry. By its nature it handles large amounts of money, some of which it can and needs to spend. The great thing about Telecoms is that people carry on making phone calls, transmitting data and accessing the Internet - in other words even in a time of belt-tightening or capital meltdown/restructuring, cash flows. There are many weaker sectors to pick out - car manufacturing is an obvious one. If you want to pick a new sector to apply your SOA/EA skills, have a look at Renewable Natural Resources. Whatever the temporary drop in the oil price, in the long-term this should be a winner. Gervas ------------------------------------ Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/service-orientated-architecture/join (Yahoo! ID required) <*> To change settings via email: mailto:service-orientated-architecture-digest-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org mailto:service-orientated-architecture-fullfeatured-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> To unsubscribe from this group, send an email to: service-orientated-architecture-unsubscribe-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/ Gervas Douglas 2008-11-18T11:16:03 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8974 ZapThink </> Why Today is a Perfect Time for No-Platform SOA Document ID: ZAPFLASH-20081117 | Document Type: ZapFlash /By: Jason Bloomberg/ Posted: Nov. 17, 2008 ZapThink's integration cost curve <http://www.zapthink.com/report.html?id=ZapFlash-10232002>, which we published back in 2002, continues to stir discussion amongst our Licensed ZapThink Architects <http://www.zapthink.com/lza.html>. In brief, our argument is that while traditional middleware-based integration leads to unpredictable spikes in cost when business requirements change, taking a Service-Oriented Architecture (SOA) approach to solving integration challenges leads to a flattened cost of change. Implementing SOA means building for change, so the argument goes, so while there will continue to be some ongoing costs, a fundamentally agile architecture will smooth out the ups and downs of IT integration expense. Cut to the end of 2008. Today, in spite of ZapThink's repeated warnings about taking an ESB-first approach to SOA <http://www.zapthink.com/report.html?id=ZAPFLASH-2008530>, many organizations have bowed to vendor pressure and have undertaken an ESB-first, "SOA platform" approach to implementing SOA. As we stated in that ZapFlash, it's possible to implement SOA with an ESB, and many organizations are doing just that -- but the essential best practice is to leverage the ESB as a Service intermediary, rather than as integration middleware. Placing this best practice in the context of our integration cost curve, leveraging an ESB as integration middleware will lead to the spikes in cost when requirements evolve, eliminating the flattened cost of change benefit that SOA promises. Only by taking an architecture-first approach to SOA will oganizations be able to achieve this benefit. *Middleware for your Middleware?* We're now seeing evidence of this trend in the marketplace. As organizations attempt to scale their SOA platform-centric SOA implementations, they soon run into problems. Because of the size of today's enterprises, no single platform addresses the SOA infrastructure needs of the entire organization. As a result, they must implement different platforms for different parts of the business -- what some analysts are calling "SOA domains" (not to be confused with the business-centric notion of Service domains <http://www.zapthink.com/report.html?id=ZAPFLASH-10272004> that ZapThink has been discussing since 2004). Instead, a SOA domain centers on a SOA platform and the Services that are running on that platform. As a result, scaling the SOA initiative requires interactions between SOA domains, which leads to the challenges of interoperating and federating across SOA domains. And how do you best accomplish such interoperation and federation? By purchasing more middleware, of course! Herein lies the most dangerous pitfall of the SOA platform-centric approach to SOA: because it depends upon integration middleware, it succumbs to the issues with middleware that SOA was meant to address, namely the lack of agility and the increasing costs of integration over time. Basically, you'll eventually need more middleware to get your various ESBs running in various SOA domains to interoperate or federate with each other. Now, it's possible to implement SOA in this manner, but if you're unable to achieve either the business agility or cost savings benefits of the new architecture, then why bother? Interestingly enough, it was Mike Gilpin at Forrester Research <http://www.forrester.com/Research/Document/Excerpt/0,7211,46350,00.html> who clued us into the depth of this problem. While Gilpin's report is impeccably researched and internally coherent, his conclusion is incorrect. Basically, his argument is in part that since enterprises have a SOA platform strategy, as they scale their SOA initiatives, they will likely need to interoperate or federate between SOA domains, which will require more middleware. Gilpin, however, fails to take this argument to its natural conclusion, which is a /reductio ad absurdum <http://en.wikipedia.org/wiki/Reductio_ad_absurdum>/: if you assume that implementing SOA depends on a SOA platform strategy, then eventually you'll need middleware for your middleware, which will eliminate the benefits of SOA that led you to the architecture in the first place. Therefore, SOA should not depend on a SOA platform strategy. *Taking the Plunge into No-ESB SOA* This ZapFlash need not delve into the details of how we recommend approaching SOA from an architectural, rather than an integration-centric perspective, as we've covered this topic in great depth in previous ZapFlashes. We advise against caving into software vendor pressure <http://www.zapthink.com/report.html?id=ZAPFLASH-2007920> to take a SOA platform approach. We also explain architecture-driven infrastructure <http://www.zapthink.com/report.html?id=ZAPFLASH-200795>, discuss the intermediary pattern <http://www.zapthink.com/report.html?id=ZAPFLASH-200774>, explain its importance to loose coupling <http://www.zapthink.com/report.html?id=ZAPFLASH-2008228>, and then focus on the difficult task of building and maintaining the Business Service abstraction <http://www.zapthink.com/report.html?id=ZAPFLASH-2007719>. In fact, we warned against middleware for your middleware <http://www.zapthink.com/report.html?id=ZAPFLASH-200561> back in 2005. Interestingly enough, the core principle for the No-ESB SOA approach appeared in our seminal 2002 /Service-Oriented Process/ report <http://www.zapthink.com/report.html?id=ZTB-0111>, where we explained how integration should be a byproduct of Service composition. More than six years later, we're still fighting this battle: integration should be something the business does with the Services, not something IT does to connect one bit of infrastructure to another. Instead, the core technical challenge of SOA is building and maintaining the Business Service abstraction, so that the business can build flexible processes by composing those Services. In other words, SOA requires us to move away from a "connecting things" approach to distributed computing to a "composing Services" approach. After all, the integration-centric approach to business process, what we might call traditional Business Process Management (BPM), has long suffered from the limitations of the technology. In traditional BPM, the process engine is either part of the platform or tightly coupled to it. As a result, even if you're implementing processes by composing Services, those Services must run on the platform, or the engine is unable to adequately control and manage them. On the other hand, if you take a Service-oriented approach to business process, then we're abstracting out the underlying runtime environments of the Services, which can now run anywhere we like -- locally or remotely, on or off the bus, in Java, .NET, or even mainframe environments. Such processes maintain process instance state via the messages the Services exchange <http://www.zapthink.com/report.html?id=ZAPFLASH-20061031>, instead of relying upon the engine to spawn threads or instantiate other objects, which are essentially non-Service-oriented techniques. The point is this: the SOA platform approach to implementing business processes has more limitations than advantages. It impedes cross-platform processes in addition to requiring additional middleware to scale. Furthermore, the larger the implementation becomes, the less agile it is. On the other hand, the no-ESB approach is more difficult, as it requires that the organization get the architecture right, including proper governance, leveraging the intermediary pattern, and all the other aspects of building and maintaining the Business Service abstraction. Most difficult of all is that the no-ESB approach to SOA requires a different way of thinking about distributed computing <http://www.zapthink.com/report.html?id=ZAPFLASH-20081024> that for people comfortable with traditional integration-centric environments feels much like jumping from an airplane without a parachute. That sense of risk, however, is in large part illusory: a combination of unfamiliarity and vendor pressure. It's time to cut the cords and take the plunge into architecture-driven, no-ESB SOA. *The ZapThink Take* If you've been through our LZA course, or even if you've simply been following our ZapFlashes for a while, the no-ESB approach to SOA is clearly appealing to you -- but unfortunately, the software-first alternative has always seemed to be lower risk. After all, if you dive into the no-ESB approach and fail, it's your head that's on the block, but if you buy some big package from your favorite vendor and have difficulties, then your job is unlikely to be on the line. And if the big analyst firms (many of whom are in the employ of the vendors, by the way) say that a SOA platform approach is reasonable, then why rock the boat? Now, however, something has changed: the economy. How well do you think the "middleware for your middleware" story for scaling your SOA implementation will sell in a down economy <http://www.zapthink.com/report.html?id=ZAPFLASH-2008109>? It doesn't matter now if the boss golfs with the vendor's VP of Sales, or if you consider yourself a vendor "shop." Today it's time to economize, and thrift is the word of the day. ZapThink has been saying for years that you probably won't have to buy much software to implement SOA, and now maybe it's time to get the boss to listen. It's still too early to tell just how bad this economy is going to get, but rest assured only some organizations will survive. While SOA promises costs savings and greater agility, two essential elements of surviving a steep downturn, simply having a SOA initiative doesn't guarantee success. After all, you have to /get it right/. If you implement SOA and fail to achieve its desired benefits, or if you attempt to implement it and fail along the way, that doesn't mean that there's something wrong with SOA. What it means is that you didn't do it properly. When we see enterprises who've taken a SOA platform approach consider purchasing middleware for their middleware to scale their SOA initiatives, oblivious to the fact that following that path will prevent them from achieving the goals of SOA, all we can say is that we'll be placing our bets on their competition -- the ones who are taking an architecture-first approach to SOA. Gervas Douglas 2008-11-18T11:07:19 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8973 Surprisingly, Steve's "I think that T-SOA (which Stefan Tilkov defined as being WS-*) is not required for a business to deliver a business SOA approach and that most companies would get more benefit focusing on using it to improve the 80%+ of existing IT spend than they will from focusing on the <20% that is spent on new projects" matches my B- and T-service interpretation very well - Michael ________________________________ From: Steve Jones <jones.steveg-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org> To: service-orientated-architecture-hHKSG33TihhbjbujkaE4pw< at >public.gmane.org Sent: Monday, November 17, 2008 10:10:29 PM Subject: Re: [service-orientated-architecture] Business SOA 2008/11/17 Nick Gall <nick.gall< at >gmail. com>: Nope. What I'm saying now, and saying then, and saying in between is that T-SOA is not a requirement for successful delivery of a Business driven SOA approach. I'm also not saying that Business driven SOA is a free floating set of concepts. I think here could be a misunderstanding on each others terms. For me I think that T-SOA (which Stefan Tilkov defined as being WS-*) is not required for a business to deliver a business SOA approach and that most companies would get more benefit focusing on using it to improve the 80%+ of existing IT spend than they will from focusing on the <20% that is spent on new projects. Steve Michael Poulin 2008-11-18T10:36:14 http://permalink.gmane.org/gmane.comp.web.services.soa.yahoo-1/8972 I have noticed an announcement from OASIS and publication in SOA Magazine about initiative in creation of SOA for Telecom: http://www.soamag.com/I23/1108-3.asp If people are going mad around me, the instinct of self-defense tells me that I better to start a SOA for Kindergarden or SOA for Ice-cream Kiosks. How about you? - Michael Michael Poulin 2008-11-18T10:42:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.web.services.soa.yahoo-1