Slashdot Mirror
Ask Slashdot: Advice On Enterprise Architect Position
dave562 writes: I could use some advice from the community. I have almost 20 years of IT experience, 5 of it with the company I am currently working for. In my current position, the infrastructure and applications that I am responsible for account for nearly 80% of the entire IT infrastructure of the company. In broad strokes our footprint is roughly 60 physical hosts that run close to 1500 VMs and a SAN that hosts almost 4PB of data. The organization is a moderate sized (~3000 employees), publicly traded company with a nearly $1 billion market value (recent fluctuations not withstanding).
I have been involved in a constant struggle with the core IT group over how to best run the operations. They are a traditional, internal facing IT shop. They have stumbled through a private cloud initiative that is only about 30% realized. I have had to drag them kicking and screaming into the world of automated provisioning, IaaS, application performance monitoring, and all of the other IT "must haves" that a reasonable person would expect from a company of our size. All the while, I have never had full access to the infrastructure. I do not have access to the storage. I do not have access to the virtualization layer. I do not have Domain Admin rights. I cannot see the network.
The entire organization has been ham strung by an "enterprise architect" who relies on consultants to get the job done, but does not have the capability to properly scope the projects. This has resulted in failure after failure and a broken trail of partially implemented projects. (VMware without SRM enabled. EMC storage hardware without automated tiering enabled. Numerous proof of concept systems that never make it into production because they were not scoped properly.)
After 5 years of succeeding in the face of all of these challenges, the organization has offered me the Enterprise Architect position. However they do not think that the position should have full access to the environment. It is an "architecture" position and not a "sysadmin" position is how they explained it to me. That seems insane. It is like asking someone to draw a map, without being able to actually visit the place that needs to be mapped.
For those of you in the community who have similar positions, what is your experience? Do you have unfettered access to the environment? Are purely architectural / advisory roles the norm at this level?
I have been involved in a constant struggle with the core IT group over how to best run the operations. They are a traditional, internal facing IT shop. They have stumbled through a private cloud initiative that is only about 30% realized. I have had to drag them kicking and screaming into the world of automated provisioning, IaaS, application performance monitoring, and all of the other IT "must haves" that a reasonable person would expect from a company of our size. All the while, I have never had full access to the infrastructure. I do not have access to the storage. I do not have access to the virtualization layer. I do not have Domain Admin rights. I cannot see the network.
The entire organization has been ham strung by an "enterprise architect" who relies on consultants to get the job done, but does not have the capability to properly scope the projects. This has resulted in failure after failure and a broken trail of partially implemented projects. (VMware without SRM enabled. EMC storage hardware without automated tiering enabled. Numerous proof of concept systems that never make it into production because they were not scoped properly.)
After 5 years of succeeding in the face of all of these challenges, the organization has offered me the Enterprise Architect position. However they do not think that the position should have full access to the environment. It is an "architecture" position and not a "sysadmin" position is how they explained it to me. That seems insane. It is like asking someone to draw a map, without being able to actually visit the place that needs to be mapped.
For those of you in the community who have similar positions, what is your experience? Do you have unfettered access to the environment? Are purely architectural / advisory roles the norm at this level?
An architect is someone who designs, implements and oversees the day to day progress of large(r) scale projects. You get to define who/what to buy and how to realize your vision. But no, you don't need access to the systems but you do need an overview of the entire infrastructure, you're an architect, not a builder/maintainer/owner, you get to see the site, you define future upgrades but you don't maintain the system(s), you surround yourself with others that do that job.
If you can't get a full picture of the network and systems without full admin access, your underlings are doing something wrong and it's time for you to kick them out or go on a major discovery/documentation project. If I were an architect, I'd make sure I have plans, diagrams and documentation on the entire picture first before embarking on a next project.
Custom electronics and digital signage for your business: www.evcircuits.com
With 60 hosts and 1500 VMs I would certainly expect separate roles for enterprise architecture and system provision/admin. If you were talking about a a dozen hosts and 100 or fewer VMs then a sys admin with architectural responsibilities would be quite common. The main thing here is what can you do? My guess is with your experience they could use you overseeing a system admin team and doing EA, moving more to the latter as the team's experience grows.
I'm one of several that play the EA role for an 8,000+ employee firm and for the most part I have no special rights to the systems, domain and network. I can see read rights to everything your describing being reasonable, but just like we don't give developers rights to the production app, the architects shouldn't have the ability to change production either. The person designing and advocating for the solution always thinks they are right. But having to put it through a good change control process helps reveal assumptions and ill considered ideas. That isn't to say you should be able to see into production either directly or be able to request any data you need to design better solutions. And you're not powerless, sounds like the last guy had enough power to screw things up, use the same bully pulpit to start guiding the changes that make it better.
What they're offering isn't out of the norm, though I might negotiate with them and ask for read-only access (non-root for servers) at least. I've been a network architect for a few years, and one of the things that comes with: loss of enable access to the routers and switches. Mind you, I was a data center network engineer for a whole bunch of years so I know my way around them. But the organizations would rather I "look, but don't touch". The great thing about it is: I can't be called for an on-call issue because there's nothing I can do to fix it. :-)
Welcome to needing to think strategically. Take what they're offering as a compliment and run with it!
I concur. Take the small wins (especially in big orgs), and help them make the transition. You don't need rights to anything YET. That's after you learn to trust your team to bring things into the newer enterprise model and they learn to trust you. A position of this magnitude, and the experience in performing the full migration will get you even better dollars and perhaps even CIO at a firm slightly smaller, or even the same size depending on how you play it.
If you were willing to stick it out for five years and got a major offer in that time, why not stick it out another two and see where it leads?
When the foot seeks the place of the head, the line is crossed. Know your place. Keep your place. Be a shoe.
The architect is the "big picture guy", he should be able to design it and explain it. But he sure as hell shouldn't be running it.
The architect is most decidedly not the sysadmin, he's there for strategic and long term planning, but not day to day stuff.
If you want to be both the architect and the admin, you'll do a piss poor job of both, and likely cause more problems than you realize. I've met a few architects who thought they should still keep their fingers on the switch, so to speak ... and as they generally made a hash of things because they didn't have the time to be good admins, and though they knew everything at all times.
An architect who thinks he's ad admin is someone who has delusions of being able to do everything, and ends up doing everything badly.
Your management is right, it's an either or thing.
If your organization is small enough you can do both, you're not really an architect. If it's large enough to need an architect, it also needs a sysadmin. It doesn't need some guy who thinks he can do both.
Lost at C:>. Found at C.
I would say that the best enterprise architects are the ones influencing the business, listening to their pain points, identifying the risks with the security manager. Set the boundaries or constraints of your organisation. No point wanting to use public cloud if you hold TS information. Do you suffer more pain for not technologically being able to spin up things automatically? Or do senior management have drivers to meet compliance this year because they now got to a new $ value and have more auditing responsibilities. They will be the ones with the money to let you execute your roadmap, so you need to show the global view of how IT enables them. Don't be precious around opensource vs Windows, Oracle vs PostGres. Only if you want to analyse the costs and direction of the company as a whole, might you say that you have an organisational direction to set. Expect possible resistance from the person who takes your job. Negotiate, document, communicate, review and sign-off.
Develop roadmaps, ISSP's and ways to get there that are easy for people to follow. Use the operational staff from your new level to derive the information on your behalf. Do your work on it, and then communicate how you want to tackle problems. If you have not had clear leadership in the organisations technology aspirations space, then take advantage of being the EA/CA and the position it generally enjoys closer to the senior management. For all sides though, you need to bring ways forward, budgets expected to be consumed, tech sets to be used, tech sets to be retired. Read up on TOGAF or other architecture methodologies. See how an EA can slot into the surrounding processes such as programme management, business planning. And fully expect those people and processes to be needing help too.
I can say as a 6+ year infrastructure architect, I've only rarely hopped onto a read-only view of a vCentre, or into an Azure/AWS config. Moreso for my own training than anything. Same goes for spinning up VM's, playing with controllers - only for training and keeping across what the market has to offer. You will find very quickly it is hard to stay abreast of all of that, especially with the ton of work mentioned above. Embrace that, do a good job and try not to upset the alphas on either side ($$ and priorities on management / business side, and tech arguments on IT side can bring out worst in some meetings).
I don't want leadership, management or anyone with any kind of oversight responsibility making changes on the live gear. That's the entire point of having an operations staff.
However, I see absolutely nothing wrong with read only access. The ability to change things - Not Good. The ability to gather information, that I would deem to be necessary for someone who's going to handle the care and feeding of the system going forward.
It also sounds like you need to clean house if your ops staff is pushing back at designed changes, however. Putting in a competent staff that will follow your dictates and provide you with the information you need would go along way to making access to the actual gear unnecessary
I'm an Architect. Also with a long technical background. Similar size organisations. It's not normal to have admin access. Largely because that level of detail can overwhelm you. It's also easy to get dragged back into your old job if you can be dragged back. In one org I worked in where the Architects did have access (before I was one...) one of our vendors develops the habit of finger pointing when mysterious issues occurred that looked like unauthorised change. We stopped that with some config monitoring software that notified us of any settings change - but I mention it to show what can happen.
One of the hard concepts to grasp is what is Architecturally significant. Mostly that's big block level stuff, but sometimes certain details can be significant too. Working out which without looking at every detail is where your experience comes in.
Most of the time the team members doing the design and implementation work can show you the detail when you need to see it - and by asking them you can discuss what you're looking for and why. This builds up trust that your solutions aren't just ivory tower creations from some distant figure but things they're connected with.
If you must have some ability to see every little detail you could always try asking for read-only access. It might be a reasonable compromise.
This has been a bit of a rambling post, but I hope it has something useful....
Spoken like a clueless idiot who thinks he can do all tasks due to his divinely superior skills. Sorry, you sound like a whiny little punk with not enough experience to realize how utterly full of shit he is.
My guess it you'd be qualified neither as the architect nor the admin, but act like you know it all.
You're a fucking idiot. The fact that you think the architect is one of the "big guns" who should have the keys to the kingdom tells us this.
Once you get to a certain level of management, you don't get to drive the fucking bus. You get to decide where the bus goes, but keep your fucking hands off the controls.
Fucking children who think they know everything.
If you are logging on to boxes, you are getting too close to operations and too far away from architecture. You get the admins to pull reports and logs you need, but you don't really need logins to the entire infrastructure. What on earth would you do with it that you can't get from the admins? I'm an IT architect for a DR outsourcing company; I wouldn't even have the least clue HOW to login to the gear I'm buying by the truckload (much less do anything useful with it), so obviously I don't have the ability to do so either.
An architect need not have admin rights or even the knowledge an admin must know. (And likewise, it's not important for an admin to know things an architect must.)
P.S. Errr, 1500 VM's for 3000 employees? I sense that a lot of these (and whatever massive amounts of stale data they are attached to) sit utterly disused.
P.S.S. And your historical analogy isn't even valid. Cartographers are generally not surveyors.
An architect (and one that is trying to be forward thinking and implement all sorts of fascinating new gear) is wasting time learning the admin interface for every box he/she specifies.
And if an architect is having trouble getting away from daily ops, not having any access to the boxes at all will help with that transition. (Not to mention that the architect will inevitably get pulled into ops problems, leaving less time to do the actual job.)
i'd say take the position and try to grow it from there, if you need to.
if you need data about configurations, ask for it anytime you need it. if they cant get it to you in a timely manner, complain up a few times, then try to get more access.
sounds like not having to change things is a good way to not get called to fix them, however. also sounds like you are being rewarded and should accept it. maybe you'll find they are open to you doing more once you prove you can continue to handle your duties well.
By and large, language is a tool for concealing the truth. -- George Carlin
If the time has come for the general to pick up a rifle, the war is lost. You should not be thinking in single-system mode. You should be able to trust your minions and underlings to do what they're paid to do, which is follow your direction. Read-only access is a great ask, since it ensures that any changes made are documented, and therefore repeatable.
Watch for Penguins, they eat Apples and throw rocks at Windows.