Dear Jerry,
I agree with your differentiation. I see architects in three areas:
1. Business Architects
2. System Architects
3. Technical Architects
I use the term business architect to mean a role played by a person
such that they are responsible for extracting business requirements
both functional and non functional and business processes (the
structured ordering of interactions).
A business architect collaborates with a systems architect to ensure
that requirements and business processes are well formed and
consistent.
I use the term systems architect to mean a role played by a person such
that they are responsible for mapping business requirements and
business processes into a formal description of a system.
A systems architect collaborates with a business architect to establish
design principles.
A system architect collaborates with a technical architect to ensure
requirements and business processes are well formed and consistent.
We use the term technical architect to mean a role played by a person
such that they are responsible for mapping a system into a set of
technologies that can realise a system.
A technical architect collaborates to establish design principles.
A technical architect establishes design constraints.
An architect for an application may only look at a single service. If
they do so they are not looking at the system as a whole. Often system
architects play the role of application/technical architects when
needed.
Infrastructure could well mean technology architecture but I think it
better to say that technology infrastructure is a realisation of a
technology architecture as opposed to it being the architecture.
Otherwise it would be a bit like saying the architecture that my
architect produced for my house extension is in fact my house
extension. When we look at a building we often say "ah that
architecture is of the edwardian period". This doesn't mean that the
building is the edwardian period it means that the observable aspects
of the building conform to a well known pattern used by architects of
that period. Software systems may be seen in a similar way.
I agree with your multiple architecture view. One may well say that a
software system has a message based architecture for its infrastructure
- which is an architectural style. One may also say that the
information architecture of a system is based on an entity-relationship
architecture. And one may say that the system as a whole is based on a
service oriented architecture. With the first we can look at topics and
queues and say there is some notion of description but it is clearly
not complete for the system as a whole. With the information
architecture we may well have a formal description as an ER model. With
the latter we may have no formal description at all just service
definitions, which I would say is not an architecture because it fails
to express the system, rather it deals with discrete services paying no
heed to the overall architecture. In many systems having a formal
description of the latter enables you to drive the others. One should
be able to write down what information (messages and their types) get
sent from what to what and when and the ordering of all message
exchanges between all services. This is what allows one to derive
service descriptions, understand what message types are needed, tie in
service level agreements to business and so on. Without the high level
system description it all becomes something in someones head which is
never a good thing for any business.
Cheers
Steve T
On 16 Mar 2006, at 23:49, Jerry Zhu wrote:
> When we talk about architecture we need to be aware of
> the context. Is it about software application or
> enterprise wide IT planning? Each has different kinds
> of architectures. In software application, for
> example, there should be three kinds of architectures:
> data, software, and system. For enterprise, there
> could be more architectures as defined in FEAF.
>
> Infrastructure could refer to technology architecture
> in EA. It may also refer to application's system
> architecture. When we talk about buildings, there
> maybe only one architecture. Building are things or
> simple systems. Business or a software system is a
> complex system that needs to be viewed in
> multi-perspectives, hence multiple architectures.
>
> Jerry Z.
>
>
> --- Steve Ross-Talbot <[EMAIL PROTECTED]> wrote:
>
> > I think it is wholly unhelpful to mix these terms.
> > Let me explain
> > further. There is a famous building in Paris (the
> > Pompideux centre). It
> > is a building that has an architecture which is
> > something that
> > architects produced. It's infrastructure is visible
> > on the outside of
> > the building - unusual because most are embedded or
> > on the inside. The
> > architecture was the blue print by which the
> > structural engineers and
> > builders delivered what was required. The
> > architecture simply stated
> > that the infrastructure was to be put on the outside
> > and gave a clear
> > description of what that meant.
> >
> > Clearly we do not talk about the architecture
> > infrastructure of the
> > Pompidu Centre being on the outside. We do talk
> > about the
> > infrastructure being on the outside. The danger is
> > that we further
> > promote poor understanding as to what is meant by
> > architecture and we
> > confuse it with infrastructure. Only this week I
> > heard a CEO confuse
> > the two thinking that the infrastructure was the
> > architecture.
> >
> > Whilst I am on the topic I would like to make sure
> > we are all of one
> > mind. Architecture is not something that we do. It
> > is not a verb. It is
> > an artifact that is produced in the course of
> > building a system.
> > According to TOGAF it is "A formal description of a
> > system". According
> > to UML it "the organizational structure of a
> > system". Architecting is
> > something that Architects do and the output of what
> > they do is an
> > Architecture. I suggested at Web Services on Wall
> > Street and I have
> > still to hear anyone counter this - I'd love to have
> > a debate and learn
> > new tricks from those more learned than I - that
> > there is not A in SOA.
> > There is no clear, precise way within the accepted
> > tools sets that can
> > be said to define the SOA space, that are being used
> > or can be used to
> > "formally describe a system" or to describe "the
> > organizational
> > structure of a system".
> >
> > It would be very nice if in this group of interested
> > parties we could
> > actually establish what we mean by architecture and
> > then be clear about
> > how this might differ from the prevailing wisdom of
> > TOGAF, UML, OMG and
> > others. And if it doesn't how one might actually
> > encode an
> > Architecture. Is UML sufficient? Can we describe
> > all of the
> > interactions that occur between a set of services
> > using UML in an
> > unambiguous way? Could we do with BPEL or BPMN?
> > Could we do with
> > WS-CDL?
> >
> > Why should we care? Pretty simple really. When you
> > Architect in the
> > world of civil engineering, electrical engineering
> > and so on, you use a
> > formal description of the system (not all the detail
> > but enough) to
> > simulate and test. This is how Architects find that
> > the stress levels
> > on a specific beam are too high or find that they
> > have over specified
> > some tolerance can reduce the cost of a component.
> > Without such a
> > description this cannot be done. I would content
> > that we should do the
> > same in software. If you cannot write down your
> > Architecture then you
> > do not know enough about what you are doing, and you
> > will have a high
> > risk of failure because of this.
> >
> > I believe we can do better and make the dream of SOA
> > a reality in a
> > lower cost and lower risk way. In effect I think we
> > can put the A back
> > into SOA as opposed to continual talk of SOA when we
> > really only mean
> > Service Orientation - which is a step higher than
> > Object-Orientation.
> >
> > The above rantings are not just the work of a
> > demented long in the
> > tooth perhaps should retire too old software guy.
> > Rather they are an
> > extract of many discussions with many practicing
> > Architects who deliver
> > real systems (not software products) that deliver
> > real business benefit
> > to real customers.
> >
> > Thoughts please .........
> >
> >
> > Cheers
> >
> > Steve T
> >
> > On 15 Mar 2006, at 13:56, Ron Schmelzer wrote:
> >
> > > So, what exactly is architecture infrastructure?
> > Aren't these two
> > > different things... does it make sense to even
> > combine these two words
> > > together?
> > >
> > > Ron
> > >
> > > Anne Thomas Manes wrote:Gregg,
> > >>
> > >> A SOA infrastructure [sorry JP, but I think this
> > term is useful]
> > >> ought to support any type of communication style:
> > synchronous vs
> > >> asynchronous, request/response vs one-way, direct
> > connection vs
> > >> brokered, queued, pub/sub, Linda, etc. It's even
> > better if the
> > >> infrastructure is natively supported by most
> > development platforms.
> > >>
> > >> I think this last point is the most serious
> > downfall for J/JS. You
> > >> had the luxury of developing your own
> > communication infrastructure,
> > >> and you chose to base it on J/JS. (I think this
> > was a great decision
> > >> for you.) Most organizations don't have that
> > luxury, though. For
> > >> them, software infrastructure development is not
> > a core competency.
> > >> So they buy it. And because a communication
> > infrastructure is such a
> > >> critcal component in their IT systems, they tend
> > to buy it from
> > >> solid, stable vendors -- IBM, Microsoft, BEA,
> > Oracle, SAP, etc. None
> > >> of these vendors provide native support for J/JS
> > (or any Linda system
> > >> for that matter).
> > >>
> > >> I've always been a big fan of Linda, but you
> > must agree that it's a
> > >> fringe technology. It's been around for ever, but
> > never been a part
> > >> of the mainstream. The key advantage I see for
> > using SOAP as the
> > >> foundation for SOA is that *everyone* provides
> > native support for the
> > >> technology.
> > >>
> > >> Anne
> > >>
> > >> On 3/14/06, Gregg Wonderly <[EMAIL PROTECTED]> wrote:
> > Anne Thomas Manes
> > >> wrote:
> > >>> > I understand that the JERI stack opens J/JS
> > up to allow
> > >>> integration with
> > >>> > other languages and protocols, but there are
> > a number of features
> > >>> in J/JS
> > >>> > which are available only to Java
> > applications.
> > >>>
> > >>> There are a number of Web services features
> > that are only available
> > >>> to web
> > >>> services applications.
> > >>>
> > >>> Where is the line drawn to differentiate?  I
> > am not sure what
> > >>> missing features
> > >>> you think are problematic or which would cause
> > problems.  Can you
> > >>> share some
> > >>> specific concerns?  This is really an
> > interesting issue for me.
> > >>>
> > >>> At some point, the technology of choice is
> > visible
> === message truncated ===
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam? Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
>
>
>
> YAHOO! GROUPS LINKS
>
> ▪ Visit your group "service-orientated-architecture" on the web.
>
> ▪ To unsubscribe from this group, send an email to:
> [EMAIL PROTECTED]
>
> ▪ Your use of Yahoo! Groups is subject to the Yahoo! Terms of
> Service.
>
>
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/
