Techniques to Prepare for and Pass the TOGAF® Certification Exams

Scott S NelsonLeave a comment

There is a great deal of discussion at the various virtual gathering places of Enterprises Architects (and those that want to be) on what certifications are the most important to have. The answers vary a great deal, mostly depending on perspective. Those who are already EAs respond with the assumption that everyone has almost as much education, experience and influence as they do, and recommend the pursuit of areas that will enhance their abilities. Then there are those who own a particular framework who suggest that the certification they offer is the most desirable for any EA (which I sometimes agree with except for the “most” quantifier). Then there are the practical bunch that point out that TOGAF® is the most widely recognized certification and the framework that many of the others are based on. In essence, if you are competent in TOGAF® you can easily become competent in most other frameworks.

Background

Once someone suggests TOGAF®, the thread moves to how to pass the certification (though many other threads about other frameworks and why certifications don’t matter will continue even though the original poster is ignoring them by this point). I recently achieved TOGAF® certification, and wanted to share how I did it before I catch the disease that seems to affect many TOGAF®-certified EAs where they mutter about how easy it is and just take a course or read a book. I also like to write, so you’ll have to suffer through some of my prose to get everything that worked for me (and some things that didn’t).  However, if you are as impatient with my writing as I am with most others, you can skip to the end for the outline and links. Go ahead, it won’t hurt my feelings…much.

I’m also not going to go into a deep review of the exam structure or material covered. This is more about where to get the material and how to use it than the material itself. The structure of the exam will be reviewed in terms of how to approach in a manner that will help you pass, and the material will only be referenced at a high level for context.

While I have worked with enterprise architecture for a dozen years, it has always been with the various custom frameworks of clients and employers (when any at all) which tend to use internal terminology and definitions. For example, one employer labeled “Information Architecture” as the practice of how users interact with information and focused on the use of wireframes, navigation and content taxonomy. Another employer referred to “Information Architecture” when they were discussing the design, designation and distribution of data and its containers. Neither organization listed “Information Architecture” in a glossary, so if you didn’t happen to already know their definition you could become very confused (and appear very stupid) in discussion about “Information Architecture” and the organizations capability to contribute Subject Matter Experts on the topic. Having been confused and appeared stupid in training class for an employer’s internal Enterprise Architecture Framework over this difference in nomenclature, when the time came to chose between TOGAF® Level 1 training and TOGAF® Level 1 & 2 training, I opted for the first. For my particular learning style, this was a good choice, even if made for (perhaps) the wrong reason.

Approaches

If your learning style leans towards interactive exchange with an instructor and other students or you have no experience with TOGAF®, I would highly recommend taking a Level 1 class as a starting point. Level 1 focuses mostly on the terminology of TOGAF®. In TOGAF® terms, Level 1 is the Preliminary phase of the ADM. The Level 1 exam covers all phases of the ADM, and touches on all of the other sections to assure that an individual certified at this level can have a conversation about TOGAF and not be totally lost. The exam is multiple choice, and the questions are at least twice as hard as any of the practice exams I have seen. So if you opt for the classroom instruction, review the course materials thoroughly afterwards. Many courses will give you the exercises performed during the class broken out by sections. I found it helpful to repeat the exercises to note which areas I did not score perfectly in and review those topics again.

If you are one of those people who absorb information very quickly or have been following the actual TOGAF® approach in your day-to-day work, going straight to a combined Level 1 and Level 2 class will probably be more to your liking and benefit. Level 2 of the TOGAF® exam and certification is a deep dive into how to take all of those terms and apply them in real-world scenarios. Level 2 is an open book exam, where a scenario is presented, a challenge is described based on the scenario, and then four approaches are described and your job is to pick the best one. One of the four is totally wrong, and the others have degrees of correctness. The training class I attended had us answer the class exercise questions by putting them in order. While this is not how the exam is done, I found that approach very helpful in choosing the most correct answer on the actual exam. One exam approach that I found invaluable was to break down the question into TOGAF®-specific areas and then see which answer addressed the most of them according to the document.

Don’t let the open book aspect of the Level 2 exam fool you into complacency.  While it does not have the rote memorization aspect of the Level 1 exam, the answers all sound pretty reasonable if taken alone. Also, for those who have dealt with Enterprise Architecture where TOGAF® was not followed some of the answers that sound most real-world are the 0 point responses. The key to this part of the exam is to know the structure of the TOGAF® document so that you can quickly locate relevant sections and verify how closely an answer matches the document. Another point to remember is that in addition to the document, there is a general approach core to TOGAF® which is the collaboration between business, technology, Enterprise Architecture and Project Management.

Of course, there are those who learn perfectly well from only reading (or reading in addition to work experience) and they are welcome to ignore my training course recommendations. In fact, for simply passing the certification exams (as opposed to scoring well, which I have a preference for), you can get by without a course, too, if you follow all of the suggestions described here using the written material and any practice exams you can access.

I would highly recommend taking the exams separately as I experienced some dismay during the Level 2 exam as I noticed which answers I got wrong on the Level 1 exam, which is a distraction.

Planning is Everything

One note from my personal experience is that having taken the path of a Level 1 course and certification followed by a combined Level 1 & 2 course (there was no Level 2-only course available to me at the time) I assumed that I would be able to simply take the Level 2 exam to complete my full TOGAF® certification. Turns out I need to have discussed this with the training company before taking the course as I received a voucher for the combined exam instead of just the Level 2. I could not exchange the voucher, and the testing center would not allow me to take only the Level 2 with that voucher, even though I had taken the Level 1 course with the same training company and the exam with the same exam provider. Fortunately I don’t know if this rigid process would have resulted in my not having been certified if I failed the Level 1 exam the second time around, though I’m sure it would have entailed a great deal of time consuming communications to correct that situation had that been the case. I suppose it is very much in the spirit of TOGAF® to never assume that all parties think about the same model from the same viewpoint.

My Ultimate TOGAF® 9 Certification Preparation Process by the Numbers

OK, so here it is, as promised:

Before the exam…

  1. Read TOGAF® 9 Certified Study Guide
  2. Attend a course
  3. Read the TOGAF® 9 spec cover to cover
  4. Review the course materials

During the exam…

  1. If possible, take the Level 1 exam and Level 2 exam individually
  2. If not 100% positive about the answer, mark it for review
  3. For Level 1, do not spend more than two minutes on any question for the first pass
  4. Complete all answers in the level before reviewing
  5. If you don’t know an answer pick one at random and mark it for review
  6. Once completing all the answers, begin the review with the first question. Some of the answers will now be obvious from later questions, so go through the marked questions quickly the first review and answer the ones you know are confident about
  7. On the first review, do not spend more than 1 minute per question
  8. If not 100% certain, leave marked for review
  9. On the second review, take your time and answer to the best of your ability, leaving those you are not 90% sure of marked for review
  10. Review until you run out of time
  11. For Level 2, list the parts of the question that map to TOGAF® then check each answer for addressing those items. The one that addresses most of those items is the most likely answer

Conclusion

In all honesty I can’t say that any one source for how to pass the exam is going to work for everyone capable of passing. I hope that I have given you one of the better approaches, including the suggestion to look for blog entries and articles and discussion that have further tips specific to your needs. What I have described here worked very well for me, with the key advice I found at one site being to look for the answer that was the most TOGAF®-ish and that was generally the best answer. The studying approaches I described are what allowed me to apply that excellent advise.

Other Resources

If you found this interesting, please share.

Establishing WebLogic Server HTTPS Trust of IIS Using a Microsoft Local Certificate Authority

Scott S NelsonLeave a comment

Everyone agrees that self-signed and demo certificates for SSL and HTTPS should never be used in production and preferred not to be used elsewhere.  Most self-signed and demo certificates are provided by vendors with the intention that they are used only to integrate within the same environment. In a vendor’s perfect world all application servers in a given enterprise are from the same vendor, which makes this lack of interoperability in a non-production environment an advantage. For us working in the real world, where not only do we not use a single vendor everywhere but have to make do with self-signed certificates for all but production, testing HTTPS between an IIS ASP.NET service provider and a WebLogic J2EE consumer application can be very frustrating to set up. It was for me, especially having found many blogs and discussion threads where various solutions were described but did not quite work and were all mostly similar but just a little bit different. To save both you and my future (who always seems to forget the hardest-won lessons) all of the pain and suffering, I am recording the steps that finally worked here for reference and sanity.

How You Know You Need This

The first cold clutches of dread that tells you it is going to be a long day is when you attempt to a WSDL published by IIS in WebLogic over HTTPS and you see the following:

<Jul 30, 2012 2:51:31 PM EDT> <Warning> <Security> <BEA-090477> <Certificate chain received from myserver.mydomain.com – 10.555.55.123 was not trusted causing SSL handshake failure.>

weblogic.wsee.wsdl.WsdlException: Failed to read wsdl file from url due to — javax.net.ssl.SSLKeyException: [Security:090477]Certificate chain received from myserver02.mydomain.com – 10.555.55.123 was not trusted causing SSL handshake failure.

The above is what started a three day sojourn into searching for a solution. Even people who had solved it before would tell me how they did, and then shrug when I demonstrated that the steps did not end in the success they claimed I would experience. Rather than torture you with the details of everything I did that did not work, here is what finally did work.

Export the Certificates from IE

First, take the offending WSDL URL and paste it into IE (if you have an internal Microsoft CA, you have IE, even if you don’t use it in favor of some other browser).  To state the semi-obvious, if you received the error above there is a certificate configured for the IIS host of the service and the SSL port has been configured properly. Otherwise there would be a different error, usually about the site not found or connection failed.

Once the WSDL loads, to the right of the address bar there will be a lock icon. Click the lock and then click View Certificates in the resulting dialog (if you do not have a lock icon but do have a Certificate Error message, see http://support.microsoft.com/kb/931850 for steps to install the certificate then you can continue from the point of finding the lock icon).

Figure 1: View Certificates in IE
Next, select the Details tab in the resulting dialog

 

Figure 2: Use Certificate Details to Export Certificate
Figure 2: Use Certificate Details to Export Certificate

Figure 2: Use Certificate Details to Export Certificate

Click Copy to File, then Next, then select the Base-64 encoded option for the format

 

Figure 3: Select the Base-64 encoded option for the format
Figure 3: Select the Base-64 encoded option for the format

Figure 3: Select the Base-64 encoded option for the format

For the sake of simplicity, I choose to save this to the root of the WebLogic domain. It will work from anywhere, but later you will need to type in the full path rather than just the certificate name if you save it elsewhere.

 

Figure 4: Browse to Save Location
Figure 4: Browse to Save Location

Figure 4: Browse to Save Location

 

Figure 5: Save the Certificate to the Domain Root for Convenience
Figure 5: Save the Certificate to the Domain Root for Convenience

Figure 5: Save the Certificate to the Domain Root for Convenience

This is the point where I ran into some confusion. Some articles mentioned exporting the entire chain of certificates. This supposedly works for some types of certificates, or if you have a few other tools and the time to learn them. For the SSL experts out there, they already have these tools, know how to use them well, and should not be wasting their time reading this article meant for folks who just want to get things wired up and back to unit testing and development. For the rest of us, the easiest way to make sure things will work is to just export all the links in the chain individually and let WebLogic Server worry about re-assembling them into a chain (which it does quite nicely). While perhaps not the most elegant solution, the multi-step process is easy to repeat and uses only tools that are immediately available and require no learning curve. So…

Next, go to Tools then Internet Options then the Content tab and click Certificates. Go to the Trust Root Certificate Authorities tab and find the certificate root for your Microsoft CA cert (look for the Issuer of the certificate you exported earlier).

 

Figure 6: Trusted Root Certification Authorities Tab

Figure 6: Trusted Root Certification Authorities Tab

Export this one the same way as before, with a different name

 

Figure 7: Use a Unique Name for Each Certificate
Figure 7: Use a Unique Name for Each Certificate

Figure 7: Use a Unique Name for Each Certificate

Repeat this once more for the Intermediate Certificate tab.

Import the Certificates to the WebLogic Domain

Now, open an command prompt, navigate to [WEBLOGIC_DOMAIN_ROOT]bin and execute setDomainEnv. You should then be in the root of the domain. If not, CD to the domain root.

Assuming you saved the certificate in the domain root, execute the following:

keytool -importcert -alias [ALIAS-1] -trustcacerts -file [FULL PATH TO .CER 1] -keystore truststore.jks -storepass [PASSWORD]

An example with the variables filled in is:

keytool -importcert -alias IIS-1 -trustcacerts -file microsftcert.cer -keystore truststore.jks -storepass password

After several lines out output you will be prompted with:

Trust this certificate? [no]:

The correct answer is ‘yes’ (minus the quotes, of course). You’ll you know you were successful if the response is:

Certificate was added to keystore

If not, check your typing, as that is generally the source of an error at this point.

Repeat this for all three of the certificates you exported, changing the [ALIAS-1] and [FULL PATH TO .CER 1] value each time. For example:

keytool -importcert -alias IIS-1 -trustcacerts -file microsftcert.cer -keystore truststore.jks -storepass password

keytool -importcert -alias IIS-2 -trustcacerts -file microsftcertRoot.cer -keystore truststore.jks -storepass password

keytool -importcert -alias IIS-3 -trustcacerts -file microsftcertIntermediate.cer -keystore truststore.jks -storepass password

In the above we created a new JKS key store. You can re-use an existing one by changing the name of the JKS file to one you already have and change the password to the one that matches that JKS file. For the DemoTrust.jks  that is included with WebLogic the password is DemoTrustKeyStorePassPhrase. An example here would be:

keytool -importcert -alias IIS-1 -trustcacerts -file microsoft.cer -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

keytool -importcert -alias IIS-2 -trustcacerts -file microsoftRoot.cer -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

keytool -importcert -alias IIS-2 -trustcacerts -file microsoftInter.cer -keystore DemoTrust.jks -storepass DemoTrustKeyStorePassPhrase

Whichever keystore you use, you can check your work with:

keytool -list -keystore truststore.jks -storepass password

Where “truststore.jks” and “password” can be replaced appropriately if necessary. The output will look something like this:

 

Figure 8: Output from keytool -list -keystore
Figure 8: Output from keytool -list -keystore

Figure 8: Output from keytool -list -keystore

Update the WebLogic Keystore Configuration

If you used an existing keystore rather than creating a new one, you can restart your WebLogic Server and skip the rest of this section. For those of us who created a new one because that is the instructions we found online…

Next, we need to tell WebLogic to use the JKS file (truststore.jks) we just created. Log in to the WebLogic Server Administration Console and navigate to Servers > AdminServer > Configuration > Keystores. Scroll down to “Custom Trust Keystore:” and change the value to “truststore.jks” and the value of “Custom Trust Keystore Passphrase:” and “Confirm Custom Trust Keystore Passphrase:” to the password you used when earlier, then save your changes. You will get a nice message similar to the following:

 

Figure 9: To Be Safe, Restart Anyways
Figure 9: To Be Safe, Restart Anyways

Figure 9: To Be Safe, Restart Anyways

The “No restarts are necessary” is somewhat of an exaggeration. If you want to be able to use the keystore you may need restart the server(s). To save myself aggravation, I always do. Your mileage may vary.

Conclusion

That should get you there. If there are some erroneous steps included for your situation in particular, I will offer up a semi-apology as the process described above does not take long at all and if there is one step that could be dropped from it, is still much faster than trying to figure this out from other sources.

If you found this interesting, please share.

The Hitchhiker’s Guide to WLP 10.3.4 Domain Creation

Scott S NelsonLeave a comment

When creating a new WLP domain at the stage where you run the scripts to create the tables, at completion of the script run you may see:

CFGFWK-60839:  Database Load Failed!

Don’t Panic 🙂

It seems that sometimes the scripts don’t run in the proper order. Simply run them again after receiving the error and the second time should be fine.

If you found this interesting, please share.