Get Top Architecture Courses at Great Price

Me2Hi there. Wanted to make a post today about my Udemy courses, and how you are able to get them at a discount using the links below.

I really appreciate all of my students, and I have created these courses to help pass these architecture exams. I am constantly improving them, and so they’ll never be out of date to the specific exam that they teach.

“Excellent content that covers the organization of TOGAF very well. Scott’s insights into the exam have been invaluable!” – Vinoo Palayoor

TOGAF1

TOGAF2


“I really appreciated the content and how the whole lectures and material is organized, the small quizzes and the outside material hyperlinks. Really helpful !” – Jean-Francois Pezet

TOGAF Part 1 Arabic

Azure 70-534


I have over 21,000 students in my architecture courses, and I look forward to having you as a student.

Scott

What is Windows Azure Active Directory? | Channel 9

Windows Azure Active Directory is described in cartoon format in this video. It’s an easy to follow sketch of all the major pieces and how you can use it. It also describes the differences between Windows Azure Active Directory and Windows Server Active Directory.

Source: What is Windows Azure Active Directory? | Windows Azure Active Directory | Channel 9

The Open Group Changes Testing Centers

The Open Group recently announced that they are switching from Prometric to Pearson VUE. For now, the TOGAF 9.1 exam is available at both testing centers (and in many cases, the same testing center supports both testing companies).  But at some point in the future, the exams will only be available through Pearson.

The Open Group selects Pearson VUE for global computer-based IT certification testing programme delivery

Source: The Open Group :: Pearson VUE

Top Challenges of Enterprise, Software and Solution Architects

A week or so ago, I ran a survey of the students in my architecture courses, asking them what their biggest challenges were.

In this post, we’ll look at the top 5 answers, from real working architects and senior application developers like you:

1. Dealing with Legacy Systems

Without a doubt, as we get into the 40th year of having enterprise-level software systems, we’re all feeling a bit burdened by some of these pain-in-the-neck (and difficult to replace) systems.

In fact, as I look back on the last 10 years of my career, I can’t really think of a project that wasn’t something like these:

  • a system where the original developer is gone, and no one fully understands the system
  • a system where, for whatever reason, no one wanted to have to touch if at all possible
  • a system that has been “planning to be replaced” for several years, with no concrete schedule as to when
  • a system where the original vendor doesn’t even support it any more (or indeed talk about it on their website)

If I had a magic wand, and could update to the latest version, or replace it with something more modern instantly, for sure that magic wand would be used a lot. Unfortunately, company’s sometimes prioritize certain things very low on the list, and we have to deal with them.

2. Explaining the Value of Architecture to Non-Architects

Oh man. What is architecture? What IS it? What do architects DO?

This question has been haunting people in the architecture space for ages. I even made not one, but two videos about it. (Please check those out, and subscribe!)

The thing to remember is, every system has an architecture. Whether an architect was involved or not, one or more people made some decisions on systems design that add together to become the system architecture. But would you rather have something that is designed intentionally, or something that just comes together without forethought?

If I offered you a house, and said that I built it one room at a time without thinking about any of the other rooms, does that sound like a well-designed house? Then why can computer systems (and ultimately the businesses that run on top of them) be designed only one room at a time and expect the whole house to make sense?

(Why are there 3 bathrooms in the basement and none upstairs by the bedrooms? Because there was no architect.)

3. Dealing with Application and Data Security

In 2016, security is a huge issue that anyone in technology has to deal with. Not only is it smart business policy to protect your customers data from being exposed, but it’s actually the law in many places that this data has to be responsibly protected. As architects, we need to be on top of the standards for security and ensure that our designs have thought about that before code has been written or systems set up.

Easier said than done, of course.

But from the way customer data is kept, to the way our networks are hardened from attack, to the limitations we place on users from outside (including the website user itself which will minimize the effects of a web-facing break in) are more important than ever, and will never be something we can take for granted.

4. Dealing with integration with other systems

Legacy systems were a big headache, but even interacting with non-legacy systems can be complex. How do you package and send GBs of sensitive data from one server to another when the other system only accepts XML files in a specific file directory as input? Sometimes you end up with middle-tier “connector” systems that just move files around, and sometimes you need to use third-party solutions like Microsoft SQL Server Integration Services (SSIS) or Microsoft BizTalk to pass and manipulate data around.

The ideal solution is for two systems to be designed to talk to each other, or use some industry standard protocol (an Industry Architecture on the Enterprise Continuum!) so that related systems can just work to implement a standard instead of worrying about direct integration with so many varying systems. But those standards are often overly complex (due to the number of irrelevant-to-you scenarios they have to deal with) or don’t exist for your specific need.

5. Feeling locked in with a single vendor, such that parts of the architecture cannot be changed

We’ve all been there. Your company has been using “Tool X” for analytics and reporting so long that the code is everywhere. In every web page, of every website. Highly customized for button clicks, opt-ins, video plays, and all sorts of events. And implemented slightly differently in every site it’s been added to. When asked, you estimate 12 person-months to swap out the “Tool X” code and replace it with another solution to the same level of customization for pages and events.

Sometimes you’re stuck. The cost to replace something doesn’t give the business the necessary return on investment to spend that money. And so you go year after year, with a tool that no-one really likes, paying more for it than you probably should, because it’s tool difficult to replace.

There’s no easy solution to that, except to vow that the next time you’re asked to implement some custom third-party code in all your web pages, you devise a system that puts that code in one central location. You need to abstract that and centralize it, so that it’s easy to upgrade to the newest version or swap out to a new vendor.

Those were the top 5 issues identified by my students. Anything that I missed?

 

Using Baby Steps To Climb Mount TOGAF

A few years ago, in the place I used to work, the company used to go out for drinks after work on Thursdays. One Thursday we were out, and a friend of mine said he was interested in learning TOGAF.

TOGAF? What’s that?“, I replied.

And that’s how it started for me. When I went home, I did some research. TOGAF was a certification for architects. I was immediately excited by the idea of being certified for being an architect, as the idea that you could had not even crossed my mind before then. I’ve taken several certifications in the past – Microsoft Developer, Sun Java (back when there was a Sun Microsystems), and others. Being certified for TOGAF actually sounded like a great opportunity to learn, and a good career move. So I set it as a goal.

Opening the specification for the first time was a bit intimidating. The TOGAF 9.1 spec does not do a great job telling you what it is and introducing people to the subject of enterprise architecture. It just starts, and each paragraph is sometimes vague and unclear. It was not going to be easy.

And maybe, quite possibly, this is where you are. You see this subject, it looks interesting, something you think will help you do your job and open new opportunities in the future. You’ve bought my course (or haven’t) but what now? How do you go from where you are to where you want to be?

I’ve found in my life that you need to take things slowly sometimes. You cannot climb Mount Everest in a single day. You climb a big mountain by going from one base camp to the next, and take some time to rest and get acclimated at each stop. It actually usually takes around TWO MONTHS to climb Everest (normally arriving in March, and reaching the summit in May). Maybe you can climb Mount TOGAF in under two months, but you need to understand when you start that it’s not an overnight thing, or something that can be conquered in one week. Setting expectations is important.

So how do you reach the top of Mount TOGAF if you are currently standing at the very bottom?

For me, it was doing a little bit of studying each day. If you set aside even 30 minutes or 1 hour per day to understand a little bit more about TOGAF, you will have made a little progress towards your goal. Set a plan. And stick to it no matter what.

Do you understand what the TOGAF definition of enterprise is? Good. Do you understand what the TOGAF definition of architecture is? Good. Do you understand the objectives of the Preliminary Phase of the ADM? Good. Just keep making a little progress each day. Only one lightbulb needs to go off for a study session to be productive. Just do a little bit each day, and after a week you will be a few meters up the mountain. And after two weeks, you might be half-way up the mountain.

The worst thing you can do is put it off. Someday. If you go significant periods without looking at it, you might as well not do it. You can’t climb Mount TOGAF by only climbing once every two weeks. You need daily progress. And if you must miss a day, get back to it immediately the next day.

If you want to get the occasional email from me about TOGAF and architecture topics, I invite you to join my mailing list. You’ll get a special study guide containing the key TOGAF definitions free just for signing up.