You know, there's a new book out that discusses this very approach to business (although I wouldn't call it a methodology). I think it was written by a couple regulars on this list. :)
Speaking of the business angle on SOA, why have their not been any significant discussions on Service-Oriented Analysis? We have business process technology and the accompanying business process analysis, but I've never heard anyone describe exactly what service- oriented analysis is, other than that the outcome should be business service identification and definition. Has anyone tried to come up with a methodology yet? Is it any different than business process analysis or other analysis techniques? -tb On Mar 12, 2006, at 3:35 AM, Gervas Douglas wrote: > It occurs to me that there is another advantage to JP's vision which > is outside the restricted scope of technology, and that is by viewing > each department and individual as a service provider bound by such > agreements as service contracts or SLAs, one provides the tools of > accountability and therefore a justification for their role. > > Too often in companies there is a division in perception between > revenue contributors and resource consumers. Come a period of > financial stress (which at some stage is almost inevitable), the > all-powerful CFO proves he is not a boring bean-counter by wielding an > axe. Everyone seeing this coming starts getting a bit jittery. > Fingers point inevitably at the underperformers (e.g. salespeople who > are under-target for the quarter) or resource consumers (e.g. admin. > and sometimes marketing). The axe swings. Sometimes it swings > counter-productively for the simple reasons that assessments are > oftern too short-term and because of a lack of appreciation of the > value of roles. > > I feel that JP's approach could be developed into a productive new > management methodology. Hey, and then SOA-as-software could provide > the tools to support it. > > BTW, JP, do you prefer to be addressed by your initials? > > Gervas > > --- In [email protected], Todd Biske > <[EMAIL PROTECTED]> wrote: >> >> +1. If I could give it +2, I would. Every time I sit down and >> think about what it takes to make SOA successful, I don't think >> technology ever comes up on my list. >> >> -tb >> >> On Mar 11, 2006, at 3:42 PM, JP Morgenthal wrote: >> >>> Eric, >>> >>> Technology is not required to implement anything. I can take >>> any of >>> the bank services I represented in my example in my post and >>> implement them >>> with humans. Will I still need infrastructure, yes, probably a >>> building in >>> which to work, a phone, a pen, pencil, maybe I'll even throw in a >>> pad for >>> good faith. The one thing I don't need is technology (unless you >>> want to >>> consider the pencil technology, in which case I won't argue). >>> >>> The problem with saying SOA Infrastructure is that it immediately >>> associates in non-technical people's minds that this thing is >>> beyond them, >>> not in their field of vision, "that thing that IT does that we all >>> hate >>> because they're too slow doing it in the first place." >>> >>> I just worked with a company where we used SOA to define the entire >>> enterprise. The CFO and the sales team and the marketing team and >>> the loan >>> team didn't see SOA as technology. They saw it as the way they >>> were being >>> organized. They saw it as the way they define what they do to other >>> departments, they say it as requirement to develop a contract that >>> explains >>> to other groups how to use their services. >>> >>> SOA can be so much more than we're giving it credit for today. >>> It's >>> only recently that I've seen the power of using in organizational >>> management. However, there are many thought leaders in this group >>> and if >>> you all continue to associated SOA with technology in the minds of >>> non-technologists, the whole value proposition of SOA as a way to >>> bridge IT >>> and business disappears. >>> >>> Given your investment in the ESB market, I'm sorry to say, these >>> people could care less about an ESB, a registry or an SOA governance >>> facility. >>> >>> But, for the record, your reply even states an "SOA Application", >>> hence, I say that you're talking about SODA infrastructure and >>> not SOA >>> infrastructure. >>> >>> JP >>> >>> -----Original Message----- >>> From: [email protected] >>> [mailto:[EMAIL PROTECTED] On Behalf >>> Of Eric >>> Newcomer >>> Sent: Saturday, March 11, 2006 10:13 AM >>> To: [email protected] >>> Subject: RE: [service-orientated-architecture] Re: SOA >>> Infrastructure >>> >>> Hi JP - >>> >>> I am not sure what you think SOA Infrastructure means, >>> but to me it means the technology needed to implement >>> an SOA based application - i.e. an application >>> designed using an SOA. >>> >>> The coin in this case has two sides - yes, SOA based >>> design is independent of technology. However, >>> technology is needed to implement the design. >>> >>> I fail to see a problem in calling that technology >>> "SOA Infrastructure." >>> >>> Best, >>> >>> Eric >>> >>> >>> --- JP Morgenthal <[EMAIL PROTECTED]> wrote: >>> >>>> Sorry, but I have to weigh in on the title of this >>>> thread. Here's a blog >>>> entry I just posted at: >>>> >>> http://www.avorcor.com/morgenthal/index.php?entry=entry060311-084440 >>>> >>>> SOA and SODA >>>> Saturday, March 11, 2006, 08:43 AM >>>> When the term SODA first started being bandied about >>>> I was less than >>>> enthusiastic about the terminology. SODA stands for >>>> Service-Oriented Design >>>> of Applications. However, there's been a lot of >>>> recent discussion of a topic >>>> termed "SOA Infrastructure", which has forced me to >>>> re-examine the SODA term >>>> and start to use it to help explain and >>>> differentiate between general SOA >>>> and a technological SOA. >>>> >>>> First of all, I do not believe there is anything >>>> called "SOA >>>> Infrastructure." As I explain SOA to my clients, SOA >>>> is a way of designing a >>>> system. A system is an abstract entity, like a >>>> lighting system, electrical >>>> system, and heating and cooling system. In this case >>>> the system we're >>>> designing is a business system. There's no >>>> infrastructure involved, just >>>> artifacts, components and the relationships between >>>> these two. >>>> >>>> An SOA can be used to design an Enterprise, a >>>> software system, even a >>>> telephone system. There's no limitation or inherent >>>> attribute that says that >>>> a service has to be described as a software >>>> component. To do so only limits >>>> the value of this architectural pattern and sets it >>>> up to be easily >>>> dismissed by non-technological personnel. >>>> >>>> When you get into discussions of SOA infrastructure, >>>> in my mind, you're in >>>> the SODA world. You're specifically talking about an >>>> implementation approach >>>> to a system designed using SOA. Things like >>>> registries and enterprise >>>> service buses are components of a software-only >>>> system. They have nothing to >>>> do with a banking system I designed using SOA that >>>> identifies each of the >>>> specific types of services the bank offers as a >>>> service. >>>> >>>> For example, I can design a bank system with a >>>> checking service, loan >>>> service, loan decisioning service, investment >>>> service, corporate banking >>>> service, etc. In each case, these services represent >>>> more than some Web >>>> service interface to the e-commerce offerings within >>>> each of these areas of >>>> the bank. They represent the service itself >>>> inclusive of the organization >>>> requirements, documents, processes, workflows, etc. >>>> >>>> So, stop abusing the term SOA and use the correct >>>> term for SOA relative to a >>>> software system, which is SODA. >>>> >>>> -----Original Message----- >>>> From: >>>> [email protected] >>>> >>> [mailto:[EMAIL PROTECTED] >>>> On Behalf Of Mukund >>>> Balasubramanian >>>> Sent: Friday, March 10, 2006 6:33 PM >>>> To: [email protected] >>>> Subject: Re: [service-orientated-architecture] Re: >>>> SOA Infrastructure >>>> >>>> Jerry: >>>> >>>> This is indeed a pretty good description and I agree >>>> with most of it. >>>> >>>> I don't agree with making as strict a relation as >>>> that of a type and >>>> instance. I think it is more appropriate to leave it >>>> at the level of >>>> defining architecture as the answer to the question >>>> "what are the parts and >>>> how do they behave" and design is the answer to the >>>> question "how are the >>>> parts actually going to be built". >>>> >>>> Mukund Balasubramanian >>>> CTO/Infravio Inc. >>>> >>>> >>>> >>>> >>>> >>>> -----Original Message----- >>>> From: Jerry Zhu <[EMAIL PROTECTED]> >>>> To: [email protected] >>>> <[email protected]> >>>> Sent: Fri Mar 10 08:29:28 2006 >>>> Subject: Re: [service-orientated-architecture] Re: >>>> SOA Infrastructure >>>> >>>> Alex, >>>> >>>> Many here agree that architecture and design are two >>>> different things and architecture goes before >>>> design. >>>> Some may think that architecture is just a step in >>>> the >>>> design. I disagree. >>>> >>>> One way to differentiate the two is that >>>> architecture >>>> is the form or identity or a type. Design is an >>>> instance of that type and is a model that describes >>>> how the parts are implemented, what materials are >>>> used >>>> etc. A car is an identity as opposed to a boat and >>>> a >>>> generic description of a car is the architecture. A >>>> car can be designed into a wood car, a plastic car >>>> and >>>> metal car etc. So there are infinite designs with >>>> respect to the same architecture. Software >>>> architecture is technology dependent such as object >>>> oriented or service oriented etc. but it is platform >>>> independent. The same architecture can be designed >>>> using different platforms such as J2EE or .Net etc. >>>> >>>> >>>> Architecture has something to do with basic beliefs >>>> that are either accepted or rejected. Design is >>>> about >>>> how basic beliefs about some thing come into >>>> reality. >>>> >>>> Jerry >>>> >>>> --- Alexander Johannesen >>>> <[EMAIL PROTECTED]> wrote: >>>> >>>>> On 3/10/06, Jerry Zhu <[EMAIL PROTECTED]> wrote: >>>>>> >>>>>> Architecture is not designed but defined. >>>>>> >>>>> >>>>> I think you'll find that architecture is used as a >>>>> word describing how >>>>> something is designed, again, pointing back to >>>>> design being something an >>>>> architect does. >>>>> >>>>> But anyways, if you look up the definitions for >>>>> architecture, there are as >>>>> many definitions as there are people trying to >>>>> define it. There is no one >>>>> answer to this, and I assert that the word itself >>>>> should be erased from >>>>> serious computer language. :) >>>>> >>>>> >>>>> Alex >>>>> -- >>>>> "Ultimately, all things are known because you want >>>>> to believe you know." >>>>> >>>> >>>>> - Frank Herbert >>>>> __ http://shelter.nu/ >>>>> __________________________________________________ >>>>> >>>> >>>> >>>> __________________________________________________ >>>> Do You Yahoo!? >>>> Tired of spam? Yahoo! Mail has the best spam >>>> protection around >>>> http://mail.yahoo.com >>>> >>>> >>>> >>>> >>>> >>>> >>>> SPONSORED LINKS >>>> Computer software >>>> >>> <http://groups.yahoo.com/gads?t=ms&k=Computer+software&w1=Computer >>> +software& >>>> >>> w2=Computer+aided+design+software&w3=Computer+job&w4=Soa&w5=Service- >>> oriented >>>> +architecture&c=5&s=121&.sig=fpXcvMH1T7dIWKArM_WfrQ> >>>> Computer aided >>>> design software >>>> >>> === message truncated === >>> >>> >>> __________________________________________________ >>> Do You Yahoo!? >>> Tired of spam? Yahoo! Mail has the best spam protection around >>> http://mail.yahoo.com >>> >>> >>> >>> >>> >>> Yahoo! Groups Links >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> Yahoo! Groups Links >>> >>> >>> >>> >>> >>> >> > > > > > > > > > > > > Yahoo! Groups Links > > > > > > 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/
