Hi JP, Yes, we are well aware that business people do not care about ESB, governance tools, registry/repository etc. But at a certain point business requirements need to be automated and for an SOA I would say these are today the collection of system software artifacts that most closely match those requirements.
I think what you are talking about is valid and important but you also seem to be creating a false dichotomy between technology and business. It almost seems as if you are proposing to get out of the IT field and into business and organizational consulting. I completely agree, by the way, that organizational issues are often the biggest impediment to successful SOA project. But I do not see the point of investing in SOA based designs that aren't implementable - meaning I do not see the point of going through SOA analysis and design just to put the resulting diagram on the wall as artwork or something. I use the bank analogy in my book and it's in the courseware we offer. The tellers provide the bank's services to its customers. The customers don't care about the technology used behind the counter (this may be your point) but about the service they are getting. However the bank has to care about what's behind the counter since a good IT system helps provide good service to its customers. We are certainly overloading the word "service" here since it is used for the functions the business provides for its customers as well as the functions the IT system provides for the business's employees. Yes, IT investments haven't paid off. Yes, business people have no idea how to align their investments in IT with strategic goals and really measure the effectiveness of their efforts. Yes, software remains a craft industry without industrial methods that lead to predictable projects etc. But the answer is to fix the technology - or at least part of the answer - rather than ignore it. A positive way to characterize what's happening here is to consider that the software industry has reached a point of maturity. The same old technology is not going to work for today's problems. The grumbling and vendor mistrust so prevalent today is an indication of change. And from this we will see solutions emerge that are a better fit for the next wave of IT adoption. Eric --- JP Morgenthal <[EMAIL PROTECTED]> 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 > === 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/
