My previous post was about how to be or become an IdM Architect and what I feel are the items to look for in a top architect. The first item in the list is: They must know the Identity Management software that you are working with. All of it. Inside and out.
There is no exception to this rule. If you don’t know all the little intricacies of the main components you will be working with, you will not be able to successfully architect a clean and efficient environment.
A lot of people in this industry that consider themselves architects, have learned the software from a top-down approach. Meaning, they first start with the documentation and learn what the software does and how it does it. I like to equate this with the word “Theory”.
If you’ve read everything published by the vendor on a certain piece of IdM software, you will have a great understanding of how to implement it…in theory. In reality, you still have no idea what you’re doing. This level of knowledge is one step higher than a sales guy’s understanding.
These architects will then suggest and implement what they think will work best based on what the vendor docs say is best practices. What happens is that it will all fall apart pretty much instantly. Or even pre-instantly. Yep, I just made up a word =)
Pre-Instantly = Before you even get to installing anything.
Example: Architect says to install the provisioning piece and the web server on the same instance to save footprint (actual hardware usage) and consolidate. In reality, these two pieces conflict over port usage, and certificate management. So, before the engineers even install anything, they come to you and point out that it wont work. Now you need to put one of the pieces somewhere else. This is a big change and will require a rework of your architecture.
To become proficient in your software knowledge, you need to learn from the bottom-up. You need to install the software. A lot. Configure it all kinds of ways to see what happens, what works, and what doesn’t. Break it… a lot. Then fix it. That’s how you’ll learn the full capabilities of what you’re working with.
Once you have mastered one piece of software, you need to work on the integration between it and others. Learn how they work. What is involved network wise? What libraries are required to install it? What versions of OS are supported? Can they both run on the same server? Try it out, see what happens. What are the benefits of consolidating and what are the disadvantages. These are all items that need to be weighed when developing an architecture. Some clients prefer beefier servers with a smaller footprint, so they’ll want to run more services on less servers. You need to know how to design for that need. Some clients prefer to have more hardware for ease of fail-over / disaster recovery. You need to know how to design for that. And the latest in the enterprise buzz-word filled world, how to design for “the cloud”. Going virtual. You need to know how to design for that.
No one architecture will fit every clients needs, so it’s imperative that you know how you can consolidate and spread apart all the software you’re working with to fit your clients needs. Another point is with support from the vendor. Even though the software and configuration works with your design and it may seem the best to everyone, the vendor may not support it (especially in the virtual space) and that right there will cancel it for a lot of clients. Learn your vendors support models. You don’t want to spend weeks designing something that the vendor won’t support.
This last point should be obvious, but I’ll state it anyway. You need to know as many IdM software pieces as possible! Not just the provisioning piece for one vendor. You need to know the provisioning piece, the access management piece, the federation piece, the SSO piece, the directory piece, the virtualization piece, and all other related pieces for ALL MAJOR VENDORS! Really? All of ’em? Yes! If a client is running IBM’s Tivoli Access Manager, but is using Microsoft’s Active Directory and you’re hired to architect the integration of Oracle’s Identity Manager, you need to know how all these pieces will fit together off the top of your head. When you’re sitting in a board room, and you’re told what it is that they want, you need to be able to stand up, white-board out a proposed, high-level diagram pretty much instantly with all major pieces being accounted for. They will ask you questions on how it will work, or where the firewalls will be, or any other technical questions about your diagram. You’ll have to be able to talk to and answer all questions to instill confidence in them about you and your plans. They’re about to invest (or already have) hundreds of thousands of dollars, and this one moment could cause it all to be flushed down the toilet or prove to them that they have an IdM Rockstar in front of them!
Hopefully that’ll get you started and understand what you need to know in the world of IdM software. Next up: Administrator knowledge of all the major enterprise software suites and applications that are being used in big business!
.: Adam
PS: Merry christmas and happy new year! With all this time off, what are you doing? I’ll be testing a new implementation strategy for virtualized environments in the cloud. IdM Rockstars never rest! Make sure you learn something new this break as well!