tag:blogger.com,1999:blog-7467444810662647963.comments2023-08-01T11:53:26.404+01:00SOA ProcessLawrence Wilkeshttp://www.blogger.com/profile/13110189132992558385noreply@blogger.comBlogger13125tag:blogger.com,1999:blog-7467444810662647963.post-13433273432511395502009-05-22T17:04:57.135+01:002009-05-22T17:04:57.135+01:00When Version 2 of the SAE metamodel was published,...When Version 2 of the SAE metamodel was published, we made it clear that we were not attempting to produce a complete metamodel of business modelling concepts and techniques. However, since we produced Version 2 of the SAE metamodel, a lot of useful standards and notations have emerged, especially at the Business Architecture level, so this is certainly an area we'd like to develop further.Richard Veryardhttps://www.blogger.com/profile/04499123397533975655noreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-65673540511317426672009-05-04T20:46:00.000+01:002009-05-04T20:46:00.000+01:00Although the differences between the Concept Model...Although the differences between the Concept Model and the Business Type Model does not confuse me -- the fact that the SAE UML Profile does not provide stereotypes for the Concept Model leaves me with some undefined choices as to how to tangibly represent the Concept Model in my UML model and have it stand-out that these are part of the Concept Model. Please include a mapping of the Concept Model to the SAE UML Profile when following up with more details. -- thanks.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-57716736838967907232009-02-24T19:21:00.000+00:002009-02-24T19:21:00.000+00:00I just blogged that I think “Big SOA is Dead; Lit...I just blogged that I think “Big SOA is Dead; Little SOA is Thriving” at: http://tinyurl.com/soa-today2 . Ok, maybe Big SOA isn’t “dead”, but certainly struggling to convince companies to invest in BPM, BAM, ESB (Big SOA) in today’s economic climate is a tough, academic sell when they can go Little SOA with positive ROI. Organizations want rapid results– they want SOA Today and not 6-9 months down the line!Jordan Braunsteinhttps://www.blogger.com/profile/07945646697528939430noreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-51309027957843180192008-07-28T08:49:00.000+01:002008-07-28T08:49:00.000+01:00Dr. Chris Harding is Forum Director for SOA and Se...Dr. Chris Harding is Forum Director for SOA and Semantic Interoperability at The Open Group. He has been with The Open Group for ten years and is currently responsible for managing and supporting its work on semantic interoperability and SOA. Before joining The Open Group, he was a consultant, and a designer and development manager of communications software. Chris is a certified TOGAF practitioner.Chris will conduct a workshop on 'Using TOGAF for SOA' at the SOA Conference at Business Technology Summit 2008, held in Bangalore from 22-24 September. This workshop will explore in depth how to develop a Service-Oriented Architecture (SOA) using The Open Group Architecture Framework (TOGAF). SOA is the architecture style of choice for enterprises looking for agility in their IT systems. But it is not a "one size fits all" approach. It can be applied in different ways to meet the needs of different enterprises. To do this successfully, an architect must have knowledge, skill, and good judgement. TOGAF is an industry standard architecture framework that has been developed and continuously evolved since the mid-90’s by representatives of some of the world’s leading IT customer and vendor organizations, working in The Open Group's Architecture Forum. No framework can take the place of skill and judgement, but TOGAF gives an architect knowledge that has been accumulated by others working in many different architectural styles. Over the last two years, members of The Open Group have been working on how to apply TOGAF to SOA. Workshop participants will gain an understanding of SOA features and building blocks, of the TOGAF architecture development method, and of how to use TOGAF to create SOAs for their enterprises.Shagufhttps://www.blogger.com/profile/12254135463317272189noreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-31802399246989256112008-03-11T18:29:00.000+00:002008-03-11T18:29:00.000+00:00I am in the final stages of finishing my Master's ...I am in the final stages of finishing my Master's Thesis and I look at using EA Frameworks towards SOA implementations.<BR/><BR/>http://techinitiatives.blogspot.comCollin Smithhttps://www.blogger.com/profile/06531569154370269314noreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-62391550873860440242007-12-12T17:42:00.000+00:002007-12-12T17:42:00.000+00:00Martin,Many thanks for the information. I shall be...Martin,<BR/><BR/>Many thanks for the information. I shall be following up as soon as I am able!Paul Allenhttps://www.blogger.com/profile/12346602280044954044noreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-88889785580137263762007-12-11T10:43:00.000+00:002007-12-11T10:43:00.000+00:00Thanks for your comment. I have posted an answer h...Thanks for your comment. I have posted an answer here: <A HREF="http://soaprocess.blogspot.com/2007/12/good-business-modelling-and.html" REL="nofollow">Good Business Modelling and Decomposition</A>.Richard Veryardhttps://www.blogger.com/profile/04499123397533975655noreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-6721606162720514432007-12-11T04:09:00.000+00:002007-12-11T04:09:00.000+00:00I agree with the fact that SOA is hyped much more ...I agree with the fact that SOA is hyped much more than what it actually deserves - the basic tenet that is put forward by industry and vendors clearly indicates that SOA process is no different from "Good Business Modeling and Decomposition" except that there is more emphasis on streamlining, standards and products (that adhere to these standards).<BR/><BR/>Regards,<BR/>Vasu, WiproAnonymousnoreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-6072752806243246902007-12-10T22:30:00.000+00:002007-12-10T22:30:00.000+00:00Paul,The TMForum and CBDiForum have a collaboratio...Paul,<BR/>The TMForum and CBDiForum have a collaboration agreement that you can work through, contact John Reilly jreilly@tmforum.org and Tony Richardson tonyr@tmforum.org for how you can participate in teams. Alternatively join the TMForum and teh working teams (Architecture Harmonisation and/or SDF), check to see if your company isn't already a member.<BR/><BR/>In the interim I can suggest the TMForum Community pages and the SDF team discussion area, for this you do not need to be a TMForum member:<BR/>http://www.tmforum.org/community/forums/default.aspx?GroupID=25 <BR/>BR<BR/>MEHScooterhttps://www.blogger.com/profile/15432596526049825831noreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-85470905675300112062007-12-07T16:44:00.000+00:002007-12-07T16:44:00.000+00:00On Basic Principles: While we did think about =pro...On Basic Principles: While we did think about =providing introductory coverage, we felt we had trod that ground pretty well before in the cited references to previous material and didn’t want readers to feel we were just repeating things they already knew. However on reflection I think this is a fair point, so we have added appropriate information and links on this site.<BR/><BR/>On Decomposition/Composition: These are techniques that are important in both consume and provide tracks. However, like all techniques, they have their limitations (“If your only tool is a hammer, the whole world looks like a nail). The SAE process defines techniques as first class citizens that can be usable in different tasks and disciplines. <BR/><BR/>On Project Orientation: This is correct in so far as the Total Architecture approach (overlaid here on to the SAE process) is pretty much project oriented, though I would say oriented toward “large projects”. Of course you have to (ideally at least) start things off in the right business context, which is what SO Business Requirements Planning is all about. However this article focuses very much on the Architected Solution Process, without going into – albeit important – surrounding areas. In addition, we have covered the relationship between enterprise and project processes at a high level (in my February journal article on SO Process) and also between program and project management (in the Sept and Oct journals on SOA Project Management). Finally, a lot depends on how large the project scope is, and in this particular context we are talking large enough to cross different business processes (for example a breadth first inventory across business processes is conducted as part of the Solution Architecture and Design work). I’m sure Paul Brown could expand, but it is important to realize that Synthesize Solution Architecture “begins with an initial breadth-first inventory of all the business processes that appear to be impacted by the project. This inventory is based on the business goals set forth in the project charter (an output from SO Business Requirements Planning)” and to note the section “Assessing the Wider View”.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-18519330081718583242007-12-07T16:39:00.000+00:002007-12-07T16:39:00.000+00:00The process described has it's historical roots in...The process described has it's historical roots in many different influences and previous processes through structured methods, OO, CBD and now SOA. For my part our original thinking (published in February) echoed the supply-consume separation found in Select Perspective. The Architected Solutions overlay could perhaps be seen as incorporating OO solutions refinement, found in thinkers such as Booch, on top of the CBD mindset. So it's maybe no surprise to see this process likened to something else.<BR/><BR/>We would be interested in collaborating with the TMForum and communicating these ideas to the TMForum. In addition we would like to learn more about the relevant work that is taking place there. Please could you advise on the best way for us to do that?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-41199852456581446312007-12-04T09:11:00.000+00:002007-12-04T09:11:00.000+00:00I probably have to read 2 or 3 more times -- but I...I probably have to read 2 or 3 more times -- but I like to drop some early comments. Getting this part of the process right is imho one of the key area for SOA success. The other one getting hold on a proper baseline for decomposing a problem domain (like an enterprise) into services that ensure enduring agility.<BR/> <BR/>I would suggest spending some time on first explaing the essential mental model, principles if you like, underpinning all this work. Although I believe I am pretty much an insider on the subject, I found it pretty hard to read/digest.<BR/> <BR/>It seems to be very much project oriented. <BR/>1) I believe effective SOA essentially starts with a business-2-business collaboration (if it is clear that this collaboration is not clear -- don't start an IT project yet). It seems this required collaboration is being addressed in the middle of the second column on p-8 -- but only as part of a 'refinement' step. For me it should be the starting point. With b2b I either mean domain-, process- or 'object/entity' boundaries. (the other essential key area for success)<BR/>2) The SOA demand-supply model should imho be executed over the top of multiple projects. You are very right that it is a constant refinement based on learning and constraints found along the way.<BR/>3) The model doesn't seem to cater for the fact that might be multiple solutions might request for the same service. Having more than one use case in vision greatly enhances the chance to find good, reusable, stable services.<BR/>4) In real life budget-level governance is very importance as well. Getting a service provider (owner/LOB responsible) to invest for (initially) the benefit of others is usually not something that can be arranged for in the scope of a project. This should be done (prepared for) in business(case) planning and indeed a service portfolio process that spans indifvidual projects.<BR/> <BR/>Not the essence of this article, but the notion of architecture is being used very incosistent.<BR/> <BR/>On the provide side the notion of service versioning (and deprecation) could receive more attention. It is a provisioning responsability to decide if a new service should be provide as the result of a specific demand or that an existing service need to be extended (ensure compatability existing consumers) and whether/when a specific service should be taken out of production (including the separate responsability of a consumer to switch over to a newer version).<BR/> <BR/>Separate consumer from provider as an architecture principle seems to be well adhered to for the consume and provide processes. In the enable process this distincition seem to be blurred however. In my experience this quickly leads to the Enterprise Spaghetti Box. <BR/> <BR/>In real life budget-level governance is very important as well.<BR/> <BR/>Small point. In figure-3 security is being mentioned as a provide item only. I believe this is/should be equally true for the consume side of the equation.<BR/> <BR/>Nevertheless -- keep on the good work!Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-7467444810662647963.post-7932114840583606572007-11-30T20:55:00.000+00:002007-11-30T20:55:00.000+00:00This essentially describes the processes of the es...This essentially describes the processes of the established TMForum NGOSS Lifecycle, the difference being that this work ads value in modelling the process whilst the NGOSS work in documents like GB924 describe the roles travelling around the 4 NGOSS phases of Business, System, Implementation and Deployment. This process work should be contributed to the TMForum eTOM team and the Service Delivery Platform teams. BR MEHScooterhttps://www.blogger.com/profile/15432596526049825831noreply@blogger.com