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 <*> 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/
