Re: My Enterprise Architecture - your thoughts?
From: Tim Smith (timasmith_at_hotmail.com)
Date: 06/23/04
- Previous message: Phlip: "Re: My Enterprise Architecture - your thoughts?"
- In reply to: Mark Nicholls: "Re: My Enterprise Architecture - your thoughts?"
- Next in thread: Mark Nicholls: "Re: My Enterprise Architecture - your thoughts?"
- Reply: Mark Nicholls: "Re: My Enterprise Architecture - your thoughts?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 22 Jun 2004 18:08:05 -0700
Nicholls.Mark@mtvne.com (Mark Nicholls) wrote in message news:<bdf4e330.0406180103.6703ee0d@posting.google.com>...
> Is this an "Enterprise Architecture"? I don't think it is, I would
> refer to things like Zachman for a framework for developing an
> "Enterprise Architecture".
thanks for the tip
>
> I'll read it as a system architecture (note I think Fowlers "Patterns
> of Enterprise application architecture" is a bit of a misnomer as
> well, even if it's a very good book along the lines that you are
> talking).
>
> > Logical View has 4 layers
> >
> > - Presentation : GUI, views and reports, external system input
> > - Application : App specific workflow which coordinates business
> > logic.
> > Also interface data is mapped and processed here.
> > - Middleware : Business logic is broken into functional services
> > Services All database access must be through a service.
> > - Data : Persistent data access through database stored
> > procedures
> >
> > Process View
> >
> > - Each service is a thread, groups of services are a process.
> > - Services/Applications communicate by passing objects that represent
> > the domain.
>
> I assume tbis is, objects that are members of the domain model? or
> represent entities in the domain.
>
Domain model was a new term for me on this project, how it differs
from an domain entity I am a little fuzzy on. Suffice to say it is an
object which reflects the real world attributes and relationships
between objects. This is quite dramatically different to the legacy
database schema which the service maps the domain object to through an
adapter.
> >
> > Implementation/Deployment View
> >
> > - The services may run on a node ddfferent to the data and
> > application.
> > - Service definitions and objects passed between the
> > application/middleware are deployed on both tiers
> >
> > Detailed Design
> >
> > An interface example:
> >
> > 1) custom data in
> > external ------> interface (interface app transforms data
> > system application into a PersonObject)
> >
> > 2) PersonObject
> > interface ------> middleware (PersonObject sent to middleware
> > application service for processing. Middleware
> > transforms
> > into a DatabasePersonObject)
> >
> > 3) DatabasePersonObject
> > middleware ------> database (DatabasePersonObject written to
> > service layer database.)
> >
> > As you can see there is a fair amount of mapping/transforming.
> > Certainly I can look for some patterns on that. The reason for a
> > separate PersonObject to DatabasePersonObject is to reduce the impact
> > of data model changes on the application (only the adapter in the
> > interface layer need change).
> >
> > There is a fair amount of data being transferred and I worry that
> > there will be scalability issues as many users access the system,
> > although it is designed so that you can replicate the service tier on
> > many nodes.
>
> You may have absolute performance problems with just 1 user.
Hmm, well I have done a prototype of course running on a low grade PC
and I saw around 150ms for a general search function which returns
10-100 rows back to the screen. So while not as fast as a direct
database connection/display I would not say it has performance
problems yet.
>
> Your scalability problems will generally be contention in the
> database, or bandwidth on your network.
I am banking on being able to ramp up the database, and as many
servers of services as needed. Network, I have some concerns but I am
not sure if it will be a bottleneck, perhaps not if I can get 1GB
ethernet connections to the servers.
>
> There doesn't seem to be anything glaringly out of the ordinary, I
> would worry about....
>
> i) complexity...you may not need all this.
We are looking to this for the base of an information system with a
large amount of functionality (2 years to build with 30 developers or
so).
> ii) absolute performance - the more layers you put in and
> transformations, and passing data by value, you do the slower the
> response for a single user.
I agree, I do wonder if it will work. My old company did it with a
home grown middleware but it was written in a lower level language
than I will use.
> iii) scalability - there is nothing here that makes me especially
> worried, how many concurrent users are you like to have, accessing how
> many rows on average on what sort of DB - your logic layer will
> probably not be the bottleneck.
20 power users, 50-200 lighter users, interfaces processing a
transaction a second between them, some reports etc. Trying to reduce
the number of rows accessed.
>
> I would refer to
> Fowlers "Patterns of Enterprise application architecture".
> and "Enterprise integration patterns" for you "custom data in"
I have been working through that book, though it is a little light in
some areas (data layer).
>
> If its being done from scratch I would start small, concentrating on a
> single simple top to bottom functional aspect of the system, develop
> the architecture and then mitigate your worries by running some
> performance/scalability tests.
Yep, I have a test interface which will be the prototype.
- Previous message: Phlip: "Re: My Enterprise Architecture - your thoughts?"
- In reply to: Mark Nicholls: "Re: My Enterprise Architecture - your thoughts?"
- Next in thread: Mark Nicholls: "Re: My Enterprise Architecture - your thoughts?"
- Reply: Mark Nicholls: "Re: My Enterprise Architecture - your thoughts?"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|