What does it take to be a successful solution architect in today's business landscape? Here's a hint — it's not a numbers game like you might think.
We caught up with Senior Developer Steve Zimmerman, who's been working with Microsoft Dynamics software for over 20 years, to ask what qualities make a developer successful in today's digital landscape.
Q: How did you get into IT?
A: In 1996 I was working my way through a PhD in history at the University of Memphis. I loved my history degree — it taught me the value of communication skills, both written and oral, and the value of being able to do research. Most of all, it taught me interpersonal skills.
I’d always had a knack for computers, despite having never been formally taught anything. While working on my master’s degree in history, I began working on web development for the social sciences and philosophy department at the college I attended. Keep in mind that most of the technologies surrounding such work were not terribly advanced at that point, things developers do today with the click of a mouse would require a lot of effort back then. But I did learn at least a little bit about what the profession required.
After a year and a half of PhD work, I became convinced that I’d never get a job teaching history at the college level. There were just too many history teachers out there at that point, so many in fact that when the small liberal arts college I attended would do a job search, it would get applicants from Harvard and Yale. I quit the program, decided to make a change, and moved to Minnesota.
I started working in IT for a Dynamics GP partner. After a year or so in that position, I asked if they would be willing to train me to be a developer for Dynamics GP (then called Great Plains). I went to Fargo, North Dakota in 1999, did the training for Dexterity development, and got certified. I was one of the last people to get certified for Dexterity, as they discontinued the certification not long thereafter.
Q: How was the transition from history to IT?
A: My first few projects were terrible. Being trained doesn’t mean you are proficient. But I did learn the value of the process. I wasn’t doing my own designs back then, but I was at least involved in the design meetings that would occur. I learned a great deal about how to do the process properly — from design, through documentation and QA, to delivery and end-user training. Years passed, positions came and went, and through it all, I became more and more proficient in designing solutions to fit user’s needs.
Q: Why is documentation important when creating a client solution?
A: I'm a firm believer in documentation. Don’t get me wrong, I hate it. I hate writing it, but I understand the value of it. I’ve told more than one customer that the document I write for them becomes our Bible — it’s what I’m going to build, exactly, so we need to get it to say exactly what they want. Once they sign it, that’s what they're getting. I’ve been saved more than once by my documentation, but more importantly, the outcome has been what’s expected — the customer gets what they wanted, and I don’t have to feel like I’m going to be blindsided because I forgot something.
I don't understand why computer science is under the purview of the math department. I don’t know why computer programmers are subjected to inane math classes they most likely will never use, while not being required to take humanities. I understand there are still types of programming that are math-intensive, but application development isn’t one of them.
As such, our current educational system is succeeding in graduating coders, but not solution architects. Even the math-intensive types of development still require communication skills, design capabilities, and documentation. You don't learn these things by knowing 2+2=4, but from the humanities. If you want to be a good writer, read talented authors. If you want to be a good communicator, talk to people.
If you can’t talk to people, if you can’t write well, if you can’t understand a problem and then provide a well-designed solution to solve it — in terms that people can understand — you'll have limited potential as a solution architect. You'll likely have a job out there, creating the stuff other people have designed, but you’ll be one of those people that's never allowed anywhere near a customer.
Interested in more career tips and tricks? How about 10 things you learned in kindergarten?
