Gervas,
Yes, I have gone by JP since 1994 when I needed to shorten my name
so that editors would stop removing my quotes due to the unfortunate length
of my last name.
As per your response--YAAHOOO!----I'm not talking to the wall.
Other people get it! Yes, this an amazing way to think about designing the
enterprise, actually designing any system. I have created a whole
methodology around developing out a service contract at the departmental
level, which has nothing to do with technology.
I can't tell you how easy it is to implement new processes with this
organizational architecture.
JP
-----Original Message-----
From: [email protected]
[mailto:[EMAIL PROTECTED] On Behalf Of Gervas
Douglas
Sent: Sunday, March 12, 2006 4:35 AM
To: [email protected]
Subject: [service-orientated-architecture] Re: SOA Infrastructure
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/
