Hello Steve, I would give a context before define architectures. If the context is software application, then I would say the architectures are:
data architecture (ER diagrams) systems architecture (fire walls, load balancing, DMZ, tiers, servers,and storage etc) software architecture (platform independent, technology dependent) I normally do not use information architecture that is, in my view, to define content structure for webpages. I agree that infrastucture is the implemenation of systems architecture. We must first build business models (process charts, business rules, data flows) (I would not say business architecture) that drive requirements from which the three architectures are defined. Architectures are conceptual models that describe what to be created. Design creates them the first time as logical models, implementation creates them the second time as physical models. Enterprise architecture is more involved and there are lots of frameworks. FEAF uses five reference models (architectural patterns) to guide the construction of architectures. Architectues are logically related hence we must consider their interdependencies before creating them. Have a good weekend. Jerry Z. --- Steve Ross-Talbot <[EMAIL PROTECTED]> wrote: > 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 > === 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/
