Just under a year ago, I wrote a blog entry on how I study for a certification exam and only a mere 10 months after tailoring it to pass the TOGAF 9 (The Open Group Architecture Framework) certification exam, I am in a position to reuse it, as I am working towards completing ISTQB (International Software Testing Qualification Board) Foundation Level certification as an important part of my work at Meticulon.
As I did before with the TOGAF 9 exam and the PMP (Project Management Professional) exam before it, I plan to tailor my general process for the specifics of the ISTQB Foundation Level certification exam and chronicle it here.
The first obvious potential pitfall here is to underestimate the exam. Let’s face it, there are many a developer (which is my background) that would look down on testing as less intellectually demanding. I myself was guilty of that in my past. But fortunately after personally having done a lot of work to build a training curriculum for the people I am training to get jobs in software testing (and to also complete this certification down the road), I have come to realize that the software testing discipline is built on a very large foundation of concepts, processes and tools.
Software testing definitely requires strong aptitudes, capabilities and skills to be a proficient software tester and the software testing knowledge base is very broad involving many different levels, methods and types of testing which each have their own set of processes and tools to support them. As well, the demands for a software tester (software test engineer) have grown to include things like scripting, programming, behaviour driven design (BDD) and test driven development (TDD) such that the demarcation lines between software developer and software tester have blurred. This is so regularly the case, that often software developers get their first jobs as software testers these days before becoming full-fledged developers.
Ok, enough justification, on to the actual exam preparation…
(Previously completed – Read the ISTQB Foundation Level Syllabus and create and deliver a training curriculum)
Baseline test (not the ISTQB official sample exam)
Read the ISTQB - Foundation Level Exam Structure and Rules Version:1.2
Re-read the ISTQB Foundation Level Syllabus
Do the ISTQB official sample exam
(Optional – purchase a Foundation Level prep guide from an accredited training provider)
More sample testing until scoring 80% or higher on 3 consecutive (including repeating the ISTQB official sample exam again)
Schedule the certification exam
Re-review text(s) at a high level.
Keep the material fresh by regularly attempting sample questions
Ace the exam.
I believe that I will not need to purchase a prep guide nor take a training program from an accredited training provider given my familiarity with the material and predisposition to self-learn, but those are always useful options for people who learn better from a structured book or a class based training program (whether online on in-person). As I proceed with this process I will update this post to include exactly what I did and any corresponding results.
As always, I start with a baseline exam and using an online test available on testingexcellence.com (namely istqb-foundation-practice-exam-1), I manage to identify the correct answer on my first try on 20 out of 40 questions giving me a score of 50% (despite the website’s scoring which scored me 78%, which I guess accounts for getting the answer correct on subsequent attempts). This score is significantly short of the required 26 out of 40 or 65% to pass the ISTQB Foundation Level exam and my own personal goal of 80% or better on any exam.
Of course, I have no idea at this point how representative this exam is compared to the official ISTQB foundation exam. But despite my recent work in software testing, it probably should not come as too much of a surprise given that most of my experience is in software development, architecture and project management. But it does validate my earlier point about how software testing has truly become and always was an IT discipline worthy of respect (which it often does not receive).
The next steps are to actually read the preparation guide and syllabus in depth which will take a bit of time. But having taken an exam and been found lacking, I will be more motivated to really learn the material and that is the whole point of doing the baseline.
Photo Credit: Cartoon by Andy Glover, used with permission from cartoontest.blogspot.com
If you found this blog post useful, I happily accept tips in:
So after an initial less than wildly successful foray into mining cryptocurrencies (although I haven’t yet thrown in the towel), I’m turning my focus towards investing in cryptocurrencies.
Investment in cryptocurrencies basically has three possible forms, direct investing, indirect investing and venture capital. I’m going to look at the first method in this post and leave the other two for future posts that will focus on profiting from cryptocurrencies through indirect investing and entrepreneurship.
So how does one invest directly in cryptocurrencies…
Direct investing involves buying cryptocurrencies speculatively in order to profit from changes in exchange rates. Fairly simple, but there are a number of pitfalls that could arise here including how to trade currencies, counter-party risk and rules around taxation.
In the early days of cryptocurrencies, there were no exchanges, so trades often took place face to face and set up through IRC chat. While this has the advantage of removing transaction fees, its not much different than if you set up a meeting with someone to trade dollars for euros. I find selling used goods on Craigslist a bit dodgy and really if you are going to deal in any substantial amounts this is probably best avoided to avoid fraud.
Fortunately this wild west method of exchange was usurped by virtual exchanges which, if you are familiar with the Mt. Gox exchange’s highly publicized demise, does still have considerable counter-party risk.
So first you need to find a fairly reputable virtual exchange (or exchanges). You may actually need one to convert from fiat currencies (dollars, euros, pounds, etc.) to some of the more widely accepted cryptocurrencies (Bitcoin, Litecoin, Dogecoin) such as Bitstamp and use another exchange to further convert to lesser accepted cryptocurrencies such as Cryptsy. When deciding upon an exchange issues such as security measures, KYC (Know Your Client) requirements, and transaction fees (for deposits, trades and withdrawals) should be considered.
Once you have accounts set up on one or more exchanges, there are basically two familiar equity strategies to employ, namely buy and hold and arbitrage. In either case, one needs to be aware of fees for trading and deposit/withdrawl. Additionally, due to the considerable counter-party risks of hacking theft and financial stability of the exchanges, you may need to download the appropriate cryptocurrency wallet (always use an official site when downloading a wallet) and even consider storing that wallet on an offline device such as a USB stick. Check out this blog for more details on storing your cryptocurrency safely.
Buy and hold is exactly how it sounds. Purchase one or more cryptocurrencies using your dollars (or other fiat currency) and hold them for a period of time. Hopefully over this period, a profit is realized over just simply holding dollars. In this case, it likely makes sense to store this in an offline wallet (with backups and wallet password information that is safely secured as well) until a sale is planned.
Arbitrage on the other hand seeks to take advantage of bid/ask spreads. In many online exchanges the spreads between bid/ask are significant enough to be able to profit from simply putting in bids to buy near the bid price and waiting for someone to sell you the currency at that price and then turning around and selling near the ask price and waiting for someone to buy the currency at this price. The profit from the arbitrage pair of trades is the difference between the purchase cost and the sale proceeds minus fees. Sounds easy, but it is affected by the volume of exchange (how long it takes to complete the pair of trades) and price volatility. With high volatility, more frequently you will buy (or sell) and not be able to make a paired trade profitably as the price will have fluctuated below your purchase price (or above your sale price). Additionally, you will need to keep more of your cryptocurrency (and cash if you are trading to and from cash) on the exchange which has the previously mentioned counter-party risks.
In either buy and hold or arbitrage, trades may be subject to taxation rules based on the tax treatment of your jurisdiction. In Canada, cryptocurrencies are treated similarly to a commodity for investment purpose and generally gains (and losses) are treated as capital gains (losses) with some exceptions for professionals who are investing as a business. It may be the case that only trades from fiat to cryptocurrency and vice versa are considered taxable events, which might be important especially for an arbitrage strategy. Note: barter rules apply for retail transactions but that will be discussed in a future post around entrepreneurial endeavors.
The big question is what kind of profits can one expect to achieve?
It certainly does not seem out of the question that a single digit multiple is possible in Bitcoin (as it is currently trading at under half of its Dec. 2013 peak), and moreover with Litecoin or Dogecoin with a buy and hold strategy. Buying and holding a lesser known coin has a bigger payoff potential, but also a 100% loss scenario becomes more prevalent. If one decides to pick a new currency to invest in, the next question is which one or in other works what is the differentiation criteria between all the coins available? Ultimately it is the community and confidence behind a cryptocurrency that gives it its value, if a large community gets behind it a currency then it has a greater chance of acceptance. I suspect that at some point a country will mint its own digital currency (as opposed to adopting current ones) and that might be a good opportunity. Additionally if a big company or social community (like facebook or twitter) created a coin with a purpose, those could have good potential for success. Obviously following the cryptocurrency social media environments is a good way to keep an eye out for such opportunities and I will do just that. Ultimately I think the best strategy for a buy and hold for the time being is to start with Litecoin or Dogecoin and continue to look for opportunities on the secondary alt-coins.
But what about arbitrage, can better profits be found here than just buying and holding? First an arbitrage strategy is going to require a greater time commitment than buy and hold (to track bid/ask spreads and put in limit trades). But I have already started to see that people are starting to build automated bots / trading platforms to try to automate this. It would appear that the spreads are significant enough, but is the turnover (volume) there as well? I feel like yes, but only for now. If cryptocurrencies continue to gain in popularity, one would expect the spreads to shrink but turnover/volume to increase. Additionally I would expect additional players to enter the arbitrage market with automated tools as we are already seeing. Ultimately I suspect this market will become like the arbitrage markets in Forex and equities, where only market makers with high frequency trading solutions run by major firms will be able to generate profits (but there may be a entrepreneurial opportunity here).
So I think for me, I will go the buy and hold route initially. While I do think there is an arbitrage opportunity currently, it will be too time consuming for me to take advantage of and I suspect it is only going to be available for a limited time. In the next post I will look at indirect investing and then entrepreneurial opportunities in the following one.
Photo credit: Lendingmemo
If you found this blog post useful, I happily accept tips in:
So the last piece of the puzzle came together as I started mining this weekend. It really was pretty simple given that I already had Cudaminer installed and benchmarking, all I needed to do was decide whether to mine solo or join a pool.
While I never really had the impression that the mining opportunity with my limited rig was going to be a gold rush, I did have some expectation that it would be possible to turn a meagre profit, breakeven (pay off the fixed costs), or at worst pay off the electricity that it consumes (pay for the variable costs).
On to the verdict…
But first I need to catch us up. Last post, I completed the OS install, but did not describe the process to get Cudaminer installed.
To do so I found that I needed to combine the instructions from the Cudaminer github wiki page on compiling cudaminer, this post on litecointalk.org and this post on reddit.
Effectively you can follow the steps in the CudaMiner wiki up to the point where you are going to compile CudaMiner. At which point you need to use the second post to modify the LD_LIBRARY_PATH and PATH environment variables and the third post provides (in step 6 and 7) steps to add the libcurl4-openssl-dev library which the Wiki does not mention. Finally switching back to the Wiki page to complete the final steps to compile the code and run it.
Once you have CudaMiner working, it is time to start mining. But that requires a bit of work to really understand how mining works and then decide what and how to mine. I recommend reading the following the first three paragraphs of this blog to understand how it works.
In terms of what to mine, there are quite a number of currencies to mine and you can either mine solo or as part of a pool. Additionally, you can even join profit switching pools which attempt to mine the most profitable coin and switch when that changes. With pools, the payout can be in the currency mined or it can be exchanged for a different currency (often bitcoin or to a lesser extent some of the other more popular alt-coins). The pools use a myriad different algorithms to decide how to divvy up the spoils of mining.
Mining solo offers the benefit that you do not have to share the spoils when you “solve a block”. But if you liken your hashing rate (the computation power of your GPU to solve the mining algorithm) to lottery tickets, it is like as if you have a single ticket and the pools have millions, billions or trillions (in the case of bitcoins) of tickets. Only one ticket is selected every mining period, so the likelihood of yours being selected is very small, so your effective payout is zero, except for cryptocurrencies that have very small network hashing rates (i.e. your hashing rate is at least 1/1000th of the currencies network rate). If we use that hashing rate / network rate ratio for a cryptocurrency with a 10 minute mining period, it would be reasonable to expect that we would find a block on average once every 7 days (7 days * 24 hours * 6 blocks / hr = 1008).
For currencies with higher network hashing rates, for the individual miner, a pool becomes the only option. At least in a pool you will receive some (albeit small) portion of the spoils when your pool solves a block.
When a block is solved, the miner (or pool) receives the reward, which is a number of units of the cryptocurrency. Thus the ROI of mining for mining becomes:
Return (solo) = %CSB * BP * Rew * Exch Rate
= NHR / IHR * BP * REW * Exch Rate
Return (pool) = %CPSB * IC * (1 – PC%) * BP * Rew * Exch Rate
BP = Block Period (estimated time to solve a block)
Rew = Reward
Exch Rate = Exchange Rate (if you want to convert to a fiat or other currency)
NHR = Network Hashing Rate
IHR = Individual Miner Hashing Rate
PHR = Pool Hashing Rate
PVS = Pool Valid Shares
IVS = Individual Valid Shares
PC% = Pool Commission Percentage
Note: I assumed a proportional sharing of the reward within a pool. Some pools use different algorithms to share the spoils. Also, the Return is per block period length, you may want to adjust that to days, months or years as desired. To solve ROI (Return on Investment), you would need to include the variable and fixed cost components.
Whew. So I decided that I first wanted to try my hand at mining litecoins. Given its huge network hashing rate, I decided to find a pool. There are a lot, with a lot of different options. Finally I decided on ltcbox.net. This is a pool dedicated to litecoin and my initial interest was with LTC so I figured it had a reasonably friendly interface, a good pool hashing rate and a 1% commission rate.
So first I needed to register to set up my account username and password. After validating the account, I needed to login and setup a worker. Under the my workers section, I simply add a new worker name and a password. There are also account settings for exchanging to other currencies or paying out automatically but since I have no wallets set up yet I just figured I would pay the manual transfer fee.
Now I can start mining. I just need to run Cudaminer with the following command (although I recommend setting up a script to contain this information):
./cudaminer -o stratum+tcp://pool.ltcbox.net:3333 -u [Account Name].[Worker Name] -p [Worker password]
Where the values in square brackets need to be replaced with your specific account and worker details. Additionally if you used other pools you would switch the URL and Port to those for the pool.
The command runs and after some autotuning the card is actively contributing shares to the pool. A refresh of the account after a couple of minutes shows the same. My hashing rate is a fair standard 250 k/hash for this card. The temperature reaches a ceiling at a relatively cool 51 degrees Celsius, fan speed on the GPU reaches a ceiling at 65%. Pretty good. The estimated share of the spoils seems very small though but I figure maybe there is some error. I decide to give it some time.
Fast forward to about 8 hours later. I have mined an estimated almost 0.015 LTC (final amount was 0.013689). At the current LTC/USD exchange rate this is worth about 14 cents. I think it probably cost me 14 cents in electricity just to boot the machine (never mind the cost of running the machine for 8 hours). So obviously this is not working. I shut it down for the night.
The next day, I try mining Coino and Fluttercoin with marginally better profitability, but nowhere near paying for the power consumption.
So what conclusions can I draw from this. Well I think more investigation than one weekend will be required, but I suspect that unless you are speculating on significant increases in coin values, mining will not be a gold rush and difficult to even profit from. Even if you are speculating, you are better off buying the coins then mining them if my current experience holds. I plan to keep digging, but for now unless I’m actually working on the machine, I’m turning it off.
All in all, I do feel like this was a valuable investment for me because of the experience and what I have learned. As a rule, the first step of investing or entrepreneurship is understanding and I have made huge strides in this department. In the next segment, unless I have a mining Eureka moment, I am going to turn to looking at cryptocurrencies as an investment vehicle and other methods for investing in cryptocurrencies.
So after a bit of an adventurous first attempt at assembling my cryptorig, I was back at square one. What transpired over the weekend was very much a case of two steps forward, one step back. Reassembling the hardware, installing the operating system, installing the video drivers and lastly getting CudaMiner working. Rather than chronicling that arduous journey which involved numerous steps back, better would be to detail the successful path and point out the pitfalls that could be (and were) encountered along the way.
Ultimately I did get the hardware re-assembled as shown in the picture above. In this post I will detail the steps of installing Ubuntu and the Nvidia graphics drivers (and leave CudaMiner and mining itself for the next post).
The main steps that I would need to do to get Ubuntu loading successfully are:
Select a version of Ubuntu that works out of the box with CudaMinder (i.e. Ubuntu 12.04 LTS)
Set up UEFI bootloader
Using the nomodeset parameter to boot the Ubuntu USB Live stick
Install Ubuntu on the Harddisk
Install the Nvidia proprietary graphics card drivers
On to the details...
Selecting the right version of Ubuntu:
Originally I installed Ubuntu 13.10 but I would discover later that Ubuntu 13.10 has a version of GCC (Gnu Compiler Collection) that does not work with CudaMiner. To avoid a messy workaround (which I never succeed in getting working), I recommend using Ubuntu 12.04 LTS which comes with a compatible version of GCC (specifically 4.6 as opposed to 4.8 with Ubuntu 13.10). This step, which was actually the last problem I resolved, really is the first step someone reading this should make.
Setting Up UEFI (choosing between UEFI / BIOS):
Before installing Ubuntu, the first thing that is required is a decision to either use UEFI or BIOS for the firmware interface.
First it is pertinent to understand the difference between UEFI and BIOS. UEFI is a firmware interface (software) that is meant to replace the older BIOS firmware interface (software). Firmware interface software enables an operating system to interact with computer’s hardware. I highly recommend doing a quick read of the UEFI Wikipedia page, but it may be sufficient to understand that many motherboards today support UEFI but also have the capability of supporting BIOS via the Compatibility Support Module (CSM). You have to choose which you are going to use. I plan to just run Ubuntu on this machine, but if you are going to dual boot (or already have an OS installed) you have to have all operating systems using the same firmware interface (either UEFI or BIOS) or the machine will not see the other operating systems as it is looking for the bootloader in different places for the different firmware options (EFI System Partition for UEFI or Master Boot Record for BIOS).
UEFI has some benefits over BIOS including Secure Boot. Secure Boot allows only authorized programs to be loaded by the bootloader, thus preventing malicious software from hijacking the boot loader partition as can be done when using BIOS. A number of versions of Ubuntu after the LTS 12.04.2 including 13.10 are “recommended” to be authorized but in some cases motherboard manufacturers may not have followed the recommendation. In this case Secure Boot may need to be disabled. I leave Secure Boot in Windows EUFI mode.
For anyone attempting to run and install Ubuntu using UEFI, I recommend reading the following tutorial first: https://help.ubuntu.com/community/UEFI.
Here are two more potential pitfalls, as the tutorial mentions you may need to disable Quickboot/Fastboot and Intel Smart Response Technology. My machine worked without doing so. I set my boot device (the USB Live stick) to boot in UEFI mode and not legacy mode. I save and exit the Bios. Another pitfall, when creating your Ubuntu Live USB stick (this blog is for Ubuntu 13.10 but is the same using a 12.04 image instead), you need to ensure that there is a /EFI directory which will allow the Ubuntu installer to install into the EFI System Partition (as opposed to the MBR for BIOS)
Using nomodeset to Boot into Ubuntu
Based on that I am ready to go. Start the machine (with the Ubuntu 12.04 LTS Live USB stick plugged in). Grub loads up. I select Try Ubuntu without Installing. Appears to be loading for a bit and then shows some repeating error message about Nouveau (which turns out to be the open source graphic driver for Nvidia GPUs – the card I am using is not yet supported). More troubleshooting required.
Another pitfall. I notice that a message is flashing before Grub pops up: Could not open "\EFI\BOOT\fallback.efi": 14 It flashes on the screen for a tenth of a second, so I actually need to record it with my phone and then go frame by frame to figure out the message. Turns out to be a wild goose chase, the message does not have an effect apparently. More troubleshooting.
Finally, I find the tumbler for the last lock on the vault, namely nomodeset. I find an ubuntu forum post that mentions that most Nvidia GPUs require this setting otherwise Ubuntu will not completely load. When Grub loads, I select the “Try Ubuntu without installing” option and press the ‘e’ key. I manually add the nomodeset parameter (I put it between the quiet and splash parameters). Then I press F10 to boot Ubuntu. Success, Ubuntu loads!
Installing Ubuntu
In Ubuntu, I select the Install Ubuntu 12.04 LTS option. I use this blog as a guideline (the blog is for Ubuntu 13.10 but the options are pretty much the same). The key step is that the install detects that the harddrive is mounted on /dev/sdb and asks if I want to unmount to be able to create, delete or resize partitions. I select Yes. I select the option to Erase disk and install Ubuntu. The rest of install is straightforward although I choose the option to log in automatically. I reboot after the install and nouveau dies on attempted boot (nouveau is the open source driver for Nvidia cards), I need to use nomodeset until a working NVidia driver is installed.
Installing the Nvidia Driver
While I did not initially use the CudaMiner install guide wiki on github to walk me through the install of the Nvidia driver, it turns out it succinctly contains all the steps to install the driver. Note: It suggests installing Xubuntu 13.10 which may work without issue, but Ubuntu 13.10 will not compile CudaMiner as mentioned previously.
Basically you can follow this guide, step by step. I downloaded the NVIDIA-Linux-x86_64-334.21.run installer as I am running under 64 bit. Also it assumes some experience with Linux as you need change the permissions on the driver file to be able to run it. (i.e. go to the Downloads directory run the following command: chmod +x NVIDIA-Linux-x86_64-334.21.run” before the “sudo ./NVIDIA-Linux-x86_64-334.21.run” command (334.21 was the version available as of this writing)). The other piece it doesn’t really discuss is stepping through the actual driver install.
Basically when you go through the install you need to:
accept a license agreement
then ignore a message that the pre-install script failed
then choose the option to install without signing (signing might cause UEFI issues)
then install the 32 bit compatibility libraries
then select to install the libvdpau and libvdpau_trace libraries
and finally run the nvidia-xconfig utility and automatically update X configuration file so NVIDIA driver is used when we restart X. (and backup previous X config)
After this step, edit the /etc/modprobe.d/nvidia-graphics-drivers.conf as mentioned in the blog, reboot and you should reboot into Ubuntu (without needing nomodeset) with full screen resolution.
While I have already completed compiling CudaMiner, I only managed to get to the point where I ran CudaMiner with the benchmarking tool (average appears to be 240 k/h on immediate benchmark). I will elaborate more on the CudaMiner install along with the rest of steps to begin successfully mining in my next post.
This was a long post, and an even longer process. Definitely a case of two steps forward and one step back but that's always better than one step forward two steps back so I count myself fortunate to have the goalposts in sight.
Cryptomining: Close only counts in horseshoes and hand grenades…
So over the weekend, I took up the challenge of getting my cryptomining rig going. It has probably been almost 20 years since I actually assembled a desktop computer, so as I mentioned in the first segment of this series, it’s a bit of a case of back to the future.
Ok, on to the build...
Acquisition:
So I had already purchased last week all the componentry, with the exception of the “chassis”.
A quick trip to the grocery superstore, produced a bit to my surprise a really perfect solution – a solid wire basket and a package of cable ties (zip-straps / zip-ties). With that I had everything I needed for the rig, including the processor (CPU), motherboard, memory, graphics card (GPU), power supply unit (PSU), an external USB HD and the chassis.
With the exception of the HD, which is actually a Velocity enclosure containing a laptop HD from a laptop that no longer works, I purchased all of the items. (Note: I will provide a detailed list of all the components and costs in the next post)
This list of items is everything that is required by the machine which can run “headless” once operation begins. But of course to get the machine into mining operation requires additionally a keyboard, mouse, a USB stick (for installing the OS) and a monitor. I had all but the latter, but was able to get a monitor from a well-timed one day sale at Staples.
The overall cost for me was under $700 for the components I purchased (including the monitor) and you could easily get the items I already had for about $65 ($40 for the USB HD, $20 for a keyboard/mouse combo, and $5 for the USB stick). In fact, you could forgo the HD and just use a USB stick to run the OS if you choose to use Linux. I will use Linux but I actually want to use this machine for purposes other than mining occasionally so I’m initially going with the USB HD. I may still opt for a USB stick based OS if I want to optimize power efficiency in the future. For now my focus is just getting it running.
The Build Process:
So the first steps were actually taken by Memory Express. They conveniently offered to mount the RAM and CPU, which I readily accepted since I seem to be a static-y type of guy. I unpacked the motherboard and mounted it to the basket using the cable ties. I am surprised how heavy the CPU is, the weight of it actually causes a few of the cable ties to snap. But after a couple mishaps and doubling up on the side with the CPU, it is solidly in place. I brush away the tears of pride I have for the simple elegance of it.
Ok, next up, installing the graphics card. It’s not as heavy as the CPU is, but still heavy enough that I’m regretting a little that I did not put it in before mounting the motherboard with the cable ties. After some delicate prodding the card goes in. As I’m putting this together, I’m also downloading the latest 64 bit Ubuntu .iso which I will use as the OS.
As I’m unpacking the power supply, I suddenly have a thought. Without a true chassis, how the heck am I going to power the machine on? Internet to the rescue. Some motherboards have actual power switches, mine does not. More searching. It turns out you can short the pins that the power switch normally connects to using a screwdriver or other metal object. You are just completing the power circuit to send the power up signal just like the switch does. The theory is sound, but it feels a bit dodgy. Additional searching comes up with solutions that are not trivially expensive and may require a wait. Screwdriver it is.
I need to use the machine itself to install Ubuntu onto the external HD, but first I need to create an Ubuntu live USB stick. To do this I followed this blog.
Ok, with the installer ready, I’m set to power this sucker up. The eternal optimist, I plug in the keyboard, mouse, Ethernet cable, HDMI to the monitor, and the USB stick with the Ubuntu installer. I power up the monitor and it looks good. Screwdriver at the ready. Touch the power pins. Fans start to spin on the CPU and GPU. So far so good… or is it. Monitor light continues to flash like it has no signal. Uh oh. Wait a moment. No change. Hmm…
It is at this moment, I realize the second issue with my makeshift chassis. I have no PC speaker. If the motherboard wants to tell me something is wrong, I have no way of hearing it. A trip to the store is looking imminent, but I figure let’s read the troubleshooting manual for the motherboard for a lark. It has a nice little troubleshooting flow chart. I’m at the state where the fans are running (i.e. no power short, but the monitor is getting no signal), but I do the previous steps of ensuing all the cards are seated properly. The steps after the monitor step involve plugging in peripherals one at a time. I pull everything out except the monitor.
I reach for my screwdriver, but my 3 year old son who has been aching to be involved in some way with building this machine, sees the object of my desire and is faster to grab it than I. He loves tools. I remove the bit, which he takes offense to, so it is safe for him to handle, but I see that he will not give up the handle. After a brief consideration of using the bit without the plastic non-conducting handle, I hide the bit away. As I do, I notice my bike lock key. Plastic grip, metal head, perfect!
The key works like a charm, power on, monitor… A single message appears on the display.
“Please power down and connect the pcie power cables.”
Internet, your move.
Something wrong with the GPU, someone else had to return the board and get a replacement.
I’d like a second opinion please.
The Gigabyte GTX750 Ti requires the PCIe cable to be connected to the PSU.
Should have been obvious. I actually bought this card over other GTX750 cards because it has (what I thought was optional) a PCI-E power connector. All the other GTX750 cards do not have this extra connector as the power usage is sufficiently low that the power can be supplied by the PCI-E slot on the motherboard. I actually purchased the Gigabyte board as I thought the additional power may be useful when I got around to overclocking the card. Turns out it is not optional at all.
Power off. Pull the power plug. I locate a Type3 – PCIe cable from the mass of cabling provided with the PSU. Connect it up. Power plug in. Power switch on. Bike key switch on. A screen appears telling me that no bootable OS is found so it is going to the Bios Setup. Sounds good to me, I just need to click OK. Except the keyboard is not plugged in. I decide to go optimist again and I power down, plug in all the peripherals and bike key power up.
In the Bios, I do not see any need to adjust the boot loader (it should detect the USB stick Ubuntu installer as having a bootable OS). So the only change I make is in Power Management, where I change the power on option to have the machine immediately power up when AC power is detected to forego the need to use my bike key power up workaround.
Restart the machine. Ubuntu installer menu loads up. I am pleased. I have reached my comfort zone. My bliss will be short lived. I select the install Ubuntu option. It appears to be installing to the USB external drive. The Ubuntu installation status monitor is 5 dots that alternate from white to orange and back. After a period of time the status no longer moves and the HD appears to have no activity. After a considerable wait, I assume the install has gone into the Bermuda Triangle.
What would follow is around five hours of trying different suggested workarounds, all without success. The problem is that the motherboard has a known defect with the onboard network card not being detected properly in Linux, it ends up conflicting with the USB ports. I tried the bios changes and other options for which I had the necessary peripherals for, but ultimately I am left with a choice. Either I buy Windows, buy a DVD player to install Linux from a DVD, or a PCIe network card, or try to replace the motherboard all together. I opt for the latter as the other three options have no guarantee of success.
The motherboard that was failing was a Gigabyte 970a-D3P (which I highly suggest avoiding). So I headed over to Memory Express to have them replace the motherboard. After a headache filled process that requires me to leave and come back four times over 3 days I finally get my replacement motherboard, an Asus M5A97 R2.0 with the CPU and RAM mounted. Needless to say, I am less than enamored with Memory Express right now but this weekend I'll give it another go.
So now that I am basically back at square one, what can I say about my cryptomining odyssey so far. Well, first and foremost it makes me admire how persistent we were back in my University days when we spent days trying to get computers to work and never got discouraged. It was a challenge and that was half the fun. But I will say that I am grateful for the Internet today, because as a dad, spending countless days tinkering with hardware is just not in the cards.
Clearly this first horseshoe took a bad bounce and ended up pretty far from the post. Hopefully the next attempt will find the mark.
What possible connection could there be between the two... other than we'd all love to go back to 2009 and start mining, buying or somehow investing in Bitcoins, or even some of the more popular alt-coins.
In fact for me, it is about as close as I will get to being Michael J Fox going back in time, as I just bought all the components for a cryptocurrency mining rig.
Other than the occasional RAM upgrade, the last time I was putting together any computer from components was likely circa 1992, when I was regularly connecting serial cables together with friends, trying to get a playable 3-way multiplayer LAN session of Doom going.
On the weekend I plan to put together the rig (I hesitate to call it a desktop computer as it, like many of its brethren, will be mounted in a laundry basket, milk crate, or other yet to be divined air flow friendly container). The whole set of components to initially get started cost under $700, less than I paid for an 8 MB (yes that's Megabyte) memory module back in '92.
When figuring out how to get started, I used a number of excellent blog posts to determine HOW to build a mining rig, but what was invariably missing from all of them was WHY. If you are like me, I cannot simply take a list of ingredients and follow the recipe blindly, I need to understand the reason why we are doing this or that.
Why is understanding the WHY important? Well, in this case, I think the immediate opportunity to profit vastly via mining as an individual is already past (although a reasonable profit is not out of the question). But just like when websites started popping up around '92, it wasn't until 1998 to 2000 that domain names, dotcoms and other opportunities started to truly monetize the opportunity. But to capture that unknown opportunity one must understand the foundation it is build on, which means understanding as much about cryptocurrencies as possible, which includes practical experience.
As such I plan to blog over the coming weeks on the three current opportunity that I can see right now from which a person can profit from cryptocurrencies, which are:
Mining
Investing (directly and indirectly)
Entrepreneurship
I had initially pursued the investing angle first as it offered seemingly the least number of barriers to entry, I came to realize there are in fact some barriers. And while I did invest a bit, which I will talk about when I blog about the Investing opportunity, I decided to switch gears and focus on developing a deep understanding of the space, which starts with mining, with the ultimate goal of taking advantage of opportunities in the third realm of entrepreneurship.
I expect the next installment or two in this series of blog entry will be fairly technical in nature and likely focus on the hardware configuration (and later modding and overclocking), software configuration and utilizing the cryptocurrency services such as mining pools and cryptocurrency exchanges, after which I will turn to the investment and lastly the entrepreneurial opportunities.
I will mention that I have deliberately chosen to focus on the more generic opportunity around cryptocurrency as opposed to Bitcoin which is the current leader in the space. The reason for that is simple, the past few years have shown that often the first to forge in a revolutionary space is often the one that meets the most resistance from the established stakeholders in the space. (Think Napster, or even Palm, Netscape, RIMM, My Space). And there are a lot of big 800 pound Gorillas who are only now starting to take notice of Bitcoin (and its brethren), such as Paypal, Visa, Mastercard, the global banking institutions, and all of the federal banks and governments of the world.
While I do not believe these organizations really see Bitcoin as a threat yet, they are already starting to take actions in place to make it more challenging for Joe Public to enter the space, especially as enterprising individuals find ways to break down the challenges that exist for greater adoption of cryptocurrency. It does portend for an eventual conflict if growth continues, and Bitcoin might be the ultimate target (and scapegoat) for the majority of that conflict. I will definitely want to pursue this line of thought in a post as well.
I think that is a good initial chronicle of the beginning of my cryptocurrency journey for which the first stop is a Back to the Future moment for me. I'll continue the journey in my next post, but speaking of Back to the Future, apparently the fourth installment is in the works. If Hollywood can resurrect this classic franchise, then certainly I can go back to my roots of how I got into Information Technology putting together hardware computers.
About eight weeks ago, I had one of those spur of the moment revelations that you sometimes get when you are contemplating your place in some much larger system.
I managed to type out some rough notes so I would not forget, and its probably a good thing I did, because I got very busy and only now have the time to further investigate and elucidate the thought here.
In this case I was thinking about the IT industry and my place in it, when I came to revelation that their appears to be a major division occurring in IT, and that I needed (and you may also need) to decide just exactly which side I wanted to find myself on.
Before I do the big reveal about exactly what the divide is (or more correctly collection of divides), I think some context is in order. For those of you who have read some of my blog entries, you might know that I left IBM in March of this year. Since then I have been religiously re-educating myself, completing certifications such as PMP and TOGAF and learning about whatever IT topic happened to catch my eye, things like Github, Tumblr, Klout, Hootsuite, and many other new IT innovations. Most recently I started taking two intense computer science MOOCs (massively open online courses), EDX's CS169.1x and CS169.2x from University of Calfornia Berkeley.
It was these experiences, along with looking for my next job that indirectly resulted in the realization that there is a major divide in IT, which might loosely be called old school versus new school for lack of a better characterization. I would especially call out the EDX course for inspiring my realization.
On one side of the divide you have the old school companies, like IBM, Intel, Cisco, Yahoo, Oracle, and Microsoft. On the other you have companies like Google, Amazon, Facebook, Twitter, Tumblr, GitHub, Heroku, Flickr, and numerous other new age start ups. (Yes, I know Tumblr was bought out by Yahoo, but they say they will run it independently… we’ll see).
While most of the companies in the first group tend be older, more established and larger and the second group younger, more niche and smaller, Google and Amazon stick out as not exactly fitting the latter description. In fact, the divide is really about attitude, but the lines cross many areas of IT, forming a series of smaller divides that aggregate into a much larger overall divide.
Obviously there is more conversation on this topic than I can reasonably present in a single blog entry, so I plan to address in it parts. Additionally, much is based on my experience and opinion, and I have not done the requisite fact finding to call this blog post anything more than an opinion piece. Nor will companies strictly adhere to one side or the other, but if you work for one of these companies, you will probably relate to some of the examples I will present. Notably missing from the list of companies is Apple. It’s definitely one company that is trying to bridge the divide, but in my humble opinion, will end up straddling it more than bridging it.
One of the most notable examples of the divide is how companies on either side of the divide view (and treat) their employees. TOGAF, the Open Group’s enterprise architecture, has the concept of a capability, which it defines as the ability that an organization, system or person possess. To build a capability requires a mix of process, tools and people. This is one of the more dramatic divides, as the old school companies tend to focus their expenditures (in terms of effort and resource) on building processes and tools for competitive advantage. The benefit is that expenditure on the third parameter, people, can be ostensibly be contained. The new school, in contrast takes advantage of and even favors people to processes or tools, relying on talents of individuals working together in a employee-centric environment.
Obviously, the differences for employees between the environments can be significant. In the first group, an employee can routinely expect to be working under strict cost controls, high utilization requirements, significant travel requirements with limited opportunity for skill development, or wage increases. Employee turnover is generally high, but not just because the employees burn out, in fact it is required as these companies require an injection of new skills as they limit investment into internal skill development. Hence layoffs are a norm on this side of the divide.
The other side of the divide generally offers prospective employees more flexibility, focusing on results instead of specific hours spent working. Usually there will be many perks (which may offset lower initial pay) and a strong social aspect.
Of note, both environments often require the employee to put in long hours, although the motivations used to achieve this state may differ substantially.
Another divide is in the methodologies and tools used. The new school have embraced (true) agile methodologies, are using more recent tools such as Ruby on Rails, Github, and Basecamp and depend on more open collaborative technologies hosted on the cloud. Most noteably they are open to collaborating with other companies through open APIs to build integrated web applications. While this opens their intellectual property to being copied, they see integration as the only way to prevent obsolescence.
The old school on the other hand is entrenched with proprietary technologies based on mature methodologies. Although they try to present that they are using the new processes, such as agile, it is simply a facade. The actions emulate the new processes, but the underlying ideology as outlined in the Agile Manifesto is completely abandoned. Open source is only embraced when the company has a need which is not satisfied by its own proprietary offerings. In attempting to remain relevant and refresh its workforce skills, these companies acquire companies from the new school. Collaboration between companies is challenged, mistrust and litigation between companies is the norm. Stringent policy and bureaucracy is commonplace.
Clearly, you can see where I am headed here. But I would state that being an employee for the more established firms does have some benefits as one has opportunities to work with huge multinational enterprise clients and learn structure and methodology. Salary and benefits may be more clearly defined.
Another big difference is in monetizing. New school companies generally struggle to become profitable, as they are often are more worried about eyeballs, hits or making something cool than dollars. They spend lavishly, often relying that a new round of funding from angel investors, venture capitalists or an initial public offering will surely arrive. This does present a risk for the employee of one of these companies that runs out of time. The old school company is cash flow driven, the only goal being making sure revenues and profits meet expectations for each quarterly earnings. It results in a very narrow short term focus which can limit an employees opportunity for raises and promotions. As well it does usually mean limited education, training or even perks for the employee.
I recently joined a very small startup, so I find myself making the transition from one extreme of the divide to the other. Personally, I think this was the right choice for me, as I really want to be able to make a significant contribution to the success of a company, rather than being a small cog in a large machine. Obviously, in this role, my time to do entries on this blog are limited, but I plan to examine how Enterprise Architecture is impacted by the divide in my next entry. Until then, I would recommend to you that you take the time on a regular basis to examine your career plan.
Whatever side of the divide you find yourself on (or want to be on), I wish you all the best of luck in your careers, and do not forget to take time once in a while for introspection as you navigate a constantly changing IT landscape.
Open 2 Study: Introduction to Enterprise Architecture Course
So I recently took (and completed) the Introduction to Enterprise Architecture Course available as a MOOC (Massive Open Online Course) on the Open2Study web site.
The course, which is presented by Craig Martin from Enterprise Architects, is delivered over a four week period. Broken up into four modules, each with eight to ten topics, the course introduces Enterprise Architecture in some detail using TOGAF (The Open Group Architecture Framework) as its guide.
This course was my first experience in taking a MOOC, and I found it an effective medium for learning. Each topic is covered by a short five to ten minute video which is followed by a single question pop-quiz. Upon completing all the topics in a module, the student is asked to do an assessment of five multiple choice questions, with three attempts permitted. An overall score of 60% across the assessments is required to pass the course and receive an unofficial completion certificate.
There were many things I liked about the course. Foremost, Craig Martin is an excellent instructor who simplifies complex concepts, presenting them in a manner that makes them easy to understand. The format, in which Craig can diagram using neon markers on a transparent surface between him and the camera, is very effective. Additionally, the content itself covers a large percentage of the TOGAF specification, providing both clarification and examples.
But what I found most useful from the course (since I had already completed my TOGAF certification), was the detailing of the actual artifacts that are created as deliverables from the execution of the TOGAF ADM (Architecture Development Method). Many of those artifacts can be on the MOOC resources page on the Enterprise Architects site.
Also highly useful was Topic 5 in Module 4, which has a lot of excellent content on the differences between different types of architects and related roles within EA (Enterprise, Business, Information, Data, Technology (Infrastructure), and Solution architects as well as Business Analysts, System Admins, App Designers. and Architecture Managers.) This content is a gold mine for architects in planning their career development.
As well, I found many of the non-TOGAF extensions that are presented to be of use. Specifically, the realization iteration which discusses how implementation governance works with the implementation teams to actually realize the transition and ultimately the target architectures is a useful customization in my opinion.
There were some drawbacks though. Some of the questions (in both the pop quiz and assessments) were not directly covered in the video content and would like require you to read or have knowledge of the corresponding content in the TOGAF 9 guide. Additionally, not having homework assignments means that the knowledge gained is more oriented towards the passive theoretical space instead of the active application space. Obviously for a free course, this would be asking a lot to have practical application of the material implemented.
For people who are looking to certify in TOGAF, this course is an excellent starting place. I would recommend that it be watched early on in your studying efforts because while it gives excellent context and provides clarity on how all the concepts relate, it does deviate from the nomeclature and order of topics that the TOGAF 9 guide uses. Later study should concentrate on using the actual TOGAF 9 guide as the authoritative source for the exam.
Overall, the Introduction to Enterprise Architecture course is an excellent resource for learning enterprise architecture, and I would definitely recommend it to neophyte EAs, trained EAs and even experienced EAs as it can serve to bolster your EA knowledge and round out your EA understanding.
Book Review: Zoom Factor for the Enterprise Architect: How to Focus and Accelerate Your Career
A fellow group member on the "Togaf for Architecture" LinkedIn group suggested that I check out Zoom Factor to help guide my career transition into Enterprise Architecture.
After reading a couple of positive reviews I decided to purchase the book. For me, I consider a book useful or valuable if it does at least one of three things:
Provide a handful of "Of course" moments where it confirms something you subconsciously already knew, but now that it has been categorized can be referred to in the future.
Provide "Useful" intellectual capital that will save you time in the future. It could be a model, a pattern or some other technique that you can apply either today or refer to in the future.
Provide a "Eureka" moment of insight where it enlightens you to a new line of thinking or radically adjusts your view by uncovering a different perspective.
So how did Zoom Factor measure up?
Before I answer that, I would be remiss if I did not describe the book and its intended purpose first.
Zoom Factor for the Enterprise Architect is a 330 page paperback written by Sharon C. Evans and published in November, 2010. It is aimed at three different audiences: new or aspiring IT Architects and Enterprise Architects, IT Architecture Managers and Chief Architects, and Chief Information Officers. I fall in the first group, so this review will be most useful to those who are likewise entering the EA space.
The book is broken up into five sections that strive to assist the reader in achieving Enterprise Architectural Excellence, namely: Set your Foundation, Perfect the Process, Realize Your Soft Skills, Propel Your Perspective and Gain Altitude through Strategy. The idea being that by becoming an excellent architect your career will naturally follow suit.
While there was no "Eureka" moment for me, I did find a lot of "Of course" and many "Useful" moments. Each of the 21 chapters ends with a set of checklists that Zoom In and Zoom Out, providing both low and high level perspectives on each of the topics. While some of these felt contrived to fit the format, I will definitely refer to some of them when following an EA framework like TOGAF if for nothing else than to check for completeness of deliverables.
Additionally the checklists from chapter 1, the associated career roadmap on p.120 and the accompaniment that the author provides on her web site are simply excellent, no nonsense, guides to the skills and capabilities that one must build upon in the journey towards becoming an excellent Enterprise Architect. These assets clearly identify for a potential architect where their skills gaps lie and provide suggestions on how to address them.
Lastly, while the laundry list of skills, capabilities and knowledge that are identified seems extensive, the author does a good job of regularly reminding the reader that it is simply impossible to be an expert in everything and nor need you be. Additionally, chapter 20 on becoming a change master, highlights the critical challenge facing EA's and will truly help a person to decide if a career in Enterprise Architecture is the right choice.
While I did have a positive reaction to most of the book, I did find some of the sections somewhat verbose and could have been more concise, but then again having had a lot of exposure to project management and other soft skills, it may be that the more traditional IT architect would benefit from the additional hand holding.
The other concern I had, was that the author seemed to be somewhat critical of TOGAF, going so far as to state "... many feel this framework is better suited for solution architecture than for enterprise architecture ...".
She appeared to prefer Zachman or even just following a method that she outlines at a high level in the book. I suspect this is due to the heavy weight nature of TOGAF as a general framework, with the author stressing agility. Until I have spent some time learning the Zachman framework and experiencing an EA project first hand, I can not really judge if this is fair criticism or not.
Ultimately, I found the book to have some useful assets which can be used when following an EA framework, and the guidance around what skills are required will save any entrant into the EA field significant time. I know exactly what skills I need to work on and I've already started working on them. I would definitely recommend the book to anyone aspiring to become an Enterprise Architect.
My Motivation for Becoming an Enterprise Architect
So over the weekend I received an email on LinkedIn from someone who read a discussion I had started about Looking for an EA Mentor. The email author asked me to provide some details about the IBM EA course which I took and how it was the inspiration for me to start working towards a career in Enterprise Architecture.
So I took IBM's EA course last October. Since I left IBM 4 months ago, I no longer have access to the content, but that is probably for the best as it is a proprietary asset and even if I did not have a clause in my employment agreement barring me from discussing proprietary information I would still consider it unethical to discuss anything that was not publicly available.
When I came to the course, I knew very little about EA. I will confess that I mainly took it to take a break from a very challenging stressful project that I was on. Little did I know how great an impact it would have on me.
My first impression was... wow! here is a senior position that leverages technical knowledge but also delves into business strategy. Exactly what I was looking for!
Perhaps some context would help. Up to this point in my career I've been doing "blended roles" at IBM. 50% Solution Architect, 25% Project Manager, 15% Service Delivery Manager, etc. etc. The roles and the percentages might change, but I rarely had a dedicated role. Why? Well its simple. I enjoy understanding technology (in its many facets) and designing IT solutions but also enjoy being strategic, understanding business, and being involved in the big picture. So I was trying to wear multiple hats and do multiple roles, even if they had limited connections to each other. It was challenging to juggle everything. So Imagine my surprise (and joy) when I found that there was a single position that would marry the two areas together.
Over the four days of the course, I learned IBM's take on Enterprise Architecture, which was fairly similar to TOGAF 9, but with a consulting bias (which is not surprising as IBM uses its framework and method in EA consulting engagements). It had a similar cyclical image to describe its method and covered all of the same topics. One addition it makes to the business architecture domain is the use of the Component Business Model which IBM created (examples can be found using Google Images). IBM offers this course to both internal IBM employee and external participants.
Other than the first "Eureka" moment, the other things I gained from the course were the ability to apply EA in case studies and simply interact with the other students, most of which were not coming from an IT architect background (there were sales principles, project managers, business analysts, practice leads, and even a former CIO).
After the course, I went back to my application architect / development lead / project manager blended role, but the desire to do EA was still there. Fundamentally, I think the motivation for me to become an EA comes from the fact that I enjoy the two core aspects involved in what an EA does, which is aligning business strategy to Information Technology.
Okay, so now we know why I was initially motivated to learn more about EA. At this point, I feel compelled to say that while this is what motivated me, it likely is not the sole motivation for other IT Architects or IT practitioners to consider a career as an Enterprise Architect. Nor would I suggest that simply having interests in both business strategy and Information Technology as a guarantee that a career in EA is the correct fit for you, regardless of your IT background.
There are a lot of different characteristics and skills that an EA must have (or obtain) that go beyond capability in IT and business strategy. An EA also needs strongly developed soft skills such as leadership, communication, negotiation, decision-making, understanding politics, etc. A full investigation of all the skills that an EA needs in his toolkit would require a series of blog posts or even a book. So it should come as no surprise that an enterprising EA has already written such a book and somewhat coincidentally I just finished reading that same book.
The book is "Zoom Factor for the Enterprise Architect: How to Focus and Accelerate Your Career". As its title suggests, its goal is to help Enterprise Architects build their career. While I plan to review the book in detail in a post later this week, I will say that the first part of the book addresses the exact topic of this post, which is the motivation for becoming an EA and also what skills are needed to fulfill the role of an EA.
So back to the email that inspired this post. The email's author was interested in my motivation for becoming an EA, but I think its useful to generalize the question at this point, at least from an IT architect's perspective (which both me and the email's author come from).
What is the motivation for becoming an EA if you are currently an IT architect?
So we know my motivation is derived from an interest in IT and business strategy. Are there other interest based motivations? Probably, and those in my opinion would be other good reasons to entertain a career as an EA. But what about money, prestige, and career advancement?
If you did a quick search on EA on LinkedIn, you will quickly find many senior IT Solution architects calling themselves (incorrectly in my mind) Enterprise Architects. Creating enterprise-wide architecture solutions and doing enterprise architecture are related but different things. If you aspire to become a great architect, I think either path should be somewhat comparable in compensation (both monetary and seniority).
The difference between the two is pretty simple, the EA is more involved in the planning of architecture and the Solution Architect is more involved in the implementation of the architecture. One designs a plan for architecture, the other designs the architecture to be implemented. Obviously there is a fair amount of overlap between the two. Both would be core members of the Enterprise Architecture Board, one in a governance role and the other in representing the portfolio / program that is implementing the architecture.
I will paraphrase from the "Zoom Factor" book which provides a useful suggestion for an IT Architect trying to decide between those two roles. Would you, as an architect, prefer to spend more time working with stakeholders and business people or with developers. If the former, then EA is probably a good career choice. If the latter, then SA (solution architect) is probably the right choice. Even if you choose the solution architect option, there is no reason that you can not ascend to become the chief solution architect for a program or even an enterprise's entire IT portfolio. So I do not believe that career advancement (and its associated benefits) should be the sole reason for selecting EA as your career destination.
Okay. I think that provides some insight into the motivation for becoming an EA (versus other career choices) from the IT architect perspective. While I can not comment on the motivations of other IT practitioners entering the EA space, I would love to hear about them, either in the comments section or in the LinkedIn discussion that spawned this post. But if you are an IT architect who aspires to become an EA, as I mentioned in my last blog post, the first place to start is with a mentor.
Most people who work in Information Technology are familiar with some version Moore's Law, the simplified version of which states that processor speeds or overall processing power for computers will double every two years. Today a typical smartphone that you can hold in the palm of your hand can now out process the largest supercomputers from just thirty years ago. With such huge gains in processing has also come a massive explosion of data, information and knowledge in Information Technology. So much so, that when one ventures into a new area of IT, the task can seem Herculean in its magnitude and threaten to overwhelm even the most stalwart IT nomad.
So how does one overcome this obstacle. There may be many paths around your own particular obstacle, but why not take the one that has already been trail-blazed by someone else. That in a nutshell is the whole point of Mentoring, to learn from someone who has already been down that road so that you can avoid any pitfalls and reach your goal sooner and with less effort.
Since the dawn of time, knowledge has been passed down from generation to generation, father to son, mother to daughter, teacher to student and yes, mentor to mentee (protege). All of these are social development relationships, but what differs in the mentoring relationship is that the mentee drives the relationship, by determining its objectives and goals.
There are a whole host of benefits for the mentee such as:
Networking - leveraging the established relationships of the mentor
Direct and Indirect Learning - direct knowledge transfer and directing to relevant educational assets.
Career Advice and Planning - practical advice on what opportunities (both educational and vocational) should be pursued and a timeline for doing so
Feedback - getting expert commentary on actions taken or planned by the mentee from the mentor
But as well, there are benefits for the mentor such as:
Knowledge refreshment
Giveback to the profession
Feedback
So, how does one establish a mentoring relationship. There are a number of options:
Informal mentoring may occur between colleagues working in their day to day role.
More formally, many companies have specific programs to foster mentoring between employees.
When moving beyond the boundaries of the workplace, there are many mentoring web resources that strive to bring awareness to mentoring and help establish relationships.
Lastly, through social media groups, it has become much easier to establish relationships just by putting out a request for a mentor advertisement (or mentee for those wanting to mentor).
The key advice I have for anyone looking to become a mentee (or to mentor) is to be very clear in your advertisement what development help you are looking for (or can give). For example you may be looking for general career advice in a discipline, you may be attempting to pass a certification exam, you may be seeking to build your network. or you may want to directly gain skills or knowledge. Whatever the case, by clarifying your needs, you ensure that whomever answers your call will be more likely to satisfy your need and make the relationship a profitable one.
For me specifically, I recently took the large step of becoming an Enterprise Architect. My first step was to look for mentoring. I put out a request for mentoring on LinkedIn and received a number of positive responses. With an area as broad as enterprise architecture, having multiple mentoring relationships was beneficial as each mentor was able to provide different viewpoints and provide valuable advice leveraging their area of expertise. In many cases, when making a significant foray into a new discipline, you may need multiple mentors to fulfill multiple needs.
Some might disagree with me, but when it comes to mentoring, there need not be hard and fast rules. The relationship can range from informal (getting together to chat with no set agenda) to formal (documenting goals and measuring progress towards them), it can be regimented (meeting every X days) or adhoc (when needed), it can be in person or remote (by phone, video conference or even via chat), and it can be established by either party. But ultimately the goal is development of the mentee and as such for most professional mentoring relationships, the mentee must decide what the desired outcome(s) of the relationship should be.
Just a few days ago I received confirmation that I was approved for membership in the Center for the Advancement of the Enterprise Architecture Profession (CAEAP). Along with the confirmation was an invitation to participate in a variety of different volunteering opportunities. I readily responded back that I was eager to help in whatever way I could.
In my opinion, volunteering should be a key building block in any IT practitioner's toolkit, regardless of whether they want to become an enterprise architect, a developer, a project manager or a Chief Information Officer.
Recently I have seen numerous articles on LinkedIn regarding the need for those searching for work (and even those currently employed) to be cultivating their social media brands and expanding their professional networks. Many articles suggest that IT professionals need to have blogs, examples of their work available for review on portals such as GitHub, and be leveraging online networking contacts for referrals as the traditional job posting / resume / interview process was destined for the dustbin.
While these may be valid methods of advancing one's career, I have noticed that two key methods, volunteering and mentoring, are noticeably absent. Perhaps its because they are traditional (and thus out of favour), or because it takes a larger commitment. Whatever the reason, while they may not directly contribute to advancing a career (i.e getting a job), they do provide mechanisms for building fundamental skills in your chosen career field, which is ultimately is required to successfully launch a career or take that next big step.
Volunteering and mentoring (which I plan to discuss in a future post) have been for me two of the four cornerstones of career development (the other two being on-the-job experience and education / training). Not only does volunteering help develop new skills, it also has the benefit of indirectly building a professional network and also giving back to your profession.
I can not emphasize enough the importance of giving back enough.
The reality is that in my career and yours, many colleagues and like-mind professionals have taken time to help us (formally and informally), and as a beneficiary of that help, it is imperative that we continue that tradition, to help others as they strive to develop their careers.
I am really looking forward to having the opportunity to volunteer with the CAEAP. When I do hear back from them, I'll detail in a future post what my involvement will be.
I was recently directed to the CAEAP (Center for the Advancement of the Enterprise Architecture Profession) web site by a fellow group member on the TOGAF for Architecture group on LinkedIn.
It is a fantastic site for up and coming enterprise architects. The CAEAP has a number of goals including the advocacy of enterprise architecture and also the promotion of ethics within the enterprise architecture discipline. To join as a volunteer member of CAEAP you need to sign the Enterprise Architect Professional Oath and also sign the Enterprise Architect Professional Doctrine.
Not only does it provide ethical guidelines to follow as a member of the enterprise architect community, but also advocates mentoring and other forms of professional giveback which I wholeheartedly endorse. Some of the benefits to be reaped include the aforementioned mentoring, as well as volunteering experience opportunities and networking.
I highly recommend checking out the CAEAP web site (and becoming a member). I just joined as a member, and as I learn more about the CAEAP, I will discuss it in future blogs.
So in my last blog entry, I detailed the general method I use when studying for an exam. This entry takes the next step and shows how I tailored my method specifically for The Open Group Architecture Framework (TOGAF) 9 certification exam.
The combined TOGAF 9 test is comprised of two parts.
Part 1 is a 60 minute 40 question multiple choice test. This part is meant to test your knowledge of the vocabulary, the organization of the TOGAF 9 guide and fundamental concepts. You need to achieve a score of 22 to pass this part.
Part 2 is a 90 minute 8 question complex multiple choice test. In this part, you need to read a case study and choose the most appropriate answer to the question. The answers are graded as 5 points for the best answer per TOGAF, 3 points for the second best answer, 1 point for the third best and 0 points for the incorrect "distractor" answer. This test is open text, so you can refer to the TOGAF 9.1 guide during the exam. This part tests your abilities to apply TOGAF to a business case. You need to achieve a score of 24 to pass this part.
First off, I would recommend having a mentor that has taken the exam. I plan to discuss the overall value of mentoring in moving your career forward in a future post, but for now I can simply say that a mentor can provide valuable guidance and tips both on taking the exam and applying the material after you certify.
Here is the tailored method I recommend for the combined two part TOGAF 9 exam:
Take a baseline sample exam.
Read the Open Group Introduction to TOGAF 9 PDF
Watched the Knotion TOGAF overview series videos
Read the TOGAF 9.1 Pocket Guide
Take another sample exam
Read Nik Ansell's TOGAF study guide.
Read the full TOGAF 9.1 Guide
Take sample exams, review the areas of difficulty (incorrect questions and questions where you are unsure)
Take more sample exams until you are scoring 80% on both parts of the exam.
Schedule the exam
Continue to review the TOGAF 9 guide and do sample questions until you take the exam.
Details:
The first issue you will have with this tailored method is the availability of sample questions (especially free sample questions). The Open Group web site provides a single sample exam for each part. It is the best approximation of the exam. I recommend using it for your baseline and then repeating this exam (both parts) directly after reading the full guide.
After the official sample exams, the next best free resource was Manuel Di Toma's theopenarch.com web site, which provides three sample exams for the first part and two sample exams for the second part. As a third party resource, it is not sanctioned by the Open Group (it's unofficial), but I found the exams for the first part to be fairly indicative of the type and difficulty found on the actual exam. For the second part, I found that the answers were too similar (often differing by a single line or two). The Open Group's official sample exam is more indicative, but it is still a reasonably useful resource.
In getting an introduction to TOGAF, the introductory PDF gave a good executive overview and the Knotion TOGAF videos (a set of ten 10 minute youtube videos) were an excellent way of understanding the relationships between the different components of TOGAF. (I would just note that the videos are for TOGAF 9, not 9.1 but at a high level the concepts are nearly unchanged and the exam will not test areas that were modified from 9 to 9.1)
The Pocket Guide also served to give a more detailed overview of TOGAF. But it is important to remember that especially for the Part 1 exam, some times the questions use the exact wording from the full TOGAF 9 guide and as such it needs to be considered the only authoritative source. I also suggest reading Nik Ansell's TOGAF Exam Study Guide, it is excellent at highlighting areas to focus on.
After reading the full TOGAF guide, you need to continue doing sample tests (other free and paid tests are available, or you can repeat the tests). The key is to identify areas of difficulty and resolve them by referring to the TOGAF guide. This will also help in the second part of the exam, which is an open text exam.
When taking sample exams for Part 2 of the test, I highly recommend quickly referring to appropriate section. When I took the exam, I had time to read the case, read the answers, refer the appropriate section in the TOGAF guide and select my answer in roughly ten minutes for each question. This left me ten minutes to review my answers at the end of the test. It is simply not possible to remember all the details of architectural artifacts and inputs, outputs, approaches and steps of ADM phases so your focus should be on knowing the guide well enough to be able to identify correctly what part of the guide the question is asking about and then applying it to question correctly.
As I used this method, I first started with baseline scores of 22 and 26 (which is a pass, barely). After reading the pocket guide, I improved to scores of 27 and 26 on a new set of sample exams (obviously my score in the second part did not improve, but that's not too surprising given that I had not read the full guide).
After completing the guide I still struggled to score above my 80% comfort level, simply because there is so much detail and with much of it being similarly named, it was easy to confuse one concept with another. But in time, after skimming the guide a second time, it all started to come together and I actually feel like I really understand the material (and am excited to apply it).
When I finally took the exam I scored 36 and 40 respectively, for an overall score of 95% and 100% on the second part.
Now obviously, with my current situation of being between jobs, I was able to dedicate significant effort to my preparations for the exam. This may not be possible for you, but as I mentioned in my previous post, you can tailor your approach to meet your own circumstances and goals.
I wish you the best of luck on your exam, but if you follow this approach I believe you will pass even if your fortunes abandon you.
Since leaving my job in March, I actually have completed two certifications, first the PMI's PMP (Project Management Institute's Project Management Professional) certification and most recently the Open Group's TOGAF 9.1 (The Open Group Architecture Framework) certification.
For both certification exams, I used my own personal study method with which I have had good success with and will share with you.
My generic study method is as follows:
Baseline test
Read an introductory synopsis or executive summary
Do a different sample test
Read the text(s) for the subject of study
More sample tests, review questions that you have difficulty with
High level review of text(s), focusing on areas of weakness
More sample testing until scoring 80% or higher on 3 consecutive
Schedule the certification exam
Re-review text(s) at a high level.
Keep the material fresh by regularly attempting sample questions
Ace the exam.
What? Is he crazy? Patience grasshopper, all will be explained.
As a good Enterprise Architect (or PM for that matter) might do, I had to tailor the method for the task at hand, and in a subsequent blog post I'll provide the tailored methods I used for each, along with tips and guidelines.
But first I'll explain the method to my madness, starting with the first step, taking a baseline test. Again, like a good EA or PM, to get to the finish line, you first need to find the starting line, and the starting line is a baseline.
So the first thing I do when I take an exam is find out exactly how far I am away from the goal (which for me is not just passing, but getting a score I can be proud of), so the starting point is taking a sample test to baseline what I would score armed with the IT knowledge and common sense I have accumulated so far. I'll save the details for the blogs but suffice it to say, I had a ways to go for both the PMP and TOGAF exams.
Once you've got a baseline (and a good idea of how far you have to go), you can start learning the material, which for me starts with understanding the concept. There are a number of ways of doing this, taking an introductory (or indepth) course, watching an online webcast or video, or reading a brief or executive summary or other short document.
After that I again test myself to see if any improvement is made. Generally there should be a discernible improvement, since testing often focuses on the core concepts which would be discussed in some detail even in an introductory offering. Note: So far I am not concerning myself with understanding any errors or difficulties I have had answering questions so far.
At this point, you should have a good idea of exactly how much effort needs to be invested in reading the subject material in detail. As well, you should have a good idea of the types of questions that will be asked (be aware of the difference between officially sanctioned sample tests/questions and third party questions. I'll discuss those in detail in the specific blog entries for exams I have taken).
Now I would begin reading the subject text(s). Some people just approach studying by memorizing content so they can pass the exam. Personally, I can not understand nor recommend this approach. This is not high school. If you do not actually learn the material, you are just doing yourself a disservice, in my opinion. This step if done properly will take up the majority of the time preparing for the exam.
Once you have read the full subject text, you begin to practice applying your knowledge. The focus for the next steps is doing sample questions, and resolving areas of difficulty. Notice I didn't say resolving errors, because often you may answer correctly but are not completely sure and a differently worded question might trip you up.
I usually continue to answer questions, and review sections of the text until I complete 3 sample tests with scores of 80% or better, at which point I schedule my exam (Note: For Prometric exams, definitely ensure that your locale has regular testing, otherwise you may need to estimate when you will achieve regular success to avoid a long delay in taking the exam). If you are achieving 80% you can feel confident that you will be successful even if your neighbor's dog keeps you up all night before your exam.
So that's what works for me. Depending on your personality, you may need to tweak it. In my upcoming posts I'll detail my tailored methods for both the TOGAF 9 and PMP exams, and after that I'll get to the topic I really want to talk about, which is my current steps towards becoming an Enterprise Architect.
Every journey has a start, a point of departure, often humble in its beginnings, filled with hope of finding quality on the road ahead.
But why should you choose to travel with me?
Good question. Perhaps one of these might be the source of your motivation:
Perhaps you are on a similar journey, and hear of the roadblocks that I encounter, so you can avoid them in your travels.
Perhaps you can find solace in sharing similar defeats, and likewise rejoice in recalling comparable victories.
Perhaps I amuse you.
But I digress. So onward with the journey.
Of course every journey actually begins before the first step is taken, by understanding the nomad themselves, which you can do by checking out my bio which will provide you with context (which is always of importance to an IT practitioner).
My awakened journey began only a few months ago, when I decided to leave my post at Big Blue (aka IBM) after a fifteen year sojourn. (Some might argue the use of sojourn here, but you will just have to trust me that it is apropos).
Already steps have been taken, and I believe that archiving them will not only serve me, but also benefit other nomads in traversing both the digital and corporeal worlds around us.
So onto those first steps, starting with obtaining my TOGAF 9 certification.
