May 4, 2005

What an J2EE Architect needs to worry about?

My aspiratation is to become an J2EE Architect and I'm steadily progressing in that direction. As part of my experiecnce with few large J2EE projects/ reading many books on J2EE/googling/reading articles I try to list down the responsiblities/worries of an J2EE Architect. This is WIP document. I will be updating based on the comments and suggestions.

-------------------------------------------------------------------------------------
The best architects are good technologists and command respect in the technical community, but also are good strategists, organizational politicians (in the best sense of the word), consultants and leaders.
(I have taken this from here. This is a good site on Software Architecture Discipline)

Here is the list:
1. Methodology
2. System Design
3. Architectural Artifacts
4. Environments
5. Development
6. Build and Deployment
7. Testing
8. Tools
9. Miscellaneous Deliverables

Lets take one by one.
1. Methodology
a. Rational Unified Process (RUP)
b. Agile Methodologies
b. Xtreme Programming (XP)
c. Crystal
d. Feature Driven Development
c. Hybrid of RUP and XP

a Rational Unified Process (RUP)
The Rational Unified Process collects many of the best practices of OO analysis and design to form a process framework with 38 different artifacts. RUP is not generally considered lightweight, although a lightweight configuration called dx (“xp” turned upside down) exists. Of course, not all 38 artifacts are required in either RUP or dx. In fact, the process framework is configurable to as few as two (use cases and code) artifacts. However, the general RUP-based process uses quite a few requirements, analysis, and design artifacts because its developers based this process on the activities of the OOA/D movement.

b. Agile Methodologies


c. Xtreme Programming (XP)
Extreme Programming has been the pioneer in the modern movement toward lightweight processes. XP emphasizes a single major artifact, the code itself. This process uses 3” x 5” cards to capture requirements in user stories and design via CRC (class, responsibilities, and collaboration) cards, the minor artifacts of the process. XP is much more than user stories, CRC cards, and coding, however. Testing frameworks and innovative practices such as pair programming (working in groups of two people) make XP an interesting addition to the field of software development processes

d. Crystal
Crystal is a lightweight process that contains 20 artifacts. This might sound like a heavier process than XP but most of the artifacts are informal and can take the form of “chalk talks” (working problems out on a chalk board), conversations, and e-mails. Of these 20 artifacts, only the final system, the test cases, and the documentation are formal. Crystal divides its artifacts into levels of precision (20,000-foot view, 5,000-foot view, 10-foot view) to allow developers to focus on their objectives.

e. Feature Driven Development
Feature-Driven Development is an incremental approach that uses as few as four artifacts (feature list, class diagram, sequence charts, and code). The FDD process focuses development using two-week iterations to show quick tangible results. Among the contributions this process provides is a semantic-based class diagram template—called the domain neutral component, which differentiates types of classes by color—to aid class designers in developing a domain model.

f. Hybrid of RUP and XP

No comments: