Greg and I had to tackle this question when writing our book (of course), and what we came up with is:
"An SOA is a style of design that guides all aspects of creating and using business services throughout their lifecycle (from conception to retirement)." In the preface we put it a little less formally, and included a bit more detail about the lifecycle: "An SOA is a style of design that guides an organization during all aspects of creating and using business services (including conception, modeling, design, development, deployment, management, versioning, and retirement)." It is entirely correct that an SOA is not the same thing as an enterprise architecture. The focus of the SOA is the blueprint or style of design - that is, the particular approach - to applying services to address a range of IT requirements. But certainly not to imply that services and the SOA style of design solve everything. The city planning analogy has been used for some time, and I think it is probably more appropriate to enterprise architecture than SOA, although in some cases the analogy is has meaning for an enterprise wide SOA that federates several technology and application domains or departments. The construction analogy is also a good one, and often debated. The main point for me in the construction analogy is the application of standards at the points at which building materials are joined together. The architect is responsible for creating a plan and a blueprint for implementing the plan, but he or she needs to know how the building materials can fit together to realize the plan. In other words, technology is important since a building plan for an unbuildable structure isn't very useful. Another good analogy that's been used successfully (including a book chapter I wrote with Peter Conklin back in 1996) is the automobile industry's validation of the concepts of mass production, which revolutionized manufacturing and changed the world. The key enabling innovation was not the assembly line but the availibility of standardized, interchangeable parts from multiple suppliers. This is what allowed automobile manufacturing to achieve the transition from a craft industry (in which each car was made by hand) to a mass production industry. The software industry has yet to achieve this transition, but the availability of interchangeable parts standardized as services will be key. SOA in this analogy is the assembly line. Eric --- Todd Biske <[EMAIL PROTECTED]> wrote: > The part that didn't sit right with me was the line > before the one > you called out. I feel that the process defines > how something gets > done, and the service defines more of what is being > done. The > problem with going to the "plan" metaphor is that > SOA does not equal > EA. To me, SOA merely states that a core unit used > in describing > the architecture is a service. Services alone are > not enough. To > use the city planning analogy (timely sidenote, I > just posted a blog > entry that discusses the city planning analogy > before reading this), > SOA would just tell me I'm going to have a retail > district in these > areas, a residential district here, hospitals here > and here, etc. If > this is all I do, I won't have a successful city. I > need to > determine what the interconnecting roads are, the > traffic patterns, > power grids, etc. That spans into enterprise > architecture. I would > edit the abstract so that the macro view is about > making SOA fit into > the broader enterprise architecture. > > All of this aside, I think the subject you're trying > to address is > one of the biggest challenges for IT right now. I'm > working on a > vision document whose goal is to get people to > understand that simply > looking at existing projects and identifying some > service boundaries > (your micro view) will not yield an enterprise SOA. > At the same > time, using the thoughts in my blog entry, no CxO is > about to evoke > eminent domain over the entire enterprise and > bulldoze it to start > from a macro view. Hopefully, you'll put some of > your thoughts from > the presentation up on your blog after the talk. > I'd love to see > what you have to say. > > -tb > > > On Jan 12, 2006, at 7:39 AM, JP Morgenthal wrote: > > > Today, I had to send in an abstract for an SOA > talk at LinuxWorld > > Canada. In that abstract, I had to capture the > essence of SOA for > > a wide audience, not just IT practitioners. This > was a great > > exercise, but based on Annes slide, Id like to > float the results > > of my efforts across the group to see what the > general consensus is > > on my thinking. > > > > > > > > The abstract is provided in full below so you can > see everything in > > context. However, the line Id like to focus on > is The SOA is the > > plan for how that service will be deployed, > accessed and managed. > > For me, I think the greatest dilemma around SOA as > a term is the > > word architecture. I started picking apart the > term in an effort > > to define it and, to me, architecture is a plan. > A building > > architecture is a plan, its not the foundation > (ESB), its not the > > beams (SOAP), its not the floors (services). > Its a plan of how > > all these things will come together into a complex > structure that > > wont fall down. > > > > > > > > Many individuals on this list carry great weight > with their words > > in the industry and upon reading their take on ESB > and other > > attributes of SOA, I find much of the thinking > focused on SOA being > > implementation-oriented rather than a plan. Its > my belief that > > when we discuss SOA, we need to realize that every > SOA is not going > > to be identical in the way that every building is > not going to be > > identical. However, there are some basic rules of > engineering and > > physics that need to be adhered to, or the > building will fall > > down. I believe its these aspects of SOA that we > need to capture, > > catalog and teach when developing and SOA. After > that, lets see > > how magnificent the buildings can get! > > > > > > > > > > > > ABSTRACT > > > > ========= > > > > SOA: The Macro and Micro View > > > > > > > > Service-Oriented Architecture (SOA)the micro > viewis a powerful > > approach to developing and deploying software > systems. At the > > macro view, however, SOA can have far reaching > impact for > > departments other than IT. The service is rapidly > becoming the > > representation of a unit of work within the > enterprise. If process > > represents the what has to get done, then the > service represents > > the how to get it done. The SOA is the plan for > how that service > > will be deployed, accessed and managed. This > session will show > > attendees how to grow from a single service to an > enterprise-scale > > SOA in a pragmatic fashion. It will also show > best practices for > > development of services contracts and service > management. > > > > > > > > > > > > > > > > > > > > From: > [email protected] > > > [mailto:[EMAIL PROTECTED] > On Behalf > > OfAnne Thomas Manes > > Sent: Tuesday, January 10, 2006 5:11 PM > > To: > [email protected] > > Subject: Re: [service-orientated-architecture] > Executive Summary > > Request: SOA on One Page > > > > I have attached a slide that I frequently use to > describe some of > > the basic concepts associated with SOA -- > specifically the concept > > of multiple applications sharing the same set of > services. > > > > This slide certainly does not completely describe > SOA, but I find > > it a useful starting point. > > > > Anne > > > > On 1/9/06, ballietf <[EMAIL PROTECTED]> wrote: > > > > Has any one described SOA on one PowerPoint slide? > If so, is it > > something you can share with me? I received a > request for such > > a "picture" from a senior executive and, in the > name of "re-use", I > > prefer to leverage the good work of another rather > than create my own. > > Thanks for the help. > > > > > > > > > > > > > > > > > === message truncated === __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
