What it takes to be an architect?

Who am I

An aspiring enterprise architect

Purpose of this thread

1. To present, based on MY limited experience, what architects did on the projects (J2EE) I worked on �apart from architecting/designing a solution - and to take input from the members of this forum about their own experience.

2. Obtain information on relevant resources informative and/or interactive URLs e.g. java.sun.com /discussion groups etc, presentations those are very useful for an architect in terms of new technologies, approaches, strategies etc.

3. To obtain suggestions from the knowledgeable people of this forum as to how one can systematically transition/mature from say a programmer/developer to an architect and the type of activities that one should constantly perform to stay as a good architect


Architect�s responsibilities � based purely on MY experience:

As mentioned above, I am not including the obvious responsibility of architecting and designing a solution to a given problem (anything implied by SCEA certification).

No specific order is used in enumerating the items.

Frameworks: Deciding an appropriate off-the-shelf framework/or constructing one that would suit the project in regard to web application (say struts/spring), logging (log 4j/jdk logger), unit testing (Junit), persistence (hibernate/spring), Xml processing (dom4j/JAXB) etc.

Design review: Reviewing the detailed/low-level design; coming up with best practices and in some cases design review check-list.

Code review: Setting up check list for code review and leading/monitoring the code review activity. This may also include using appropriate tools in conjunction with an IDE (say eclipse) and configuring it for taking care of many of the coding rules. In such cases, developers are expected to present the code along with the reports generated using such code review tools at the time of formal code review.

Organizing the code: Coming up with the right package structure and also organizing the various artifacts in the best possible way. Building the exception framework, utility framework etc.

Coding: In many cases, architects are the ones to write the first end to end code �all the way from presentation to persistence layer.

Software & deployment configuration: Deciding on software versions that would be used to build the application along with the OS & machine specifications for each of the environment such as development, integration, user acceptance, preproduction production etc. Configuring the application server.

Configuration management: This includes deciding a source control tool, setting it up, creating branches for developer groups, responsible for merges and releases.

Deployment: Be responsible for deployment or interact with a deployment manager to make sure everything is right before deployment is initiated. Architects may also write the ant scripts and may use some special tasks available from various vendors.
This task also includes base lining a process flow with respect to deployment.

Interface to business: Act as an interface to business people/active bridge between the business and technologists. They also have an in-depth understanding of the business domain.

Project estimation: Provide project estimations to project managers and also appraise of them of any technology related project risks.

Documentation: This is one of the primary responsibilities of architects. They document and also organize the documents and are responsible for updating them.

Change tracking: Track the changes to requirements and make sure the deployed code conforms to that.

Testing: Responsible for doing preliminary testing as well as coordinating performance testing. In certain cases like communicating with multiple external systems (say portals), suggesting appropriate methods to test such special scenarios.

Database: Participate in database design and proactively suggest necessary additions/updates. Closely interact with database designer and DBAs.

Migrations: Be responsible for migration of code to a newer version of application server/OS/JDK/database etc.

Trouble shooting: If any of the developer is stuck up because of say software issue or technical clarity or anything of such a kind, architect is expected to resolve it so the work can progress.

Plug-ins: Finally, architects also act as plug-ins to fill in the role of anybody in the project if the need arises-this is too vast a topic to discuss!

Creativity: Invariably the architects I came with were very creative. While this is not a responsibility it was a �very nice to have� aspect!

Also, being aware of the competing technologies (java vs .Net) and cost effectiveness of each with respect to the infrastructure, development time etc.
[ May 11, 2006: Message edited by: Ram Chandramouli ]

GREAT VIEWS!

good post and very accurate imho

Accurate inputs Chandramauli!

Just curious..do you work for big blue in India or used to ?

Thankyou don, wise and suekar for your comments.
Apparently my experience is not off the mark!

Suekar,
I didn't work for big blue in India

Hello Ram,
be honest, it's a parody on the poor reality, isn't it?

Many roles are mentioned like
- (Technical/Organizing) Project Manager - PM
- Team Leader
- Quality Manager - QM
- Change Manager
- Document Manager
- Requirement Interviewer
- Business Analyst - BA
- Data Modeller
- Software Architect
- Detailed Designer
- Developer and/or Programmer
- Deployer
- Test Engineer
- Bug/Problem/Issue Tracker/Manager
- ...

An architect may and often must take multiple roles, but on the other side often a developer also takes the role of an architect plus data modeller plus deployer plus tester plus bug tracker plus ... .

Better do not try to define the role of an architect by the duties that a person being the architect often fullfills in the field!

Instead of citing with 19 indented quotes I will just use
S: for your Sentences and
A: for my Answers

Note: For some duties you may add: "If nobody else can do it and the architect has the time: yes."


S: [What you forgot]:

A: J2EE [and common] Design Patterns!

A: Interfaces between components and/or classes ("the glue of OO")!

A: UML Usecase diagrams, if not done by BAs, for overview

A: System overview diagrams

A: Organizing the raw design by Tiers

A: UML Class diagrams

A: UML Composite Structure diagrams

A: UML Sequence/Communication/Collaboration diagrams

A: UML Component diagrams

A: UML Deployment diagrams

A: Special UML diagrams like Statechart diagrams, if needed

A: EJBs ("the heart of J2EE")!


S: Frameworks: Deciding an appropriate off-the-shelf framework/or constructing one that would suit the project in regard to web application (say struts/spring), logging (log 4j/jdk logger), unit testing (Junit), persistence (hibernate/spring), Xml processing (dom4j/JAXB) etc.

A: partly yes, but because not the architect but the developers are the specialists of divers frameworks, he must have a) mostly the criteria for decisions, b) a basic understanding of typical features, differences and for instance architectural implications of the frameworks, c) must be able to listen to developers too and d) should have some experience in each field like UI (Swing, HTML, ...), business programming (simple java), persistence, messaging, legacy connectivity, ... , not the special frameworks in detail nor in programming.


S: Design review: Reviewing the detailed/low-level design; coming up with best practices and in some cases design review check-list.

A: Duty of the team leader of the developers, advised by the architect.


S: Code review: Setting up check list for code review and leading/monitoring the code review activity. This may also include using appropriate tools in conjunction with an IDE (say eclipse) and configuring it for taking care of many of the coding rules. In such cases, developers are expected to present the code along with the reports generated using such code review tools at the time of formal code review.

A: Duty of the team leader of the developers, or QS, or PM, ... .


S: Organizing the code: Coming up with the right package structure and also organizing the various artifacts in the best possible way. Building the exception framework, utility framework etc.

A: Yes for package structure, because in detailed design it would be too late.


S: Coding: In many cases, architects are the ones to write the first end to end code �all the way from presentation to persistence layer.

A: Duty of the developer team led by the architect.


S: Software & deployment configuration: Deciding on software versions that would be used to build the application along with the OS & machine specifications for each of the environment such as development, integration, user acceptance, preproduction production etc. Configuring the application server.

A: No, not at all, though some customers expect that for curious reasons.


S: Configuration management: This includes deciding a source control tool, setting it up, creating branches for developer groups, responsible for merges and releases.

A: No, not at all. What do we have a Project Manager for?


S: Deployment: Be responsible for deployment or interact with a deployment manager to make sure everything is right before deployment is initiated. Architects may also write the ant scripts and may use some special tasks available from various vendors.
This task also includes base lining a process flow with respect to deployment.

A: No, not at all. If nobody else can do it and one of the developers has the time, the PM can ask him, because developers need deployment for their testing anyway.


S: Interface to business: Act as an interface to business people/active bridge between the business and technologists. They also have an in-depth understanding of the business domain.

A: partly, but do not forget the Business Analysts. In some projects they are the only interface that is "allowed to speak with clients", strictly speaking. The Architect should be a very good listener, but the BAs in between are important as "friends of the users, not of the developers", and architects by their history most often have been developers and in their heart still are.


S: Project estimation: Provide project estimations to project managers and also appraise of them of any technology related project risks.

A: No, not at all. What do we have a Project Manager for? Time estimations must be actively asked. How could the architect concentrate on his work anymore?


S: Documentation: This is one of the primary responsibilities of architects. They document and also organize the documents and are responsible for updating them.

A: Yes, and advising the document manager for document change management. If nobody else can do the latter and the architect has the time: yes.


S: Change tracking: Track the changes to requirements and make sure the deployed code conforms to that.

A: No, not at all. In big projects this is a full time job. Or in conjunction with the Test Engineer team. Or PM. Or ...


S: Testing: Responsible for doing preliminary testing as well as coordinating performance testing. In certain cases like communicating with multiple external systems (say portals), suggesting appropriate methods to test such special scenarios.

A: No. Coordinating performance testing: no. Advising performance testing: yes.


S: Database: Participate in database design and proactively suggest necessary additions/updates. Closely interact with database designer and DBAs.

A: Fortunately no. If you know the data modelling expertise (or ignorance) of architects, you better say no.


S: Migrations: Be responsible for migration of code to a newer version of application server/OS/JDK/database etc.

A: Beg your pardon: what is architecture specific in this task? No.


S: Trouble shooting: If any of the developer is stuck up because of say software issue or technical clarity or anything of such a kind, architect is expected to resolve it so the work can progress.

A: Only for parody ...


S: Plug-ins: Finally, architects also act as plug-ins to fill in the role of anybody in the project if the need arises-this is too vast a topic to discuss!

A: Only for parody ...


S: Creativity: Invariably the architects I came with were very creative. While this is not a responsibility it was a �very nice to have� aspect!

A: yes.


S: Also, being aware of the competing technologies (java vs .Net) and cost effectiveness of each with respect to the infrastructure, development time etc.

A: To some degree, yes. It also depends on if you offer as a Software Architect, a Java Architect, an Enterprise Architect, a J2EE architect etc. The more specialized the architect's role, the more no.

Thomas
[ May 12, 2006: Message edited by: Thomas Taeger ]

Hi Thomas,

Thanks for your meticulous feedback on each of the individual items. It�s good to see other perspectives flowing in. I do not want to go through each of the individual item in an attempt to "defend" myself but would just say a couple of points here:

1.There is no distortion of facts in what I presented-it�s just a matter of my own experience and in case it differs from that of yours, I look at yours and you may look at mine � whichever is encouraging!

2.I am not making an attempt to define the duties of an architect, as your responses seem to reflect - but just what architects did in the projects I worked on.

Finally, I must thank you for the many "No's" that you came up with primarily because I being an aspiring architect have less to tackle to reach my goal - if I follow your trail!
[ May 12, 2006: Message edited by: Ram Chandramouli ]

Originally posted by Thomas Taeger:
: EJBs ("the heart of J2EE")!

Whoaa! Hold on � stop buying into Sun's propaganda! A significant share of J2EE installations don�t even use EJBs that much � the occasional stateless session bean maybe. Read this:
Expert One-on-One J2EE Design and Development: Chapter 1 J2EE Architectures.

Basically the description the original poster gave is way too hands-on for the archetypical enterprise or software architect (see the description of the WWISA linked to in the above post)). Some EAs are loathed by the development teams because the architect simply issues enterprise technology directives and blueprints based on marketing pamphlets, White Papers, and reference architectures without ever bothering to ferret out the real implications of committing to a particular technology.
Don't Let Architecture Astronauts Scare You

Because of the scope of enterprise architecture it's easy to lose sight of the issues on that appear on the more detailed level (well the other technical people that deal with this are supposed to tell the architect about them � but they are usually too busy with real, immediate problems that concern the business right know rather than exploring potential technology candidates to the full extent necessary (i.e. beyond the point where they are done "playing" with the new toy)). Also many businesses are not big enough to warrant (the expense of) a fulltime architect � so whoever is doing the architecting tends to "flavor" all decisions with their particular specialty.

The best approach is to become Generalizing Specialist so that you can make effective architectural decisions without too much bias.

One should probably aim to become an "engineer (or craftsperson) in the trenches" (one of the Object Mentor mottos) � that way you can limit the damage an Architecture Astronaut can do to the organization that is paying your paycheck (though you will probably get paid less than the architect). If you are lucky, somebody may notice that you are behind all the good decisions and ultimately give you the job � just don't forget where your roots are.
[ May 12, 2006: Message edited by: Peer Reynders ]

Originally posted by Thomas Taeger:
S: Project estimation: Provide project estimations to project managers and also appraise of them of any technology related project risks.
A: No, not at all. What do we have a Project Manager for? Time estimations must be actively asked. How could the architect concentrate on his work anymore?

Estimates should come from the team(s) not the architect, or the Project Manager. The Architect gets to play visionary, the Project Manager (checks and) controls the project. The estimates need to come from the team(s) � if they do not, your project is in trouble even before it starts.

Originally posted by Thomas Taeger:
S: Configuration management: This includes deciding a source control tool, setting it up, creating branches for developer groups, responsible for merges and releases.
A: No, not at all. What do we have a Project Manager for?

Doesn't anybody believe in asking the people who have to use these tools? Or are all your developers of the McDonald's burger-flipping kind?
Source Control is everybody's business. Usually lead developers are roped in for configuration management.

Hello Ram,

Originally posted by Ram Chandramouli:
2.I am not making an attempt to define the duties of an architect, as your responses seem to reflect - but just what architects did in the projects I worked on.

It is true, during the last weeks all day long I received requests for any mix of architect and what else jobs, and much too often I had to defend or convince that an architect is an architect and a craftsman is a craftsman, and so on.

Your observation of the sad reality is accurately reported.

Don't get me wrong please: I am very glad you came up with this topic. Discussion [besides convincing customers] is the only chance to publicly stabilize the job description of an architect.

Thomas

S: Coding: In many cases, architects are the ones to write the first end to end code �all the way from presentation to persistence layer.
A: Duty of the developer team led by the architect.

If you see an "architect" writing code, your are dealing with a developer with architectural responsibilities. End-to-end code like "Tracer Bullets" (Pragmatic Programmer) is usually written by "Scouts" (Dynamics of Software Development) selected from the developer team.
The fact is many organizations cannot afford to have a dedicated architect, so you'll often find senior lead developers who are deeply familiar with the business making architectural decisions.

Originally posted by Peer Reynders:
The estimates need to come from the team(s) � if they do not, your project is in trouble even before it starts.

Then nearly 100% of projects were in trouble, if not the project manager goes around and actively asks a) each single developer and b) maybe additional the team(s) as groups
1. what duration he (they) estimate(s) for their work packages and
2. later what the state of these work packages is.
[ May 12, 2006: Message edited by: Thomas Taeger ]

Originally posted by Thomas Taeger:

Then nearly 100% of projects were in trouble, if not the project manager goes around and actively asks a) each single developer and b) maybe additional the team(s) as groups what the state of their work packages is.

I think we are saying the same thing here. The Project Manager has to assemble estimates - but the developers actually produce the estimates for the work they will be assigned.

PS: Added "Client:AppServer:Resource", refined for EJB, and replaced "Client/Server" to "Three Tier" - I woke up this morning and knew what I did wrong and that surely somebody will allready have cited. I am really sorry for the confusion!

Originally posted by Peer Reynders:
... stop buying into Sun's propaganda! A significant share of J2EE installations don�t even use EJBs that much � the occasional stateless session bean maybe.

I hope I am one of the few human beings not just buying anybody's propaganda, say the ultimative Web Services etc.

But when I came across EJBs I understood one special architectural thing:
Whilest the relationships Client:AppServer:Resource
- for Client/Server architecture was N:1:1,
- for Three Tier architecture was N:1:N,
- J2EE introduced N:N:N using EJB container services, i.e. gave clustering an architectural concept
. - maybe others did before, I don't know - which other architectures or frameworks do that?

Because I actually tend to design for local access to entity beans the switch to EJB-3 will be moderate in the Data Access Tier.

Originally posted by Peer Reynders:
If you are lucky, somebody may notice that you are behind all the good decisions and ultimately give you the job � just don't forget where your roots are.

That is too modest for my situation. As a freelancer I must be up and running.

Thomas
[ May 16, 2006: Message edited by: Thomas Taeger ]

Hi Thomas,

It is true, during the last weeks all day long I received requests for any mix of architect and what else jobs, and much too often I had to defend or convince that an architect is an architect and a craftsman is a craftsman, and so on.

I understand what you say now and in any case it's definitely fine to express one's opinions. Thanks for elaborating though.

What I now realize is the complexity in perspective that's generated at different levels of granularity. When I said estimation, I actually meant at a gross level. Who does generally estimate a project when there is a only a proposal? IMHO, a person with the necessary knowledge. It can be an architect, a senior developer etc. In fact, different scenarios (size of project, organizational culture, individual personalities etc) may lead to different outcomes. The discussion here seems to revolve around the finer points.

My point here is that whether or not architects do a certain thing, do they need to be aware of these aspects to be an accomplished architect or not.

Originally posted by Thomas Taeger:
ultimative Web Services

Don't get me going on that one, I've had my share of rants on that one (one example.)

Originally posted by Thomas Taeger:
But when I came across EJBs I understood one special architectural thing: Whilest the Client/Server architecture was N:1:N, J2EE introduced N:N:N. i.e. by giving clustering an architectural concept

I'm not sure exactly what you are getting at. Client-Server is usually identified as 2-tier while more advanced architectures can be n-tier. Also I'm pretty sure that clustering is not mandated by either the EJB or Servlet specification; i.e. clustering is a value added option by application server vendor, not an inherent feature of J2EE. So clustering is implemented in a vendor proprietary manner, sometimes as a pure software solution, sometimes assisted by some serious hardware. IT architecture has always "recognized" clustering as "the" horizontal scaling and/or failover option � without being tied to any particular brand of technology, framework, or architectural design.

Originally posted by Thomas Taeger:
Because I actually tend to design for local access to entity beans the switch to EJB-3 will be moderate in the Data Access Layer.

Make no mistake: EJB 3 has its place, but it's no panacea. The option of using POJOs may bring some relief but EJB 3 is still a heavy-weight solution. And while it might seem like there is a love-affair between Hibernate and EJB 3, that doesn't imply that they are one and the same. That has more to do with the fact that Hibernate moved into the JBoss initiative and JBoss needed EJB 3. Ultimately that move resulted in some tension between the Spring and Hibernate development teams Hibernate hates Spring).
To gain some perspective on EJB you should try to get a look at Rod Johnson's (founder of Interface21 who develops Spring) Expert One-on-One J2EE Design and Development and Expert One-on-One J2EE Development without EJB. (See also Local Client Vs. Remote Client and Hi Ranchers, EJB 2.0 or EJB 3.0 ).

Originally posted by Thomas Taeger:
That is too modest for my situation. As a freelancer I must be up and running.

The statement still stands. Nobody is going to give you an "architecting gig" just because you are brandishing those SCEA letters. You get that gig because of past experience. So either you are an acting architect with an employer where you have to work yourself up to that position from the lower ranks or you are working for a large consulting firm that ran out of experienced architects and forced you onto one of their customers. If you start to freelance too early (as a developer) you are going to have to rely on a repeat customer that finally trusts you enough to give you that "architecting gig" � or you are going to have to volunteer for some not-for-profit venture (that nobody else with experience is volunteering for) and wring it for all the publicity you can.

As a freelancer you cannot afford to have tunnel-vision of any kind even the EJB kind. Furthermore if you are a one man show you will have to deal with the occasional smaller contract to put bread on the table. And it's just not fair to your customer to saddle them with an EJB boat-anchor when they really don�t need it � you need to be aware of the Spring-(Hibernate/iBatis) solution that can be deployed on a single server and later scaled horizontally (as an application) by deploying the whole thing in an application server that can be clustered. Never forget Fowler's (PEAA p.89)

First Law of Distributed Object Design: Don't distribute your objects!

Once you have justified without a doubt that you need to distribute, you should always pursue the most course-grained option (i.e. usually an entire application service).
Potential reduced time-to-market it the other reason why you need to be aware of the non-EJB options � you will need that edge.

Hi Ram,

Originally posted by Ram Chandramouli:
When I said estimation, I actually meant at a gross level. Who does generally estimate a project when there is a only a proposal?

It's important to realize that you can only truly estimate once the requirements have been explored to some level (otherwise you could actually be dealing with a target). That exploration can be a small project in itself. Sadly that doesn't usually happen during the proposal phase. You can only offer a realistic estimate if you have already done it before � and in the software world if you have done it before, can't you re-use it, at least at some level? And even that turns it into a different project. The practice of fixed price contracts is pretty standard, unfortunately it doesn't usually work in the customer's favor, even if the customer thinks that it should. See Comparing Approaches to Budgeting and Estimating Software Development Projects. See a related discussion in Resources (links,books) for topic software estimation?.

The last sentence in my previous post needs a correction & elaboration:

The emphasis is not on who does each of the items I listed (based on my exp)-apparently I am way off with what few others have posted here and that's perfectly fine.

Should a successful architect be aware of all these aspects or not?
If you're an architect(J2EE) or plan to be one(JEE), what would you focus on with regard to hands-on implementation, in the capacity of a overseer and just as a participant?

The discussions are quite good, and I am learning many things that I didn't expect to in this thread; so thanks to the forum memebers!

Hello Peer,

Originally posted by Peer Reynders:
I'm not sure exactly what you are getting at.

I am sorry for the confusion: I used the name "Client/Server" but ment "Three Tier". I have re-edited this obvious failure in the original posting because otherwise the old posting would only confuse. Please see above.

Originally posted by Peer Reynders:
Also I'm pretty sure that clustering is not mandated by either the EJB or Servlet specification; i.e. clustering is a value added option by application server vendor, not an inherent feature of J2EE.

Even though clustering is an optional feature of J2EE, those vendors who realize it in a J2EE compliant way are [ideally] replacable by each other. That is what I mean with "gave clustering an architectural concept" - instead totally vendor specific or even hardware solutions. I think the presence of the huge J2EE market justifies my evaluation.

Originally posted by Peer Reynders:
So clustering is implemented in a vendor proprietary manner ...

I do not care the implementation but only the J2EE compliance that led to a industrial standard.

Originally posted by Peer Reynders:
IT architecture has always "recognized" clustering as "the" horizontal scaling and/or failover option � without being tied to any particular brand of technology, framework, or architectural design.

Which other standards for allowing clustering do exist today, allowing vendor products to be replaced by products of other vendors? That for me is the most interesting question.

I am not quite sure but I feel introducing the EJB container at that time was the right choice
- for de-facto asking/forcing all vendors to a standard
- whilst assuring the enterprise application server vendors that thay stay the "center of universe" (and of earning).
After all vendors have agreed to this first standard it is tomorrow/today easier to introduce a next standard using say dependency-injection instead of containers.

Thomas

Hello Ram,

Originally posted by Ram Chandramouli:
My point here is that whether or not architects do a certain thing, do they need to be aware of these aspects to be an accomplished architect or not.

Strictly speaking, or in an ideal world, I would say: no.
It is definitively the duty of the Project Manager to assemble a team (including sub-teams) to cover all roles - besides even other aspects like a good mix of ages, characters, genders, languages/cultures etc..

But some customers made bad experience with architects "sitting in an ivory tower", not careing about any business or realizability. Bad architects, we would say, but customers need a countermeasure and therefore try to put the architect in the same boot as the developers. I can understand them, but it is fatal.

The other reason surely is is budget, as discussed.

A third reason I will give an own thread, something like "Interest Groups and the role of an 'Architect'"

Thomas

Hello Peer,

though I totally agree that one can run in difficulties when too early going as a freelancer, the other extreme like "you must know every architecture" is not needed.

Originally posted by Peer Reynders:
As a freelancer you cannot afford to have tunnel-vision of any kind even the EJB kind.

I think you can offer your additional knowledge as an add-on value of your special person. You are not only a J2EE architect, even not only an architect but also a technology consultant (surely besides even more qualifications). I probabely will not convince you. I have my interests (making an interesting job, "bread on the table", allways by giving the best quality I can - not the bread but the quality is why I discuss in this forum, filling some gaps in the wide fields of J2EE, architecturing etc.) as you have yours.

I offer only my experience as a J2EE architect, with the additional background of a decade of Java development (and other like Pascal, Data Modelling, Oracle, ... since 1984) but no longer offering development as my role.

Thomas

Hi All,

Thanks to all of you and javarach for providing such a informative discussion.

I have doubts which are very basic level.
Making a Hello World or small application do not require an architect but normally an Telecom OSS system do requrie. Many time applicaiton grows from a small to big one, Those application normally have an exprienced developers of same project, these developer start playing role of architect.

So my doubt is

Where architecture is required? What requires an architecture?

or

How an organisation decide that this application needs an architect or not?

Regards

Hello John,

Originally posted by John Waugh:
How an organisation decide that this application needs an architect or not?

It surely is a matter of complexity of the system to be constructed, as you showed in your example - though the question "Where architecture is required?" can be misleading: Each system has an architecture, even if a wild-grown and bad one. The architect has to plan the system (if that is complex enough) for avoiding rank-groath.

Additionally the complexity and variaty of required infrastructure (central services, external systems and needed lookups, ...) are criteria for needing an architect.

I personally would add the criterion: Where one-to-many relationships mutate to one-to-verymany relationships, i.e. having hundreds of users accessing the same [vitual] server at a time.

Thomas

you lot might be interested in this:

http://www.thepragmaticarchitect.com

Hi Ram and everybody,

I've read an interesting article about the Characteristics of a software architect.
Ram, I understand you. In many cases the Architect has so many responsabilities because he is the most "senior" in the technical team.

Vagner

There are many different species of architects. Due to the focus on specialization rather than generalization, I have seen/known the following categories

Enterprise Architect - Deals with the big picture - deployment, security, physical infrastructure, footprint,Standard Operating Environment etc. Typically manages multiple applicaitons("IT Portfolio") running on disparate platforms, built by several teams over a period spanning years. This person is often the right hand for CTO/CIO/Director of technology and provides a level of abstraction to executive sponsors that hides unnecessary details.

Application Architect - Deals with specific appliation(s) and hence an expert in specific language/platform. He has two "faces". One that deals with nuances of language/platform such as design pattens, frameworks, standards, trends; and the other face is of domain knowlege- such as banking, insurance, transportation, or whatever is the domain the application is being built for. This person is a diplomat, a lobbyist, a consensus builder and balances between business goals and technological limitations. He is the liason between the technocrati and the business sponsors. He also provides critical feedback to PMs. Most of the discussion in this thread falls under this category.

Solution Architect - This guy faces backwords into the vendor space and provides critical support for application architects. There could be subspecialization of this category( typically in large organizatios ) along the lines of DB, AppServer/Platform, Security, Infrastructure and so on.

Security Architect - This is a role that has seen tremendous growth in the last two years. This person is reponsible for managing enterprise-wide security infrastructure - physical security, network security, application security, ACL directories etc. This person provides guidelines, governance and enforces standards across application project implementations. Auditing, Logging, SSO, Transport level security, encryption, digital certifications, shared secured infrastructures etc. are some examples of what this person manages.

Data Architect - This person is a combination of a DBA, a Vendor specialist and a person knowedgeable in domain data model. He is worried about data centers, clusters, replication, physical installations, application access points and dependancies, security for data at rest, SLA on data access and standards to name a few.

In addition to these well known categories, some of the other architects include - Product Architect( prevalent in product based organizations ), Integration Architect( for large organizations considering integrating their applications ) and Business Architect( domain expert who models workflows ).
[ May 15, 2006: Message edited by: Ajith Kallambella ]

Don and vagner,

Thanks for the useful links you�ve provided. They really helped me.

Ajith,

Thanks for your feedback and also for enumerating an array of possible prefixes to "Architects" along with their roles & responsibilities.

Originally posted by Vagner Freitas:
I've read an interesting article about the Characteristics of a software architect.

Excellent article. I especially like the following key points:

The software architect role is more often filled by a team, rather than represented by a single individual. That being said "team-based architects" are more prone to communication failure (and the usual personality struggles). They must use the same vocabulary to mean the same thing and the knowledge needs to overlap to foster understanding.

The architect primarily requires breadth of knowledge because of the scope of responsibilities. But some areas require some more in-depth knowledge to support communication with other parties and also to gain their respect. Development skills helps the architect deal with the development teams; domain knowledge help the architect with the business stake holders. On the whole the architect needs to know more than any specialist but the architect may not know as much as a specialist in reference to a particular topic. It is a lot harder and more work to be an architect than it is to be a specialist.

[ May 15, 2006: Message edited by: Peer Reynders ]

Wonderful article on charactristics of a software architect.

Thank a bunch for the link.

Originally posted by Thomas Taeger:
Even though clustering is an optional feature of J2EE, those vendors who realize it in a J2EE compliant way are [ideally] replaceable by each other. That is what I mean with "gave clustering an architectural concept" - instead totally vendor specific or even hardware solutions. I think the presence of the huge J2EE market justifies my evaluation.

While the whole "write-once-deploy-anywhere" (WODA) concept is nice, one should also realize that nobody is going to frivolously switch from one brand of application server to another. Just like it is highly improbable that a corporation would dump their Oracle RDBMS to switch to another RDBMS vendor, nobody is suddenly going to walk away from their WebLogic, WebSphere or OAS infrastructure to switch to another application server vendor. And just like Oracle Shops will use PL/SQL despite the fact that it's non-portable, each Shop will and should use the (worthwhile) vendor dependent enhancements of their particular application server - that's what they are paying for. This emphasizes the need to evaluate the organizations particular needs before selecting an application server vendor. So ultimately it is more important that clustering is implemented effectively rather than exactly how the clustering is implemented (or that it is implemented in a portable manner).

Part of the appeal of Java EE is that it tends to commoditize the developer workforce. In a pinch, if you can't find developers for your particular application server you can usually find some experienced in another Java EE server and bring them relatively quickly up to speed on your vendor's platform. This replace-ability also tends to reduce the labor cost.
Also if your vendor goes out-of-business you have a fighting chance to port your enterprise to a vendor who is in a healthier business position - it's not something you plan on but it's a good option to have.
Furthermore having multiple vendors supporting the same platform in the market reduces the impact in case your vendor "abandons" you. I can't imagine the shock that must have gone through COM/VB6 shops when it became clear that COM/VB6 would be left to stagnate in favor of .NET (right now COM+(MTS) is still supporting .NET but that's another issue). Microsoft will help during the transition period � but basically Microsoft can dictate that you will upgrade � there isn't an alternate COM/VB6 vendor to move to. This threat probably figured prominently in many shops deciding against Microsoft technologies.

Originally posted by Thomas Taeger:
the other extreme like "you must know every architecture" is not needed.

You don't need to know every architecture, nor do you need to know every detail. However when it comes to EJB you should now it's strengths and it's weaknesses, just as you should know the strengths and it's weaknesses of the major competing technologies (JDO, iBatis, Hibernate, Spring, etc.) so that you can ultimately choose the optimal solution. Ron Johnson has a blow-by-blow listing of some of the common EJB pros-and-cons (Expert One-on-One J2EE Design and Development: Chapter 1 J2EE Architectures p.20):
Implications of Using EJB

Using EJB makes applications harder to test

Using EJB makes applications harder to deploy

Using EJB with remote interfaces may hamper practicing OO design

Using EJB may make simple things hard

Reduced choice of application servers

Questionable Arguments for Using EJB

To ensure clean architecture by exposing business objects as EJBs

To permit the use of entity beans for data access

To develop scalable, robust applications

Compelling Arguments for Using EJB

To allow remote access to application components

To allow application components to be spread across multiple physical servers

To support multiple Java or CORBA client types

To implement message consumers when an asynchronous model is appropriate

Arguments for Using EJB on a Case-by-Case Basis

To free application developers from writing complex multi-threaded code (EJB's simplification of multi-threaded code is a strong, but not decisive, argument for using EJB)

To use the EJB container's transparent transaction management (The availability of declarative transaction management via CMT is the most compelling reason for using EJB)

To use EJB declarative support for role-based security

The EJB infrastructure is familiar

In Summary:

EJBs are a good solution to problems of distributed applications and complex transaction management. However, many applications don't encounter these problems. EJB adds unnecessary complexity in such applications. An EJB solution can be likened to a truck and a web application to a car. When we need to perform certain tasks, such as moving large objects, a truck will be far more effective than a car, but when a truck and a car can do the same job, the car will be faster, cheaper to run, more maneuverable and more fun to operate.

So really, when acting in an architectural role, not considering alternatives to EJB can be considered an instantiation of the Golden Hammer AntiPattern (In the SCEA assignment you have no choice). A good architect should never be caught using a Golden Hammer.

The Death of EJB As We Know It?
EJB Alternative ObjectJuice Announced

Originally posted by Thomas Taeger:
Because I actually tend to design for local access to entity beans the switch to EJB-3 will be moderate in the Data Access Tier.

While depreciation of a technology in the next version is a compelling reason not to use a technology, continued support in the next version isn't exactly a big motivator to use a technology. And the appearance of EJB3 doesn't eliminate the problems of solutions that where implemented against the previous specifications. You emphasize the use of local access of entity beans to highlight compliance with a best practice of hiding fine-grained entity beans (potentially behind a Session Fa�ade). But local EJB interfaces due to the containers interceptions still carry significantly more overhead than a plain Java method call � and the straightjacket of the EJB 2.1 interfaces still exists. So according Ron Johnson you only have one really compelling reason left for the use of EJB:

The availability of declarative transaction management via CMT is the most compelling reason for using EJB

So the question you have to ask yourself is: "Is that one advantage great enough to suffer all the remaining drawbacks for this particular business solution?". Or could you have actually solved this problem easier, faster and with less dead weight by using POJOs with JDO, Hibernate, iBatis (and possibly Spring)?

Now EJB3 improves things a lot. However existing EJB solutions will have to be refactored to take advantage of the new features and IT will have to switch to the next version of their application server that will support EJB3 � with the usual pains. However even EJB3 still has its warts. Chris Richardson summarizes some of those limitations in POJOs in Action: Developing Enterprise Applications with Lightweight Frameworks (Manning) p.368:
Key limitations of EJB3 (June 2005 Spec)

EJB3 only supports collections of entities. JDO and Hibernate can have collections of any old Object.

To preserve ordering you need to use the @OrderBy annotation which may require the addition of an index field to the class. JBoss offers a vendor specific extension (@IndexColumn) to get around this requirement.

EJB3 doesn't offer the option to delete a child once it is removed from the parent's collection � requiring additional coding (in potentially lots of places) to explicitly delete the child. Both JDO and Hibernate can be configured to do this for you. Again JBoss EJB3 introduced a vendor specific extension (@Cascade) to remedy this.

EJB3 shares with Hibernate the limitation that fetch joins cannot control eager loading when loading and individual object and traversing a relationship � which leads to a proliferation of similar variants of the "same query".

EJB3 does not support detachment of a fetch group like JDO 2.0 does. You either have to use multiple queries with different fetch joins (see previous limitation) or you have to manually navigate through the object graph, leading to more tedious and error-prone code that hardwires the entire object structure (in detail) in the application � both options increase the maintenance effort.

EJB3 dependency injection can only inject JNDI objects into EJBs. It does not support dependency injection of POJOs or provide some kind of integration with a light framework container such as Spring does.

EJB3 session and message-driven beans must be deployed in the EJB container, slowing down the edit-compile-test cycle � despite the fact that those beans are POJOs. Remote interfaces or Cactus is required for testing which increases complexity. Executing tests in a Spring-based application is still faster and less complex.

Ultimately you still need accept the complexity of incorporating a full-blown application server into your development environment even if you don't use the other parts of the Java EE stack, like for example, JMS.

Ajith and everyone,

Is there a website where I can find all these roles (different architects) and how they map to the overall SDLC process ?

I have seen organizations including my current one which thinks architecture is only limited to design stage in the SDLC thats all. I want to read more on these i.e. duties of an architect or its various roles like you mentioned but in a proper SDLC. Can I find one somewhere. I searched through SEI ...could not

Assuming there is a team of architects ...enterprise wide, basically making architecture a seperate shop within the organization which does overlook projects horizontally and vertically.

this forum rocks !
[ May 17, 2006: Message edited by: suekar meredilko ]

Hi Suekar,

Here is an IBM URL that talks about IT architecture and has various related links. Hope it helps.

http://www-128.ibm.com/developerworks/architecture/roadmap/