Actually this is good for any architect. The ability to achieve consensus across all the groups gets you the buy-in that you need. It also ferrets out the detractors that are going to spend the next decade throwing rocks at the decision.
Next is go make friends with the operations people. Learn how operations works and what they do, how they monitor, how they keep things running. While they appear to be BOFH like, when they get the idea that you are listening to them, they will help you out. Make sure someone from OPS is on your consensus team. I had a white board architect (WBA) work for me and I made him get signature approval from OPS on everything he proposed. After awhile he got it and became less of a WBA.
Do lots of proof of concepts to see if what you are thinking about will work. In the past I've had a cadre of co-ops / interns do the grunt work. They are always excited about working with a new technology.
(If you are in the Philly Area, call Drexel University. You can get co-op students year round in either 3 or 6 month increments. Pro tip: Don't hire them until after they graduate. If you don't send the co-op back to the University so the Uni can get the rest of their money, they will stop sending you co-ops. )
The other advantage of co-ops is that you can afford to go down some dead ends. It's a win-win, you use a less expensive resource to find out bad news, the co-op gets to put "Worked on Astroscript at major company" on their resume. It's very freeing because you can then take on someone from the outside going "Hey lets do Elm", assign an co-op to do most of the grunt work rather than burning your time up.
You can be as hands on as you want. I've always found that getting some new tool installed is a huge mess. Need this library and that version of something else, these scripts don't work, etc. So my co-ops do that. Once it's spun up and running and their first mini-Proof Of Concept is working then I'll get involved with a larger POC and get my hands dirty.
(An aside on the install mess. When we get ready to start the "Moving to Astroscript" to the internal consensus cycle, I assign a co-op to package it. They put together a clean setup process for both Operations and the Dev Manager to sign off. Nothing kills a project faster than the people you want approval from not being able to spin it up to look at it.)
It's mostly lots and lots of talking to people about what their pain points are, what direction the business is going in, thinking about planned and unplanned pivots, etc. Always be thinking about a Plan B.
My check list for new things (in order)
* What business value does this bring (ROI)
* How does operations run this
* What is the Disaster Recovery Plan
* What is the opportunity cost
* What is the internal friction
* What is the external friction with our partners
Other things that may help:
Start a series of brown bag sessions (your call if the bags contain lunch or beer) and present out to anyone what you are thinking about. ( Tip: Master the ability to create a 50 minute long Powerpoint in 30 minutes. )
Talk to other architects / users that are using the tools, designs, etc. and see what they are finding out. Be ready to share back what you find. "Hey our review and POC of Astroscript figured out that getting any useful logging out of it was impossible, so we are punting"
Be a nice person. And remember, someday you may end up working for one of those co-ops.
One of the best things was posted by sheepmullet
Actually this is good for any architect. The ability to achieve consensus across all the groups gets you the buy-in that you need. It also ferrets out the detractors that are going to spend the next decade throwing rocks at the decision.Next is go make friends with the operations people. Learn how operations works and what they do, how they monitor, how they keep things running. While they appear to be BOFH like, when they get the idea that you are listening to them, they will help you out. Make sure someone from OPS is on your consensus team. I had a white board architect (WBA) work for me and I made him get signature approval from OPS on everything he proposed. After awhile he got it and became less of a WBA.
Do lots of proof of concepts to see if what you are thinking about will work. In the past I've had a cadre of co-ops / interns do the grunt work. They are always excited about working with a new technology.
(If you are in the Philly Area, call Drexel University. You can get co-op students year round in either 3 or 6 month increments. Pro tip: Don't hire them until after they graduate. If you don't send the co-op back to the University so the Uni can get the rest of their money, they will stop sending you co-ops. )
The other advantage of co-ops is that you can afford to go down some dead ends. It's a win-win, you use a less expensive resource to find out bad news, the co-op gets to put "Worked on Astroscript at major company" on their resume. It's very freeing because you can then take on someone from the outside going "Hey lets do Elm", assign an co-op to do most of the grunt work rather than burning your time up.
You can be as hands on as you want. I've always found that getting some new tool installed is a huge mess. Need this library and that version of something else, these scripts don't work, etc. So my co-ops do that. Once it's spun up and running and their first mini-Proof Of Concept is working then I'll get involved with a larger POC and get my hands dirty.
(An aside on the install mess. When we get ready to start the "Moving to Astroscript" to the internal consensus cycle, I assign a co-op to package it. They put together a clean setup process for both Operations and the Dev Manager to sign off. Nothing kills a project faster than the people you want approval from not being able to spin it up to look at it.)
It's mostly lots and lots of talking to people about what their pain points are, what direction the business is going in, thinking about planned and unplanned pivots, etc. Always be thinking about a Plan B.
My check list for new things (in order) * What business value does this bring (ROI) * How does operations run this * What is the Disaster Recovery Plan * What is the opportunity cost * What is the internal friction * What is the external friction with our partners
Other things that may help:
Start a series of brown bag sessions (your call if the bags contain lunch or beer) and present out to anyone what you are thinking about. ( Tip: Master the ability to create a 50 minute long Powerpoint in 30 minutes. )
Talk to other architects / users that are using the tools, designs, etc. and see what they are finding out. Be ready to share back what you find. "Hey our review and POC of Astroscript figured out that getting any useful logging out of it was impossible, so we are punting"
Be a nice person. And remember, someday you may end up working for one of those co-ops.