Jimmy Clark

XML-based languages can be significantly complex, DocBook or Financial products Markup Language (FpML) for example. Understanding what XML is in terms of a specific vocabulary and having the knowledge, skills and abilities to develop XML processing code are not the same thing. Neither one of them can be "mastered" in one week, in my opinion.

Aside, contractors that support existing COBOL-based business applications "rake in the dough."

I'd say that XML could be mastered within a week, if you understood the underlying concepts and if "XML" just meant the markup language and nothing else.

The eXtensible Markup Language is a meta-"format" for creating markup languages. XML is not a markup language itself and was not properly named. That said, the design skills needed to effectively create XML-based markup languages which are efficient and supportive of related processing technologies cannot be "mastered" in one week, in my opinion.

Aside, knowledge of COBOL, the ability to write, read, modify COBOL programs is an EXTREMELY valuable skill...and is very rare. The number of existing COBOL systems throughout the world make this a very good bet.

But the only drawback here is that you will have to live on the mercy of others by asking them to help you. I was looking for some self study / self learning kind of stuff to get me going.

There are drawbacks in everything. You are trying to alter and improve the way you think. This is not something easily accomplished, and even more difficult when attempted in isolation.

In regards to material to study, here you are still depending upon someone, the author of the material. The only real differences here are that you are not communicating with the author, cannot ask questions, and are gambling with the accuracy level of the author's material.

Either way, it seems like you are off to a good start by identifying your deficiencies. Good luck son!

One of the more important elements of being a software architect is the ability to teach junior programmers and developers. Communication and teachining skills are the critical elements. So, if one wants to learn software design, they should "humbly" ask their architect to teach them. This is how you can improve your software design skills...

There are lots and lots of design patterns of different classification. You've got creational patterns, behavioral patterns, structural patterns etc. Some are documented, some are not (and in turn may not be recognized).

All object-oriented design patterns are documented. Documentation is "the" fundamental element of an object-oriented design pattern, i.e. it is not an object-oriented design pattern if there is no documentation.

How many developers are there in the world today?

A database administrator is an operational position, not a management position. A Data Architect position is not the same as a database administrator. Depending upon the nature of the position, a database administrator may also handle database programming as well as administration. This is still a low-level position, i.e. not tactical or strategic.

Keep in mind that Information Systems and Computer Science are different educational tracks, intended for different experiences and knowledge areas. There are some similarities, but there are key differences as well. Computer programmers come from both tracks, they typically have different skills and abilities.

You basically should start to enjoy testing, development skills are very different.... keep testing and you should be good...

Well, there should be a Business Delegate in the middle of your call to the business methods. Actions objects should never call directly on EJB methods...

Certifications that are controlled by for-profit companies are always geared towards sales revenue. In these situations, the certificates, exams and related training are "products." This is not a personal opinion. This is a widely known fact.

"For the last 5 years I have been running a mobile/telecom space consultancy startup. [...] Last month I decided to call it a day."

Instead of "Founder", you might want to consider using "Principal".

However, if you were the "founder" of the organization, and you abruptly decided to "call it a day." This may create the perception that you were not successful, failed as a business operator, or some other negative interpretation. You should be prepared for this.

For applications for low-level positions, you can use "Principal/Project Manager", "Principal/Business Analyst", etc.

If I mention something like “Project Manager” then at some point in time, especially when they conduct background checks, I will have to come out with the truth which again will put me in a difficult situation.

You are not being dishonest here, or at least it does not seem to be the case. It looks like your imagination is running a bit wild and you should keep it in check...unless the falsehood lies in what you are presenting and you are a bit paranoid.

I have a idea for a web-based startup that I think would provide major time and cost savings to my field, as well as several other verticals.

If you are interested in creating a company, then you should visit a couple of banks and/or other financial institutions to learn how to get financing, i.e. what is expected in your presentation, how to present your business concepts in the best light, etc.

There are a few steps that are needed before starting object-oriented design activity. Many of the posts in this thread are touching upon them in one way or another. Below is the J2EE-based standard approach published by Sun Microsystems.

Use Cases (Narratives and Diagrams)

Business Requirements (based on the Use Cases)

Technical Requirements (based on the Business Requirements)

Object-oriented design (based on the Technical Requirements)

Non-Technical Requirements

Architecture design (based on Non-Technical Requirements)

The bond must have some purpose in this situation. Whether the organization enforces the conditions specified on the bond depend on the organization. It is surely possible that they may want you to "cough up some rupees" if you break the contract. Surely you read the contract before you signed it. Aside, before signing you should ask if you can have a copy. If the answer is "no", then you can decide if you still want to sign the contract.

They may choose to not provide copies to prevent attempts to make false copies to invalidate the true bond. If the bond has a raised seal, then it is harder to make a false copy and they should be less reluctant to providing a copy.