Hi...
I'm a very Jr. software architect startup in a CMMI company..

i have observed deciding the software architecture for a project .. of
a medium to large scale.. whether .NET, J2ee... after that a cocktail
of techs like EJB,hibernate,spring etc
since one day the onus is on me to decide this.. and so far all i have
seen happening is.... The current industry best (most generic) cocktail
is applied to most projects..
I believe this is hardly optimal..

I would like to know..  how is it that the framework of a project, the
initial foundations are laid?
any books or E-text that i must read prior?..i am under formal
training,.. but that isnt enough i feel..
Help please!

Responding to Plasmafire...

> i have observed deciding the software architecture for a project .. of
> a medium to large scale.. whether .NET, J2ee... after that a cocktail
> of techs like EJB,hibernate,spring etc
> since one day the onus is on me to decide this.. and so far all i have
> seen happening is.... The current industry best (most generic) cocktail
> is applied to most projects..
> I believe this is hardly optimal..

First, let me point put that your "cocktail" of technologies and whatnot 
is really orthogonal to the CMMI.  They reflect /implementation/ 
decisions in the local organization's development context.  All the CMMI 
provides is a model for integrating them into a repeatable development 
process.

> 
> I would like to know..  how is it that the framework of a project, the
> initial foundations are laid?
> any books or E-text that i must read prior?..i am under formal
> training,.. but that isnt enough i feel..

That is really a job for a Systems Engineering.  In addition there are 
typically business trade-offs.  For example, retraining costs for 
changing technologies, etc. are often substantial so such decisions are 
often made to be optimal across the general mix of software the shop 
creates rather than individual projects.  That can lead to situations 
where the "cocktail" is not the best solution for a particular project.

Basically one needs to be quite familiar with the various technologies, 
enough to be able to evaluate them for a particular architectural 
problem.  The evaluation then determines which are best suited for the 
project or general sort of software being produced.  Alas, that 
evaluation is a pure intellectual exercise so there aren't any hard 
rules for doing it.  It depends upon the System Engineer's knowledge of 
the technologies and the kind of software being developed.  That's why 
Systems Engineers get the Big Bucks.  B-)


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

Hmmmm thatz an insight.. a couple of million $$ hang on by the thread
of (usually) a single guy's experience. What if the s/m engineer makes
a mistake in judgement..
A couple of things i understand by what u just said.. like why i was
chosen for this job.. guess it was because of my experience with
mainframes, J2EE as well as .NET

Ok.. since we delegated the framework building to a system engineer..
what do the various architects do?

(Offtopic: by the way what's Drano?)

Responding to Plasmafire...

> Hmmmm thatz an insight.. a couple of million $$ hang on by the thread
> of (usually) a single guy's experience. What if the s/m engineer makes
> a mistake in judgement..

Right.  Big Responsibility is why they get the Big Bucks.  B-)  Choose 
the wrong skeleton and nothing hangs on it right later.  So it often 
takes awhile to recognize the skeleton was wrong.  The result is the 
project gets canceled a few years and megabucks later and the Systems 
Engineer goes back to being a Software Engineer.

> A couple of things i understand by what u just said.. like why i was
> chosen for this job.. guess it was because of my experience with
> mainframes, J2EE as well as .NET

Maybe, but I suspect at a different level.  Weren't those things already 
selected for the shop?  If so, your job would be more about getting them 
to play together properly in the context of a particular application. 
IOW, your job would be to turn the theoretical advantages recognized by 
the Systems Engineer (or whoever made the "cocktail" selection 
decisions) into practical advantages.

[Alas, in many shops there isn't a true Systems Engineer and such 
decisions get made in a much more ad hoc manner.]

> Ok.. since we delegated the framework building to a system engineer..
> what do the various architects do?

I think it's mainly a matter of scale.

Systems Engineer: megathinker.  Deals with overall strategies, system 
partitioning, allocation of requirements to subsystems, communication 
strategies for subsystems, and defines hardware, tools, and platforms 
(e.g., J2EE).  Often views things from the PLA (Product Line 
Architecture) marketing perspective.  Focus is one defining what the 
critical system elements are, critical communications, and overall 
development environment.

Architect: kilothinker.  Defines specific strategies (e.g., read 
caching), protocols, infrastructures (e.g., J2EE optimizations), and 
whatnot at the application or subsystem level, given the megathinker 
concept of the project.  Focus is on getting everything to play together 
properly.

Designer: centithinker.  Provides classical high level design at the 
application or subsystem level, given the mega- and kilothinker vision 
of the project.  Focus is on actually solving the customer's problem.

Developer: thinker.  Implements everything by providing low level design 
and programming.  Focus is on getting the solution to actually work.

> (Offtopic: by the way what's Drano?)

It is a popular brand name in the US for a drain declogger and cleaner.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

If our systems engineers developed software then all our missions would
be failures. I know of only one that has the depth of knowledge to
design and develop real-time, mission-critical software. Where I work
systems engineers have a broad base of knowledge, but they do not have
detailed knowledge to perform any separate discipline well.

BTW, our systems engineers have the same pay scale as software
engineers. I guess I must be making the big bucks too!

On Tue, 2006-02-14 at 16:53 +0000, H. S. Lahman wrote:
> Responding to Plasmafire...
> 
> > Hmmmm thatz an insight.. a couple of million $$ hang on by the thread
> > of (usually) a single guy's experience. What if the s/m engineer makes
> > a mistake in judgement..
> 
> Right.  Big Responsibility is why they get the Big Bucks.  B-)  Choose 
> the wrong skeleton and nothing hangs on it right later.  So it often 
> takes awhile to recognize the skeleton was wrong.  The result is the 
> project gets canceled a few years and megabucks later and the Systems 
> Engineer goes back to being a Software Engineer.
> 
> > A couple of things i understand by what u just said.. like why i was
> > chosen for this job.. guess it was because of my experience with
> > mainframes, J2EE as well as .NET
> 
> Maybe, but I suspect at a different level.  Weren't those things already 
> selected for the shop?  If so, your job would be more about getting them 
> to play together properly in the context of a particular application. 
> IOW, your job would be to turn the theoretical advantages recognized by 
> the Systems Engineer (or whoever made the "cocktail" selection 
> decisions) into practical advantages.
> 
> [Alas, in many shops there isn't a true Systems Engineer and such 
> decisions get made in a much more ad hoc manner.]
> 
> > Ok.. since we delegated the framework building to a system engineer..
> > what do the various architects do?
> 
> I think it's mainly a matter of scale.
> 
> Systems Engineer: megathinker.  Deals with overall strategies, system 
> partitioning, allocation of requirements to subsystems, communication 
> strategies for subsystems, and defines hardware, tools, and platforms 
> (e.g., J2EE).  Often views things from the PLA (Product Line 
> Architecture) marketing perspective.  Focus is one defining what the 
> critical system elements are, critical communications, and overall 
> development environment.
> 
> Architect: kilothinker.  Defines specific strategies (e.g., read 
> caching), protocols, infrastructures (e.g., J2EE optimizations), and 
> whatnot at the application or subsystem level, given the megathinker 
> concept of the project.  Focus is on getting everything to play together 
> properly.
> 
> Designer: centithinker.  Provides classical high level design at the 
> application or subsystem level, given the mega- and kilothinker vision 
> of the project.  Focus is on actually solving the customer's problem.
> 
> Developer: thinker.  Implements everything by providing low level design 
> and programming.  Focus is on getting the solution to actually work.
> 
> > (Offtopic: by the way what's Drano?)
> 
> It is a popular brand name in the US for a drain declogger and cleaner.
> 
> 
> *************
> There is nothing wrong with me that could
> not be cured by a capful of Drano.
> 
> H. S. Lahman
> hsl@pathfindermda.com
> Pathfinder Solutions  -- Put MDA to Work
> http://www.pathfindermda.com
> blog: http://pathfinderpeople.blogs.com/hslahman
> (888)OOA-PATH
> 
> 
> 

Plasmafire wrote:

> Hmmmm thatz an insight.. a couple of million $$ hang on by the thread
> of (usually) a single guy's experience. What if the s/m engineer makes
> a mistake in judgement..

Doc, it hurts when I go like that.

Don't ever rely on any one guy. Always distribute architectural
responsibility. Anyone can upgrade the architecture, if they can get it
reviewed by everyone else.

If you think you must rely on one guy, ask Why several times.

> (Offtopic: by the way what's Draino?)

A harsh solvent (hypochlorous acid) dissolved from a heavy salt (sodium
hypochlorite). It unclogs drains, and is also effective as a very painful
form of suicide.

BTW I seriously dislike Lahman's tag-line.

-- 
  Phlip
  http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

Responding to Kandt...

> If our systems engineers developed software then all our missions would
> be failures. I know of only one that has the depth of knowledge to
> design and develop real-time, mission-critical software. Where I work
> systems engineers have a broad base of knowledge, but they do not have
> detailed knowledge to perform any separate discipline well.

Interesting.  Usually Systems Engineers come up through the ranks.  Once 
they have achieved breadth of /practical/ experience, they get anointed. 
  IOW, one view of a Systems Engineer is a developer who has matured 
with broad experience.

> BTW, our systems engineers have the same pay scale as software
> engineers. I guess I must be making the big bucks too!

IMO, that is not a good idea.  In effect it means that a developer is 
not rewarded for having unique breadth of experience and knowledge.


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH

Thanks a lot for the insights. that does clarify a lot of things...
but I still cant digest that there is no yardstick for deciding what
skeleton to use.
no way to decide how various techs go together.. except to mix n match.
then learn thru a positive (and negative) set of experiences.

@philip.. I am paid the equivalent of a 100$ more than my peers who are
regular developers.. not exactly big bucks.. but the margin difference
does get big later on. abt 300%-500% big in 3-4 yrs :)

I am learning the various platforms as of now.. how to implement etc.
trying to get a macro level view.. without going into code. MS or SUN
is the qn that drops in 1st.. any answers to that.. when to go in for
which?
By the way.. i hate the level of approximate decisions and gut feelings
that go into the initial stage of development. poor devs.. they get to
bear the brunt of it.

(Offtopic: Lahman I resent too. Cyanide is ok but Drano..nope)

Responding to Plasmafire...

> Thanks a lot for the insights. that does clarify a lot of things...
> but I still cant digest that there is no yardstick for deciding what
> skeleton to use.
> no way to decide how various techs go together.. except to mix n match.
> then learn thru a positive (and negative) set of experiences.

I think it is really a matter of having extensive practical experience 
so one knows what to look for.  For example, an Architect when 
evaluating commercial OO class libraries will know that most of the 
nasty integration problems will lie in whether and, if so, how each 
library overloads the 'new' operator.  That becomes automatic once one 
has been burned a few times.

As an example from another arena, I spent a couple of decades solving 
operations research problems.  OR has several "stock" optimization 
techniques (linear programing, dynamic programming, Monte Carlo 
analysis, regression, etc.).  As a practical matter there are commercial 
packages to do the grunt work.  The trick is to know which one to use in 
a given situation.  To make that decision one needs to know, for 
instance, that dynamic programming is the fastest but it requires huge 
amounts of memory, which may lead to page faulting.

My point is that the most crucial OR decision is selecting the right 
technique and one can do that without a great deal of theoretical 
knowledge of the actual algorithms.  One really only needs to understand 
some practical, large scale /implications/ of the algorithms.  If one is 
lucky, one can get that from a good instructor in school but it wasn't 
in any OR books I ever read.  Without that good instructor, one has to 
learn the hard way.

I think that is pretty much the way Systems Engineers are made because 
basically they are just selecting from among "canned" alternatives. 
There may be a guru around who can provide such characterization for 
..NET vs. J2EE or whatever, but I don't happen to know of any.

[I happen know a fair amount about application/system partitioning and 
that does have some "cookbook" guidelines that are described in the 
Application Partitioning category of my blog.  Alas, you are concerned 
with much more detailed architectural issues that I haven't dealt with 
for decades.  (I am a translationist so I never see 3GL code, much less 
infrastructures like .NET.)]


*************
There is nothing wrong with me that could
not be cured by a capful of Drano.

H. S. Lahman
hsl@pathfindermda.com
Pathfinder Solutions  -- Put MDA to Work
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
(888)OOA-PATH