Do you need an IT Certification?

A couple of times in recent days I had the discussion of Certifications with two friends, once with Shawn Zandi, who is the Principal Network Architect at LinkedIn and another time with Hosein Khosravi who is a successful instructor and engineer!
I thought that it might be a good idea to blog on this topic with my own words and the conclusion of my own experience till now.

Disclaimer: I’m neither against nor with certifications. I’m not telling you to be certified or not; I’m not devaluing people who have made legit efforts to get certified and totally respect them and their achievement.
I’m just looking at it from my own perspective.

You can find lots of posts on this topic in the Internet from all the experts. Usually you’ll find two types of answers; the “marketing” and the honest ones!

You can detect the marketing persuasion by phrases like:

  • You have to be certified to be hired!
  • You have to be certified as an indication of your knowledge and expertise!
  • This certification guarantees your job!
  • This is the most valuable certification on the market!
  • Your earnings will boom!
  • Holders of this certification get paid the most!

Well, they could be true, but only to some extent; but I believe less than 10% of the time! I’m not saying neither certification is bad nor it is good. Let me dig deeper into it.

Basically, achieving a certification means that you have put enough efforts and dedication to pass an exam. That’s great, congratulations!
Similarly, earning a University mainly means that you have been a good learner.

First, I’ve to admit that sticking to a plan for a certification could bring dedication into your studies. Personally, I’ve also many times started to gain knowledge about a concept by following a certification path;  but that should never be an end and boundary to grasp a technology!

Have in mind that the reality is usually different from exams.

Exams usually teach you the techniques but not the tactics. You’ve to be prepared for the complexities and harsh situations; you’ve to be able to manage your time, keep pace with new technologies, use them to make your work more efficient and play a part in connecting people and services!
Besides, You should be able to network with people and learn how to discuss your ideas and present yourself.

Be curious and find the original idea behind a thing; i.e. was there a problem out there that made engineers to create that protocol? Did it solve their issue?

Imagine yourself in different situations and scenarios; then challenge your creativity to propose something. This is a best practice!

Read the standards and scrutinize the concepts in detail; google and read what others say about the concept; think out of the box and try to figure out other possibilities; dig the RFCs deep and even maybe you can contribute to one!

Again, studying and learning is always good, whatever the reason is. Just you should be cautious of not getting bound to a vendor. Get to know what’s going on around, know the market and today’s business need; read, read and read and make some educated guesses for the future! Have in mind that the half-life of IT skills is less than 2 years. You should be fast otherwise you’ll be left behind.

So, I believe the honest and truthful answer is that, you have to earn the knowledge by dedication, hard work, experience, curiosity and creativity. A vendor’s certification can’t be a good measure of someone’s knowledge in the IT era today; you’re not bound to vendors anymore; at the end of the day we’re going to live in the IoT and SDN world. (Yeah, they’re the new fancy words)

You should add value to the certificate; not the certificate to you!

If you’re confident of having the knowledge, and you’re able to discuss and demonstrate your skills, then you’re at it! Don’t panic and let your expertise talk for itself.

A good approach could be to become certified when it’s needed; yes, sometimes vendor partners need certified people for specific projects to get discounts and support contracts; I call it a practical approach. This brings a win-win result. You get the knowledge, certification, and money.

It’s not a vendor to approve If you’re an engineer, architect, consultant, etc.; it’s you and your knowledge!

From all the articles out there, Russ White has done a great job writing on this and related topics; I totally recommend reading the posts below:

Share this!

Seriously, what is Big Data?

Big Data Defined

The easiest answer: Big Data is your data, structured and unstructured.

There’s nothing new about the notion of big data, which has been around since at least 2001. It’s the information owned by your company, obtained and processed through new techniques to produce value in the best way possible. Big data may be as important to business – and society – as the Internet has become. Why? More data may lead to more accurate analyses.

Ask any Big Data expert to define the subject and they’ll quite likely start talking about “The three V‘s”. As far back as 2001, industry analyst Doug Laney (currently with Gartner) articulated the now mainstream definition of big data as below:

  • Volume. Many factors contribute to the increase in data volume. Transaction-based data stored through the years. Unstructured data streaming in from social media. Increasing amounts of sensor and machine-to-machine data being collected. In the past, excessive data volume was a storage issue. But with decreasing storage costs, other issues emerge, including how to determine relevance within large data volumes and how to use analytics to create value from relevant data.
  • Velocity. Data is streaming in at unprecedented speed and must be dealt with in a timely manner. RFID tags, sensors and smart metering are driving the need to deal with torrents of data in near-real time. Reacting quickly enough to deal with data velocity is a challenge for most organizations.
  • Variety. Data today comes in all types of formats. Structured, numeric data in traditional databases. Information created from line-of-business applications. Unstructured text documents, email, video, audio, stock ticker data and financial transactions. Managing, merging and governing different varieties of data is something many organizations still grapple with.

Continue reading “Seriously, what is Big Data?”

Share this!

Rules of Networking

I have to admit that I’m obsessed with RFC1925 and do my best to apply it to all aspects of my work.

Just as a note to self, I post the Twelve Networking Truths here, and hopefully add more relevant ideas I find in the course of time.

  1. It Has To Work.
  2. No matter how hard you push and no matter what the priority, you can’t increase the speed of light.
    1. (corollary). No matter how hard you try, you can’t make a baby in much less than 9 months. Trying to speed this up *might* make it slower, but it won’t make it happen any quicker.
  3. With sufficient thrust, pigs fly just fine. However, this is not necessarily a good idea. It is hard to be sure where they are going to land, and it could be dangerous sitting under them as they fly overhead.
  4. Some things in life can never be fully appreciated nor understood unless experienced firsthand. Some things in networking can never be fully understood by someone who neither builds commercial networking equipment nor runs an operational network.
  5. It is always possible to aglutenate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea.
  6. It is easier to move a problem around (for example, by moving the problem to a different part of the overall network architecture) than it is to solve it.
    1. (corollary). It is always possible to add another level of indirection.
  7. It is always something
    1. (corollary). Good, Fast, Cheap: Pick any two (you can’t have all three).
  8. It is more complicated than you think.
  9. For all resources, whatever it is, you need more.
    1. (corollary) Every networking problem always takes longer to solve than it seems like it should.
  10. One size never fits all.
  11. Every old idea will be proposed again with a different name and a different presentation, regardless of whether it works.
    1. (corollary). See rule 6a.
  12. In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away.
Share this!

Overview of ISMS

This post is my snippet of Wikipedia article about ISMS.

The governing principle behind an ISMS is that an organization should design, implement and maintain a coherent set of policies, processes and systems to manage risks to its information assets, thus ensuring acceptable levels of information security risk.

PDCA (ISO/IEC 27001:2005):
  • The Plan phase is about designing the ISMS, assessing information security risks and selecting appropriate controls.
  • The Do phase involves implementing and operating the controls.
  • The Check phase objective is to review and evaluate the performance (efficiency and effectiveness) of the ISMS.
  • In the Act phase, changes are made where necessary to bring the ISMS back to peak performance.

Continue reading “Overview of ISMS”

Share this!