File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
The moose likes Architect Certification (SCEA/OCMJEA) and the fly likes OCMJEA/SCEA passed today Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Architect Certification (SCEA/OCMJEA)
Bookmark "OCMJEA/SCEA passed today" Watch "OCMJEA/SCEA passed today" New topic

OCMJEA/SCEA passed today

Yegor Bugayenko
Ranch Hand

Joined: Feb 11, 2011
Posts: 79
As the email from Oracle says from today I'm a proud holder of OCMJEA/SCEA certification. First of all I have to say big thanks to this forum. Without it my certification process would take much longer and would be much more difficult. Let me share a few thoughts which may sound not very typical comparing to what was already said here. Maybe they will help some of you:

"Mention development environment". My deployment diagram contained nodes from the development environment, including continuous integration server, source code repository, and issue tracking system. I explained visually how these nodes are connected to the production environment. I think that in modern systems development environment is as important as production and they have to be designed together.

"Risks are not issues". I clearly separated risks from issues. Issue is something that the designed architecture is solving. Risk is what is not solved by the architecture, but is documented. For example, my architecture contained a Demilitarized Zone (DMZ) as a a response to security threat. Since this issue (the threat) is solved it is not in the risk list any longer. At the same time there is a risk that once this DMZ is penetrated all data inside are not encrypted. I decided not to encrypt them, but document this potential threat in the risk list. See the difference?

"Document your assumptions". I listed a number of assumptions on top of my assignment document. By an assumption I've meant something that is not explicitly explained in the requirements document, but was understood by me in some way. For example, the requirements said nothing about "admin functionality" and I assumed that there is no such functionality required. I have documented this assumption in the first chapter of the architecture document. Thus I have explicitly filled an existing gap in the requirements.

"Make calculations". My requirements document had a number of non-technical statements about performance NFRs, e.g. "the client will have up to 100 orders every hour". I did some calculations in order to convert such statements into more specific numbers, like "pages per second", "RMI calls per hour", "Mbits/second", etc. I documented my calculations and based all other technical decisions on them.

Again, thanks to the JavaRanch forum for the help provided!

SCEA, PMP, read my blog:
Sharma Ashutosh

Joined: Apr 06, 2001
Posts: 346
Hi Yegor Bugayenko,
Thanks for sharing this information.
How long it took for them to evaluate your assignment and part3?

Ashutosh Sharma
SCJP 1.2, SCEA 5, Brainbench certified J2EE Developer, Documentum Certified Professional
Blog :
Yegor Bugayenko
Ranch Hand

Joined: Feb 11, 2011
Posts: 79
One month.
Bhanu Prakash Gopularam

Joined: May 09, 2006
Posts: 19
Hi Yegor Bugayenko,

First of all, My heartiest congratulations to you.

I am bit confused about component diagram and not able to proceed. Could you please clarify below question:

How much detail should be show in component diagram. Is it enough we show something like in Cade's example. One diagram showing all components very high level.
Or Is it better to split into multiple component diagrams and show all controllers, classes, DAOs, Session beans etc separately?

Could you please mention something about your component diagram (number of diagrams, level of detail, any other info).

Please clarify.


SCEA 5 certified
I agree. Here's the link:
subject: OCMJEA/SCEA passed today
It's not a secret anymore!