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?
The organization is a moderate sized (~3000 employees), publicly traded company with a nearly $1 billion market value (recent fluctuations not withstanding).
Since when is that "moderate sized"? That seems big to me or am I just living under a rock?
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!
Jason Van Patten
Is this one of those "separation of duties" issues raise by the security guy? Then make sure everything you do is audited, problem solved.
Is this some guys who are jealous of their infrastructure or scared that their shitty implementations get exposed? You are one of the big guns now, don't let yourself be dissuaded by pavid minions. Explain the situation to your peers, gain their support, then strike. They are making changes because they expect changes to happen.
Either take the job and do what they ask (for the pay check they are give you to do it) or don't
It obvious they want to implement a plan that the people in charge thing is good. If your not in charge you can tell them you opinion but it's not your job to make the decisions
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.
The short answer is No.
An EA does not get access to admin on anything other than their cmdb or perhaps capacity planning tools.
Are you going to ask for access to all the routers, databases, wifi, and mobile interfaces? EA will cover all those also, how about the laptops?
In the end your new role will involve a crap ton of meetings and moving boxes into other boxes for powerpoints.
Subject matter experts or architects will get admin for their domains only if they still fill a roll such as DR or level 4/5 support.
The long answer is No.
I just left a job where the EA teams are consistently producing nothing and spending all their time killing anything that they didn't get to produce. At the same time shouting nobody is embracing the new EA team. In almost 2 years nothing functional has rollout out of the paperwork tarpit.
The whole EA role is a bullshit notion which then allows someone to say plan/build/run is the way to go for your org. Leading to heavy offshoring and higher expenses to the company that fell for the whole bullshit line of EA.
If your company is smart it will keep the EA group small and demand any project EA touches has a definitive delivery date that is aggressive and makes them sweat hard.
Anything else will just lead to a complete organizational purge in IT to find the problem nobody in their exec team will admit because EA was their political brainchild.
If you will be at odds with the team, oh here's the newcomer that won't make us work the same way we used to work ... then run away.
If you have a proper connection with the team, then please do so, by all means! Then discuss with the guys, instead of staying in your desk. And ask for plans, for info on servers, for telemetry, for all that you need for you to know your servers and infrastructure are happy. And if you cannot know because you don't have data, ask IT to add up the proper data gatherers.
Which means you'll have a plan, you'll know how everything run, and no, you don't need any physical access... You'll be able to oversee how everything works, and yet not have any kind of access. And the moment you need it, you poke your IT friends and make sure to get the missing glimpses.
Of course, the backrub must come to the other side too, and you must make sure all sysadmins are happy in the process.
I work for a similar sized company, and our architecture team was built taking senior people from several different admin groups. Separation of duties, especially when you are covered by PCI, Sox, etc, is the norm.
As long as you have access to complete information as to the design, implementation, and how systems are running and working, you probably would not have unfettered access. It should not prevent you from doing your job. But you absolutely have to have a good working relationship with the people who do have that access.
The role of an enterprise architect is to work with stakeholders, gather requirements, create time lines and then hand their work over to another team to implement and continue to provide governance. At best you might be lucky to get access to some sort of test environment. I am TOGAF certified and like you before I started didn't understand what it was before I started. The trainer I had described it as creating cartoons for executives. I still got the cert but realized it really wasn't for me. I will say that I think the role is very important and as an implementor is designed to answer the questions I often have when building something like number of users, availability requirements etc.
Your job as an enterprise architect should be to align the IT strategy with the needs of the business. If you are concerned with the state and quality of what you are looking after you have every right to ask for reports. You should not spend your time in checking other people's work imo, that would be the job of the ops team.
Access is a tricky one... People want to protect their empire and a political mine field.
It would be funny if he's been offered Enterprise Architect for the city of San Francisco.
An Enterprise Architect (in the definition you're using meaning in charge of the infrastructure as opposed to the TOGAF definition) shouldn't have sysadmin access to the network because that isn't the game you're in. You shouldn't be logging into the EMC SAN and making sure that tiering is configured properly. Your job is to write the paper describing how the SAN system fits into the infrastructure, what applications should use it and that tiering should be enabled.
You are one of the big guns now, don't let yourself be dissuaded by pavid minions.
If you don't work with people, even "pavid minions" they will fight you to the end of time.
Explain the situation to your peers, gain their support, then strike.
If you go behind people's backs, they will return the favor.
They are making changes because they expect changes to happen.
Never make changes purely because changes are expected. That is what gets users slashdot beta and that is what destroyed Dice's investment in slashdot.
What you want are metrics. So while you cant get access to the systems ... you can (probably) dictate everything you need to measure and monitor. After you have lots of data points, then you can report the crap out of it to start making i better.
Your company sounds like a dreadful place to work.
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.
Sounds like the entire organization may continue to be ham strung by an "enterprise architect" who relies on free advice from random strangers, and does not have the capability to properly think for himself.
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).
What kind of business requires a SAN, a IaaS, 4PB of data,1500 VMs and a private cloud initiative? I've seen one of the big three management consulting firms running on nothing more than Windows Server with a bunch of shared directories mapped to the desktop. For example, if you were in the Washington office, then you could drill-down to to the London server through the L: drive. THey did have a custom app for remotely updating the desktops. Not much innovation going on there.
"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."
What other kind is there, unless you're running a large ecommerce business.
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
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 reasonable for a moderately sized company with the infrastructure you describe. Your analogy of drawing a map without being able to visit the area is a very good indicator of the miscommunication occurring here - you need to be able to see all the infrastructure, but you're asking for full access. To use an imperfect car analogy (this is Slashdot after all), you need to be able to lift the hood and see the engine. That's reasonable. You're asking for full access to change all parts of the car. That's overkill, actually implementing changes is outside the scope of your responsibilities.
A requirement of any senior role is the ability to delegate responsibilities and trust the input from your team and other managers. I suggest that as an architect you should be asking the IT core team for the network maps, system configuration lists, etc that you need as inputs for your design decisions. You can then respond with changes that are needed to their systems. In your new role you would have the authority that your changes are requirements not suggestions. However the responsibility to make those changes still rests with the IT core team - you don't need and should not have access to make those changes yourself.
I like to think of architect roles as consultants with authority. You give them the best documentation you have, and maybe read access to the systems. They come back with recommendations for changes, while architects have the authority to state them as requirements instead of just recommendations. But just like you wouldn't give an external consultant full admin to your systems (eg: domain controllers or databases), you wouldn't give it to an architect.
A recursive sig
Can impart wisdom and truth
Call proc signature()
Look up "peter principle" and realize the 3 envelopes in your top left drawer are the only advice to heed.
I'm only a system administrator that has worked with resources about maybe 20% that size, but there's one thing I'm hearing that I'm not exactly sure you're seeing: this is a trust issue.
I imagine that, if you did have full 100% access, and the system admin had full 100% access, there'd be a good chance that the left hand wouldn't know what the right hand was doing, leading so some really ugly problems.
If you were the architect, do you trust that the admin will carry through with your proposals? Do you trust that the company will follow your recommendations? If so, then captain the ship. If not, then decline the position, and accept the situation as it is, or find yourself another job.
Personally, from what I'm reading, I think you have to accept that an architect is an architect, not a map maker or a sysadmin. They design, not build. That's the position the CTO/CIO is looking for, and if you don't see yourself fitting into that position, then don't take a job you won't be successful in.
Key success components to such a position requires that you have the authority to make decisions and direct sysadmin level staff to implement them. You will always face the challenge of "need vs want" and "budget vs time" / "budget vs benefit" with the execs. Essentially, if you're given the role to design the systems but cannot force their implentation then you will have constant struggles and it may prove to be a very frustrating position. And be nice to to susadmin staff. ;)
Personally I'd push for control of whatever budget they give you and the autonomy to act. These pieces may be a I've your pay grade in a company of your size though.
Up until 2 years ago, when I got out of IT because i was bored of it after 21 years, I had spent the previous 8 years as an EA. As an EA there is no reason for you to have domain admin, enterprise admin, net ops admin, storage admin or any other admin role on the infrastructure. This is not only best practice from a security standpoint but for your own benefit. Read only access to the infrastructure may be required in certain cases but as an EA your job is to visual, design and plan implementation. you should have a tech team to call on for info you dont have access to and that same team to perform the actual implementation. At no stage should you be fiddling with live infrastructure unless its along side your tech team to troubleshoot implementation problems or gather data.
Like everyone you want to feel special and have god like control, in a little company of a few hundred people, thats fine and may even be appropriate. For a full sized enterprise if you havent been segregated off then the CIO/CSO isnt doing their job properly.
When you become THE enterprise architect, you are responsible for defining the why and the what, and overseeing the execution of how... But not doing it yourself.
To get access to the details is to get lost in the details, which is always comforting to a hands on technologist... But not really the job.
You are being given the opportunity not to be the driver, but to define the destination and the waypoints along the way. Find the good drivers in your organization, and make them responsible for following the itinerary you define... And learn to educate them as to the why.
No one easily follows direction without understanding.
This is a leadership position. Leaders lead, and natural leaders attract followers, they don't compel them.
But the execution of leadership vision and direction is ultimately the responsibility of the hands-on team. So, in a sense this job is about being successful by making them successful. Those that lose sight of this don't get very far.
Comment removed based on user account deletion
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....
NX-01 (Archer)
NCC-1701 (Kirk 1)
NCC-1701A (Kirk 2)
NCC-1701B (Harriman)
NCC-1701C (Garrett)
NCC-1701D (Picard/Riker)
NCC-1701E (Picard/Riker)
I'll forget alternate timelines and also the boats as they've already been "architected."
Donte Alistair Anderson Roberts - hi son!
Karma: Chameleon
Weather or not your overseeing people you are overseeing projects and larger scale strategic strategy, which makes you a manager.
You don't have the luxury anymore of being able to do things yourself. Context switching from strategic to tactical mode and back has a huge cost. Humans suck at multitasking. That's the reason that in most human endeavors over the millennia we've settled on the idea that organizations work most effectively when you have a few people overseeing the larger scale picture and many people managing the day to day tactical situation and reporting the information that the leaders need in order to make decisions up.
You can no more be successful if you're in systems typing ps to discover what's going on as a general can be if they had to write every field report by hand. At best you'll burn yourself out and then everyone will be in trouble.
Instead my advice would be to take this as a coaching opportunity. "Hey, I'd like to take a peek at this config file. Mind bringing it up for me? Ah, see, that's where the problem is, you how that quotation mark is missing? The next line is being included int he string. Thanks, I'll raise a change to fix that." You've just taught someone something. Next time they will remember to check their string terminators. It's a win-win.
And I know this because I was in EXACTLY the same spot and mindset as you about 10 years ago. It's time to shift your mental viewpoint. It's not easy, but the fact that you were given this responsible suggests your fellow leaders believe you're up for it.
Min
On the whole, I find that I prefer Slashdot posts to twitter ones because I don't get limited to 140 chars before
I worked a number of years ago as Chief Architect reporting to the CIO of a similar-sized organization. To answer your question directly: I didn't normally have admin access to systems. I could get it easily if I needed it. Mostly, what I had was access to the configuration management system which was a reflection of everything else. More importantly, what I had was unfettered access to any _person_ in the organization with a role in technology. For the complexity of the systems I was dealing with, it wasn't really possible for me to know (or want to know) all the details. Detail was, certainly important, but I trusted most other people to get that stuff right. The situation you are in, seems like it would require a lot of clean-up. I was in a similar situation. In my case, the clean-up was necessary because many systems had been custom-built by offshore providers who had low levels of technical skill. The best tool I had going for me was to use Scrum as a way to do incremental cleanup of large systems. Scrum (or other Agile methods) are an enterprise architect's best friend! Build an internal team of people that you really trust to get things right, get them to work in short increments 2 or 3 weeks long, give them the vision of cleaning everything up, but doing it incrementally, and help them prioritize the work. You will be surprised at the amazing things you can do without direct access to the details. (FWIW, I love your analogy about map-drawing, but I don't think it applies.)
Helping with organizational effectiveness is our job.
Why do you need access to resources? You need only need overview and other information regarding performance etct. As an architecture first step is to use what you have and make if more efficiently with more uptime - once that is there other things will fall in its place.
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.)
Most EAs I've ever known are technical in so much as they are interested in technology, but not deep-techie enough to know how to properly administer a Linux machine, or even to install Tomcat or whatever. They understand the concepts, but not the implementation. They also seem to end up doing a lot of documentation and going to a lot of meetings (which are often technical meetings, not all just business fluff).
Since you asked for advice, mine is:
- an EA position is far, far more administrative than an ops role (documentation, diagrams, presentations). It's also interfacing with the business, so requires some ability to work those relationships and pitch to non-technical people. Ultimately, you'll need lots of business people on-side to 'sponsor' anything you ever want to do. A lot of job specs call for "evangelists" - you're going to be the guy at the top of that pyramid scheme ;-)
- If you're looking to keep getting your hands dirty doing console hacking and such like, then an EA position is not for you. You're unlikely to even be able to throw together a PoC yourself, much less actually work on real stuff
- If you're looking to be responsible for elegant, manageable systems that all behave themselves well and provide the business benefits that are demanded of them, then you're aspiring to be an EA
- Don't think about what the current guy's job looks like - if you want to go for it, take the job and make it into the job you want
In addition to the various comments here about access to systems, I'd like to point out that you don't want full admin rights on the infrastructure. You're setting yourself up for having to fix things yourself. That is not your job.
I work for a university on an integration team. My title indicates I'm a senior developer yet I actually do multiple jobs:
1. Programmer
2. QA
3. System administration!!!
Do you really want 10-20% of your time going into responsibilities that you should not be doing? It won't go away even if you "fix" the problems you feel they have.
When I started, I only managed a few systems the IT department didn't want to maintain for us. Now, we've got a bunch of new infrastructure spun up in Amazon coming out of our budget because IT won't give us reasonable hardware or they "oversell" the VMWare infrastructure to such a degree that a 10 year old AMD box would blow out the hardware we're running. In order to get SSDs for our servers, we have to use amazon. Our "enterprise" database servers just got a single SSD this month and they called it "new technology" and "special disks".
My point is that you may put a dent in a few configuration problems, but you're not going to solve the companies problems without buyin. You're just wasting your time that could be better spent fixing things you have control over.
You do not understand why data processing adopted architect as a managerial position.
Architect in build trade is a visionary not a hammer swinger. They guide, but do not touch. They bring teams together to build the vision.
Now I guide that same way been doing it decades. I also have access to key to the kingdom. But have not had to touch them for years. I have others to do that.
If after "20 years of experience" you end up asking a bunch of shit nerds for advice, you should really find something more suitable to your skills. Like janitor.
Me and my fellow architects don't have access to the boxes and we shouldn't. If there is some reason you need to access those boxes then you're doing it wrong. If you're just curious what it looks like, ask the ops guys to show you.
" 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)"
A company that size doesn't have a detailed network map? Honestly, you should have a massive folder of visio diagrams explaining the architecture and layout of the entire enterprise. An architect has no need for domain admin access (I'm fighting this battle right now). Your job is a broad overview, design, layout and planning. Implementation and maintenance falls onto your sysadmins.
If I was you, and I didn't have an accurate network layout documented, I'd run as fast as I can. Because guess who's fault it's gonna be when everything breaks? Your architects fault.
Stick to your guns - demand what you need to do the job _well_. If that means you need to be able to see what's going on - great.
Just don't have write access to production. You're aiming to teach and lead people in the right direction without doing it all yourself.
You know the situation better than anyone else. Are there competent people you trust to get you the information you need? If not, make system access part of the condition of accepting the position. One the nice (or painful) aspects of a job like "Enterprise Architect" is you should have the latitude to define the job to a large extent. Just remember that every hour you spend at a command prompt is time you can't spend doing the main aspects of your job. There's also the possibility of you being blamed for whatever goes wrong next, whether you were involved or not. There's an opportunity cost to system access.
Sometimes the truth is arrived at by adding all the little lies together and deducting them from all that is known.
"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."
Technically, you don't. The Enterprise Architect is, technically, a high level project manager who oversees everything under them. at least based on how I define it.
Without knowing how your company defines it, there's no way for us to know.
Based on what you've said, it sounds like your IT group is divided into teams responsible for various things. As such, I wouldn't expect anyone to have the keys to everything.
However, too, it sounds like you have no understanding of what the role (even your current one) entails.
Your job would be to work with the IT Director/IT Manager/Team Leads to drive the organizations needs. Get full understanding from each team about the environment, how things work, and identify and process changes that will make things better. Whether this is done via consultants, or with people on your teams.
Good luck - sounds like you're not qualified for the job.
an enterprise architect is violently different from a sysadmin. think skyscraper architect vs a particular carpenter on the building. an architect deals in patterns, modelling and a 5 year plan that is more aligned with business goals than with technology implementations. an EA has absolutely no need to login to production systems, and even if he were able to do, it would be evidence that no security architecture is in place. operations login to production systems, no one else. as you say, "I have been involved in a constant struggle with the core IT group over how to best run the operations.". you are seeking an operational management role, not an EA role.very different animals.
"do you know the difference between an admiral and a captain? A captain is on the ship."
If the ship is the Enterprise, then there could be an Admiral there as well
In WWII Admiral Spruance commanded a fleet from the Enterprise
You should have a development environment capable of modeling, so that others can implement in the production environment.
Implementations running in the production environment as well as they did in the test environment proves your workflow.
Really at this size organization you should already realize this. But perhaps the previous architect did what you are asking and made a complete mess of it. I work for someone similar right now and I'm leaving for exactly this reason. Too many hats means corners get cut more often than they should. Focus on design and oversee parts of implementation, but keep your hands off.
On the plus side this means no more on-call!
What you describe is a political issue, not a technological one. Unless you've already made strong friends with the IT staff, and _earned_ their respect and trust, expect them to resist you at every step. In particular, expect their middle management layers to disagree with every move and sabotage them behind your back. And I'm afraid you're starting out with a basic confusion: "3000 employees" is not a medium sized, company, it's a _big_ company. I'm also afraid that if you think of it as a medium size company, you'll be tempted to micromanage individual employees and pet projects. You're not going to have time for this, really.
Earning the respect and trust of the existing staff is going to be awkward. You're going to need that: they're going to need questions answered, clear decisions made with clear justification, and a clear set of technology and social practices so they know what is expected. Documentation, backup, and standard practices for network and environment configuration are all going to come from or be signed off on by you. If they disagree with a practice, they need to be safe to express it safely, work with you to iron out the differences, and if it turns out one of you were dead wrong, to get the other's insight credited and the other person educated on why the right practice is just that.
And I'm afraid many practices aren't that clear-cut: flexibility versus recoverability, reliability versus expense, growth over repair are all going to require decisions coming from you, as an architect. And even when you make the "right" decision, sometimes things are going to break that the "wrong" decision would have avoided. Some of them are going to be _large_.
That's partly why the existing staff are afraid of handing over admin access. Another possibility is that they're _embarrassed_ and you'll have immediate visibility into what they're embarrassed about. I've had tremendous difficulty with staff leaving in unannounced backdoors "to get their jobs done" and not wanting me to know about them. I've even been booted right off a project because I kept going to the manager with "your technical leader is putting in backdoors for his telecommuting here, here, and here, in direct violation of SOX guidelines: I can't sign off on this".
Anecdotes aside, you're going to have to establish trust with these people. From your short description, it sounds like they've been thinking of you as the enemy. If they're unhappy and can't work with your vision, check if your vision is confused and you can accommodate their ideals and goals. If you can't incorporate their goals, or if they're just plain wrong, show them the door gracefully. And let them know what your "vision" is, so they can be sure if you'll like their plans or if they're going to have trouble convincing you something is workable.
The best way to show them the door is to help them get hired somewhere else better suited to their neds as well as yours. I've had good success with staff who'd outgrown our environments, or our environments had moved to new practices they didn't care for, helping them find work with partners and other companies who appreciated their approach. I've even done a few flat-out exchanges: "You need a new security expert, we need a new backup expert", we've swapped staff, and we both came out better for it.
Your primary tools will be MS Word, PowerPoint, Acrobat Reader, web browser, and calendar.
You will spend most of your time doing one of these things: reading whitepapers, writing documents and presentations, and participating in meetings.
You will forget about ssh, bash, etc. and will not have the time to do these things. The EA position has nothing to do with fiddling on real systems. YOU need to decide whether you're interested in being an EA.
If your the architect you shouldn't have change access to prod any more than a developer. If you can't understand that than you aren't cut out to be an architect. An architect should always work through proxy. You give up the keyboard for the whiteboard.
I was hired as a desktop tech by the recruiter. When I showed up at work, they had me doing remote computer security for desktops. A year later I got a fancy new job title — senior system admin — based on what I'm currently doing and 18 years of I.T. support experience. When I pointed out that a senior system admin in Silicon Valley makes ~$40K more than what I'm currently getting paid, no one wants to comment on the discrepancy.
It seems reading the story of my (working) life ... except for the proposal of the IT Architect position (although my tasks are really related to that).
I'm struggling with the (internal facing) IT Shop to provide us Application performance, Automatic Provisioning of (Virtual) Machines etc. ... I'm here since 2005 and a little changed...it's just a political reason behind :(.
I cross my fingers for you!
" 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"
If you manually (over) provision, the servers become much more predictable and hence reliable. They've been doing that for years with success, so its very patronizing to people if you come along and say these Cloud Buzzwords are 'must haves', yet if they are must haves, how did it all work before you came alone? 'Must' is clearly not must.
IaaS (Infrastructure as a service) is just Cloud marketing fluff. A server is physically linked to its network, and how that links and network exists is a complex design decision relating to performance and security, you spouting 'make it IaaS' is just MBA buzzword fluff.
"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."
So it's not YOU that keeps this $1 billion IT operation working, its THEM. You are just an MBA that claims others success as your own.
Senior management chose you are their IT bullshitter is quite common, management often chooses the person who CLAIMS to be the reason for success above the people they never talk to, who actually are responsible for the company success. Because they don't know any better.
Who get ignored by people at the VP level. So, I can feel your pain and frustration, but don't really have any advice.
No one person should have 100% access to everything in a large organization like yours. They're also doing some things wrong; relying on outside contractors instead of using permanent employees to help keep knowledge in-house. You're also doing some things wrong; never use "the cloud" or you will eventually fall when the cloud disperses. Your IT group is right to keep servers in-house. This protects your company. "The cloud" is an acceptable disaster recovery option, but nothing more.
With 60 hosts and 1500 VMs I would certainly expect separate roles for enterprise architecture and system provision/admin..
This statement is quite right. Apparently the OP doesn't deal with auditors at all in his job. Lucky him. I do in mine and I have something like a Linux system admin job. For the product I work on, and I work for a Fortune 500 company that sells a lot of software products and services, I am the main contact person every year for auditors. Since the OP works for a publicly traded company, he should know that audits are required by US law. Every year I have to answer the same questions from the auditors about separation of responsibilities on the product I support. Honestly, I don't know how the OP doesn't know that getting that kind of access for an architect is going to raise all kinds of red flags in an audit that have to be explained. If I remember correctly, we have exactly 4 people who have root access to our servers who don't work on my team. They're software developers who've worked on the product for years and need that access in an emergency if we have a software related disaster that impacts customers. We have to jump through a lot of hoops to justify this on the audit. In fact, we've actually had our access restricted from some activities we used to do that fall outside of traditional system admin tasks just because it's easier for auditing purposes for us to not be able to do it anymore. In my job my group also doesn't have access to the storage, network or virtualization layers except as users/clients and all changes have to be done by others. Sometimes it's a pain, but at auditing time it makes my life easier as I can tell the auditors "We don't have the ability to change that, so you have to talk to group X on that one".
"do you know the difference between an admiral and a captain? A captain is on the ship."
If the ship is the Enterprise, then there could be an Admiral there as well
In WWII Admiral Spruance commanded a fleet from the Enterprise
But the Admiral has to go through the Captains. Then there's a Commodore (such as Commodore Data) who is in direct control of his own ship (to the point of operating controls himself), and commanding other captains.
While indelicately put, the sentiment is accurate.
So this guy thinks he knows it all. EVERYONE else in the organization are idiots. They don't know half the buzzwords he knows.
Now that they have finally Seeeeeen The Light and offered him this position (with a great big pay hike now doubt)... it's not good enough. They are "insane".
Get off your fucking High Horse. They should fire you. I've worked for morons like you and they inevitably end up fucking things up beyond belief.
Another story for http://thedailywtf.com .
Look, we know he doesn't have access the servers so he hasn't done any detailed analysis on whats there.
Yet he demands IaaS and automatic provisioning, without even knowing if the applications they're running can support it, or if security constraint actually permit critical data being on shared servers.
Can you imagine safety critical systems being on an EC2 cloud? No! Never! Or business secrets being on shared servers on Azure? Only if you're blind to whats been going on in the spying world!
It sounds as if he's claiming success against these 'bad' people, yet they do the work and he doesn't even have a login!
Perhaps I'm biased because I've met many of these people in my time, and they're always spouting todays buzzwords and waving powerpoint slides and have absolutely no idea how these systems actually works. They get promoted because they spout the buzzwords, the management sees in their management magazines.
But as an architect he should be starting from what they have NOW and steering it to what will be TOMORROWS company needs, not TODAYS vendor buzzwords.
OK, after analyzing your question, I've come to the determination that you should leave IT. You're bloated, off point, arrogant, and don't understand people. As a sysadmin and engineer myself, I would never want to work for you.
I think you may be overlooking one thing...eSOX or equivalent policies.
Company assets have to be partitioned. You can't have people that are not trained and/or not accountable for data/hardware messing with stuff. Auditors for the Government and various Standards organizations (ISO this or that) look for these things. For instance, as an "Administrator" for our Manufacturing software, I can change master controls and permissions. But I cannot actually use the software to do anything like create POs, print Invoices, etc. and that is it should be.
I am also in the approval chain for granting access to shares...but I ultimately do not have access to any of the shares (except mine). What's in them is none of my business and outside the scope of my duties, so eSOX and similar policies say I should be locked out.
If you have someone who can do anything they want to anything they want, you are setting yourself up for a disaster.
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
Read only, and then delegate what needs to be fixed, changed and have your IT/NA team do the work.
You are not a trench grunt anymore. you dont touch the toys, you only tell them what toys they can buy and play with.
Do not look at laser with remaining good eye.
There offer is reasonable. Separation of duties is as important as all the things the original poster listed. The company is to big for the OP to be a cow boy, not saying he will but the surest way to make sure he does not go down that path is not to allow. The OP should realize that protection runs both ways. When something happens that was unauthorized he won't be on the list of suspects. I am assuming that the EA isn't also CIO.
Finally its the OP's job as EA to design a survivable architecture, that includes on that survives him leaving for any reason. Not having direct access means he will have to make sure teams working under him have the knowledge and skill sets to get the job done. That might mean training people (sending them boot camps etc), adding people, replacing people. All three of those options are sometimes hard to get done but they need to get done and they won't when the EA can just ride in on his or her white horse and do it themselves. Which by the way means you are taking your eye off the strategic objectives you are supposed to be working on and doing tactical.
EA isn't a tech job. Its a management/analyst role that demands a technical background. It will and should take your hands off the tech. Yes you still need to keep up on new tech, but in the what can it do, what is good for way not in the, this how you implement this type of abstract interface or here is how you install memory in a SAN controller way.
Repeal the 17th Amendment TODAY! Also Please Read http://www.gnu.org/philosophy/right-to-read.html
One of the hardest parts of moving from Admin to Architect is letting go of the day-to-day operations.
This seems another one of those "I know more than everyone else, why won't they listen to me" types of questions. True leaders can persuade their subordinates, peers, and others to follow them. Seems this is more of a case of wondering why people don't just do as you want. Guess what, no one knows everything, and there is sometimes more than one right way to accomplish something.
With the Enterprise Architect comes the authority to lead. You don't need admin access so much as you need to cultivate loyal, capable followers from the SA's that you are leading. They should be the implementers of your architectural designs.
I do agree with the poster that you may need user level access to servers and/or the capability to configure/build different software in userspace before deploying it at a system level.
But Enterprise Architect is a leadership role mainly. From your explanation, you've been trying to lead and influence decisions all along, now they're giving you the authority to do so. Seize the opportunity!
It is very usual that priorities get inverted. You'd say that one diligently designs the architecture and that afterwards everything is derived from there. But that's hardly ever the case. People in spots where money flows (e.g. sysadmin, sales, purchase) usually have more influence than those who actually matter most in the light of business strategy.
Who will be your boss? Will he back you up? Did you guys actually analyze your business to develop a business strategy? Or do you have policy by decree? What will the guys say that will become redundant as a result of your optimizations?
I hope you will succeed in pushing your company forward; Costs and efficiency are always factors. If you don't have reall backup from the business strategy then you might head towards rubber stamp. You should avoid becoming a scapegoat for the mess the shop is in.
(I say this with long experience as programmer, sysadmin and architect.)
I hadn't the slightest objection to his spending his time planning massacres for the bourgeoisie... (P.G. Wodehouse)
We are divided into disciplines of expertise with some cross knowledge and rights, however I don't have full access to everything, but I do have access to a lot. For example I don't tread in the MS Exchange space, and don't have any rights there really beyond what AD operations that my rights give me to edit user profiles that can translate into affecting Exchange. I have full rights over the servers and clients that in my preview, if I can justify the need I can usually get rights to other things.
I agree with the point of view that Enterprise Architect != Sysadmin...SysAdmin is a lower level job, Enterprise Architects tell SysAdmins what needs to be done, and they go do it.
I used to be in camp of give me everything...but I find these days time and experience has taught me I don't need or even want access to everything. If I don't have access it, I can't be blamed when it blows up! Helps me sleep a lot better at night honestly.
As an architect, you do need to keep abreast of new and evolving technologies. This means that you need access to either staff or strings of equipment for occasional experimentation. Again, it's better if prototyping can be done by someone else, because that's not really your job. When the prototyping is done, you want to get a really good demo so you can envision what the impact of that new technology will be on the mission or objectives of your enterprise.
It's clear you do not understand the position. You need to read about what the job entails, and then decide if you want to accept the offer or not. It's a substantial change in role from your current position. In this case, the Wikipedia article is pretty accurate:
https://en.wikipedia.org/wiki/...
As others have stated, your primary responsibility is specification. To do this, you meet with stakeholders, and do projective business IT strategic planning.
While you can relatively easily negotiate for read only access as a demand from "on high", you should not personally use it. It should be used by your staff, temporary or permanent, for the performance of detailed specification compliance audits and spot checks. This is adequate justification to get management buy-in for this type of access. This type of access is for a role, not for a person. This is one of the reasons it should not be you.
For day to day operations, what you need are dashboards, which measure the degree of compliance with the detailed specification in an ongoing basis. The main purpose of the dashboards are to give you information you can summarize periodically to the executives, and as feedback into your strategy decisions going forward (particularly decisions surround capacity planning and technology adoption).
The purpose of the ability to audit is to ensure that the dashboards are not giving you fudged numbers based on what you want to hear, vs. what IT whats to implement (or what they can implement; you may be asking for the impossible, as a dictator, when you should be viewing the detailed specifications as a negotiation). Audits can also provide progress reporting on deployment of specification changes, based on what IT is reporting vs. actual. Since you appear to be planning a lot of churn for them, I suspect you will need one FTE staff member to perform rolling audits to ensure that things are on schedule, and if they aren't, you can negotiate either a schedule change, or a working emphasis (this is a prioritization list: other things will suffer if you have insufficient staff in IT for the demands being made).
Good examples of what you can dictate are things you've complained about: Automated Provisioning, use of SRM in VMWare installations, enabling automated tiering in EMC storage hardware, and so on. Things which will bite the enterprise on the ass eventually, if they are not done.
Your initial dashboards should be based on displaying progress on this (e.g. "percentage of VMWare installations with SRM enabled", etc.).
Note that before any of your shit starts running down hill, you need to make sure you are not downhill from them. To do that, you are likely going to have to have meetings, a couple times a week (usually something like Tuesday/Friday), to collect requirements for the business, and then mash it into part of the requirements document that you will need to prepare before you start defining strategy and dictating conformance/performance). Otherwise you will find yourself buried in crap, because your goals will not be clearly derived from the enterprise goals.
Your ability to take new input from the early in the week meeting and report it in the late in the week meeting with the stakeholding execs is going to be your main performance metric until you go into the design, then implementation phases. Your goal is to get to an ongoing maintenance/change phase. Your metrics will be different in each phase. You will use these in your performance reviews to justify yourself.
If you have other things you care about, they need to be in the specifications -- and they probably need a dashboard, and they need to have a schedule.
For example, if you care about automated provisioning, then you need to have a scratch machine that is identical to the production machines, and you need to have a metric of "how long from a zeroed state does it take to provision the m
Having lived through such a scenario twice now, I will tell you that you'll need to be able to take a much more hands-off approach. An architect needs information to make decisions, but should not be mucking about in the systems. To be effective, you should either have read-only access to gather the information you need to do your job, or have a very good working relationship with the various delivery staff to provide you ad-hoc info about the environment. Of course, the ideal situation would be to position the dynamic information that you need to be available automatically via some reporting engines, removing the need for the access or constantly bothering administrators, but my experience is that setting that type of thing up often is more complex and fraught with hurdles than simply bugging someone to get you the information.
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.
Funny that you say that. As we all know Columbus discovered America (leaving earlier civilzations out of it for the moment).
Only he didn't. He thought he was in India. Later he thougt that he had discovered a new group of Islands. Who did first prove that an entire new continent was found (and gave his name to it)? Amerigo Vepucci. Did he physically visit the continent he 'discovered'? Yes! But only after he had deduced from information of others that there must be a new continent.
So you new role (and adapting to a new role is hard, so think about it) is not to go on a bold new expedition but to sift through the information you request from the different teams and build a global picture from that.
Also a concern for me is: you talk only about network, virtualization, databases etc. While an EA is also much involved in the design of the application landscape, data architecture of large projects, reporting infrastructure etc.
So, if you take the leap, let go of the low level control and widen you horizon.
fyi. I've done both EA & sysadmin roles at different times.
This should be the norm for a EA position, who acts more as a consultant in relation to stakeholders' needs.
You may ask for your own isolated playground if you need so but, what exactly do you need root access for in this role?
Why exactly skip the, intentionally slower, "sudo" step?
I made this move in a previous company where they were far too traditional in their thinking. The number of blunders they made to their detriment were shocking, but it was largely a case of "this is how we've always done it". There can be a political minefield here - it is important to navigate properly.
When it came to the networking side of things for example, I never asked for access to the switches and routers themselves. I performed an audit of the network documentation, helped the team develop configuration standards, worked with them on comprehensive diagrams - doing as much of the work myself without touching anything, sometimes just reviewing copies of the device configs. This is key as they remain invested, they are your eyes and ears in the environment, but don't feel as though they are being burdened with extra work or doing anything "wrong". What you really want access to is to any sort of network monitoring software that can give you deeper insights into the underlying infrastructure. Leave the "show ip int br" to those who do it on a regular basis.
With the storage, we ran in to a number of problems with our environment showing clearly that the organization had prioritized capacity over performance. Instead of building aggregates from evenly-sized RAID sets on a NetApp array (best practice), they had weird sizing, an aggregate would had 2 16-disk RAID groups and 1 9-disk RAID group, and we would run in to latency issues and performance hiccups regularly - not something that should happen on an array that size. A combination of vendor discussions and support calls identified the culprit and helped identify other problems with the configuration (fractional reserve set to 100%, LUN tresspassing, two dozen volumes deduplicating at the same time, etc) Old-school storage types do not like "new" technology like auto-tiering. I work for an EMC reseller now and have fixed many customer issues simply by letting the array place the data where it needs to go rather than rely on someone's estimation of data placement - you are paying the bucks for the array software after all, let it do it's job and things will be much better for you.
Security is a place where outside consultants are regularly used, especially if you have a web presence. Working from the perimeter or cloud/hosted infrastructure backwards in to the data center and user environment, develop a security plan and review it with the team to try and find holes in the coverage. If there are things missing, try to find out why. Is it a lack of resources? Money? Skillset? Does the organization consider complex passwords, anti-virus, and a firewall "good enough"? Is security engaged with storage, network, and server teams to lock down the devices to make sure only the appropriate teams have access to their toys? There are so many aspects to security that no one security analyst can possibly know them all - help them identify where they need help and get them the help they need to succeed.
Developing training plans is another way of being able to get things changed for the better. You aren't calling anyone stupid, you are trying to advance their careers and add additional value to their presence. You will also be exposing them to best practices that they may not even be exposed to regularly. You could simply pay a consultant to come in and tell everyone what they are doing wrong but it is so much better to have change initiated from within, which you can then directly attribute to an individual and their training experience. This has happened so many times for me and it is extremely satisfying. I sent a junior admin on SCCM and SCOM training for a couple weeks and when he came back I sat down with him for a debrief - the outcome was a number of change requests and mini-projects which resulted in improvements to image deployment, workstation management, server monitoring, patch management, and a number of other things. We were able to calculate how much time he saved the help desk folks over the course of a year and show that to managemen
I'd have to say I'm happy to not be working with most of the pin heads who suggest that hiding the internals of the infrastructure are in any way appropriate. You should have the keys to your kingdom. End of story. Go find another job where they trust you and treat you with respect.
I totally disagree with some of these other comments about not having or needing access. As the Architect it is your responsibility to know what is in the system. If any big issues come up the other executives are going to ask you what happened.
I spent time in just this same situation at a large power utility. They wanted the Architect to spend all day writing documents so they could have a political debate on things like: is SSH is needed. I pushed hard for access to systems and I received it. What I found was terrible. The people who were supposed to be operating the network weren't. There were lots of disconnected systems and unavailable services. It was really bad. They were trying to hide visibility of the networks from anyone who actually knew what they were doing. The protests were loudest from the Director of IT who was trying hard to prevent himself from looking bad.
Read only access doesn't really give you good information. It can be painful to set up and generally doesn't give you access the information you are looking for. At a minimum you should have access to all the monitoring systems. How else are you going to know what is currently in place to plan for future designs?
Don't fight. Make your diagrams, make your plans, make your reports and recommendations, gently push for more access, do the best you can under the idiotic conditions. Don't make waves, stick with it for 18 months, then jump ship with with your shiny new resume item to a much higher paying position in an organization that respects you. If it matters to you, you can always return a few years later at a higher level later with actual authority and put things right. They will love you because you didn't make waves. You probably won't care about them any more.
When all you have is a hammer, every problem starts to look like a thumb.
And, why I left it last year. Wrong-headed top-level management will forever hamstring a company's IT infrastructure. Let Darwin do his job; in the mean time you might want to look for a more progressive place to work.
The organization is a moderate sized (~3000 employees), publicly traded company with a nearly $1 billion market value.
I'm not going to do the research myself, but I bet you could figure out exactly who he works for from this data. Glad he's not being made the Customer Privacy Czar.
You're clearly a technical guy that's used to having his hands in the guts of it, so to speak. You have to learn to be able to work with a degree of separation through other people. It's extremely difficult and takes an entirely new set of skills that you will need to continue to be successful. You have to learn to trust (but verify) other people.
Personally I don't find it nearly as fun as doing it myself, but it's much more lucrative and allows you to have a much broader impact in the organization. You can only do so much directly, by yourself.
...for the title, wait six months, then start circulating your resume to more enlightened companies.
I've done major consulting contracts with companies like the one you describe. They're fundamentally flawed and broken and will eventually implode. Try to find a new position in another company before the do.
Good luck!
If the org is structured to where the architect role isn't directly involved with the configuration you should still get read only access or have the ability to see how these systems are setup or functioning somehow. You should not have to bother dozens of people on and off over several months to get the details on how these systems are set up and you should be able to verify these things on your own as needed. If it were me, I would present a list to my supervisor of all the the things I'd like to check and the potential recommendations/improvements I'm going to make. That way he/she will see that I need a lot more information on these systems and that having to constantly go to the busy admins for all the information would be a very slow inefficient process. How can you make or verify documentation that is accurate without the details? I wouldn't push it too hard, but get all your data together to make your case then present it....but still be ready for an answer you may not like.
I was Director of IT for a company that then got acquired by a very, very large organization. I became a principal architect for that large company as part of a team of 4 people that were tasked with architecture for all internal IT projects.
On paper we had no privileged access to the environment we were working with. We had to rely on asking questions for the day to day sysadmins and trust that the answers we were getting were correct. Depending on the sysadmin this this either worked well enough or was a train wreck. Some sysadmins just gave us the access we needed and said have a nice day.
The real problem was the architects scoped out the project but had no access to hardware to do POCs with, so all of the architect work was done via white papers and vendor responses to RFPs. There was shockingly little POC of products.. Just "well this vendor said they can do it so here's some money...". This resulted in the architects making unproven decisions and then throwing the products over the wall to the technical teams that then had to implement those unproven decisions. Unsurprisingly this led to a lot of implementations that did not go well as unforeseen problems arose and the inevitable finger pointing between sysadmins, architects, and vendors began.
In short it was complete train wreck. Given the way the rest of this large company was ran, I wrote it off to it just being one of many examples of the company being, frankly, shit. I left them for a senior engineer position at another large company, and have found that this companies architects working in very much the same way.
So... I don't know if this is just the norm, or if I happened to join 2 similarly laid out companies, but I don't feel that this way of treating the architect group makes a lick of sense.
Depending on how your environments are configured, I would think that "view" (read-only) access wouldn't be a terrible thing, but giving the architect write access, especially at a root/admin level is NOT a good idea (for similar reasons to why devs shouldn't have such access).
So the question becomes: how do we give him/her enough access to be informed and effective, but not so much that it is likely to allow problematic changes.
There could be a few ways of this. In many cases, there are management or monitoring systems with management UI's on which you can create accounts with view-only access. For example, in many places I've worked, there are one or all of the following:
* A network management software which is capable of listing all known managed network devices and returning logs or configuration details for them (without allowing access to change)
* A software/package management system capable of tracking all licensed hosts (e.g. satellite/spacewalk for Linux, or perhaps something tied to WSUS in the windows world) and the software/configuration of those hosts.
* Monitoring software which tracks the status of running applications/services/devices, and generally knows at least a little bit about the underlying OS versions, hardware, and various applications installed
* An asset management system which tracks stuff like hardware, OS, location, ownership, etc of physical and virtual hosts
That gives several points where one could have a limited-access account where one can pull up the information needed to build a fairly decent picture of how things tie together, but without giving somebody the temptation of being able to actually change or tweak things him/herself. There may be some fine details that aren't immediately apparent with the above, but that's why you have the fifth option
* cultivate a mutually beneficial/respectful relationship between your devs, architects, security team and admins.
Seriously, the "chain of incomplete/disaster projects" is almost never on one guy, but due to a breakdown of communication between layers. By cultivating a good relation between the levels of staff, you not only have people who are willing to donate some time to getting the information you need (or considering the changes you propose), but often bring important stuff to you for advise/advisement before you even have to ask!
So yeah, you should have lots of access to *see* what's going on in a global sense, but not to *change* it (except on paper/design). Access to the noted systems is going to be helpful with that, but having strong ties to the right people is the real trump.
It may just be how things are phrased (and to be fair "ask slashdot" often comes off as better describing ones frustrations than relations), but at the moment it sounds like you're not doing particularly well at the communication bit or at relinquishing control. Don't be a one-man army... even if you do get the access it'll just lead to you taking all the heat for issues and/or burning out.
Ask to have at least one high level admin who has to drop everything and get you the information you need when requested. Sometimes that means sitting with you while you look over the system through them. Of course, there will be times they cannot drop everything. If the server is on fire you will want them to put it out first.
.. that has bought into the whole cloud thing.
in my experience cloud has been less stable, and more costly (because of the loss of productivity due to outages) than in house. .. and we sure as hell know that going cloud = pretty much give unfettered access to your data to both government and the hackers that target those services.
forward deployed fleet command surface groups have an admiral aboard the designated command vessel
Hi. Posting this anonymously for obvious reasons, so people please vote this up for visibility. I actually do still have a five digit id, I've been around here a long time. ;)
I have been an EA for very large public sector and private sector entities for most of the last 10 years, with a background in solutions architecture, applications and infrastructure for another 10 years or so before that.
The first thing I'll say is it really sounds like your EA position is not actually doing enterprise architecture, but is more like a very hands on "chief architect" position. This is unfortunately reasonably common. More like a "lead architect of the enterprise" position. However, it seems like this is the sort of position you want - you want the authority to make sweeping technical decisions and gain control to do things right. I commend you on this.
True EA is pretty much technology agnostic - it deals in technology strategy, supporting the business strategy, and enabling business transformation. In a nutshell, it's about taking a business strategy, articulating it in terms of changes needed to the people, skills, processes, architectural capabilities and so on, and then roadmapping those changes. An EA deals more in principles, standards and governance than actual technical implementation details. You would state the technology strategy, then ensure the actual implementations follow your principles through your governance process - that is the meat of an EA position.
I think you need to forget about the "enterprise architect" title and really look at the job description and the political landscape you will be entering if you take it - will you have the authority to make the changes you want? Will you have the power to make people do things the way you want them done? And what battles will you be fighting? EAs usually battle mostly at an executive and programme board level.
If this is as senior a position as it sounds, it should be appointed by (and report to) someone incredibly senior like a CIO. You need to engage with them directly and tell them the exact tools and authority you need to do the job you want to do. Get it codified in your job description. If they're willing to give you the tools you want, you should be able to do this well.
Good luck!
As the Enterprise Architect, you really don't need to have rights to Production environments. That's a huge lapse in governance. However, you should be able to romp freely in some other environment. Those who do nothing but create drawings of right-angle spaghetti and square meatballs in Visio but can't actually do any of the stuff, aren't architects.
Thank you everyone who took the time to respond to my question. Reading the responses has been very insightful and a bit humbling.
I appreciate those of you who called out my tone, pointed out that I'm a whiner and even insinuated that I am not qualified for the position. What would an "Ask Slashdot" post be without one or two snide comments along the lines of, "If you have to ask slashdot, you're obviously an idiot."?
I came to the community as humbly as I could because I realized that my own ego was likely getting in the way, my understanding of what the position is might be skewed, and needing a reality check. I got it.
There were way too many questions and comments along the way to address them all individually. (tl;dr feel free to skip the rest) I will try to respond to most of them here. I hope that by providing some background about my professional experiences and how I got to where I am, others who are on a similar path will gain some insights.
A lot of people had questions about the company itself, its size, the VM to user ratios, infrastructure and other questions. Without spending all day writing about it, the company is included in the Russell 2000 Index. That makes it "medium" sized here in the States. It is a consulting company and we frequently bid (and occasionally win) jobs for the same organizations that KPMG, Deloitte and PriceWaterhouseCoopers go after. My five years at the company have been spent working in the legal technology segment. We provide electronic discovery services to some of the largest organizations in the world. Most of the VMs are application / processing VMs that churn through large batch jobs. (Think producing TIFF files of tens of millions of emails, Office documents, etc. from a large corporation involved in a dispute. Think Enron. Getting caught rigging LIBOR. Creating MBS products that send the economy into a recession...). We also have a number of SaaS solutions for that market.
The IT organization has an ITIL compliant change management process. I deal with auditors frequently. Due to the nature of litigations we are holding onto reams of personally identifiable information, confidential information, privileged information. We deal with large financial sector clients who are subjected to all of the regulations. We deal with health care clients who are subjected to all of the regulations. As irksome as auditors are, I have found that they truly do help us elevate our operations and we have been able to use audits to get capital for systems that we otherwise would have never been able to justify on our own.
When I say that the IT group was traditionally internally facing, they were. They deploy laptops, manage remote offices, keep Exchange running. Their customers are internal to the business. The prior CIO (who was moved out a few years ago) failed to properly size the "cloud" (kill me now for even using that term). Our operations completely outstripped the resources available and required millions of dollars of additional investments in storage (primarily) and compute resources. It was such a large investment that there were even rumors of the business divesting itself of the practice entirely rather than spending the money.
Before I got to my current company, I was a consultant in the (truly) small to medium sized business (SMB) market. (1-250 employees) In that life I was the primary IT resource for small companies where I did everything from design to deployment to operational support. I worked with everyone from architectural firms, to city governments, to waste management companies, 501c3 non-profits, air freight shippers, restaurants, manufacturers (things are still made in America?!?) ... a very diverse client base. I have been working with IT systems professionally since 1996 and using and building my own computers since the early 90s. (The first computer I built myself was a 486DX2/66. I am not as grey bearded as some here, but old enough to have used a 2400 baud modem and
Why are they not giving you access? What is their goal with that?
Honest answer... not what they say but why they're actually doing that.
Then...
Why do you want access? What is your goal with that?
Honest answer... not what you say but why you're actually doing it.
State those two to yourself and you should be able to figure out a path forward.
I've decided to stop wasting my time responding to AC trolls/sockpuppets... so if you want a response from me... login.
Anyone who thinks they need root/admin access to do their job probably doesn't, and to be blunt, just asking when it's clearly not needed is a very questionable thing for someone applying for an architect position.
You never want more access then you need to do your job. Ever.
Rather a moot point, don't you think, since you just fired yourself...
Yes. I have root or root equivalent on all company-owned equipment. In the instances where vendors did not grant root access to systems they sold us, I cracked them and gave myself access, with the full knowledge and prior permission of the company's CIO. You cannot audit or analyze a system without full access.
In an organization like yours, where the performance of the chief architect has been visibly unsatisfactory, it is probably normal. In my organization I am trusted not to abuse my privileges, and trusted never to change anything without informing all relevant parties, so nobody minds that I have the ability to monitor and analyze everything that's going on everywhere in the infrastructure.
You have to build trust. I recommend that you never, ever change anything without discussing it with responsible parties first (you don't have to follow their advice, but you have listen, and then you tell them what they are required to do, and don't just do it for them) unless it's a critical emergency, and if you make emergency changes you have to make damn sure that every interested party is informed afterwards of why and when and what you did.
You're asking for them to place absolute trust in you. They won't do it unless they think you deserve it - not as a technical expert, but as a person.
Unless you are an officer of the company (director level and up) Sarbains Oxley states that you should have full access to the resources/items that you are architecting. This ensures propper management, development, and accountability.
If you dont have access to these resources, whom does and why? I am unclear as to the justification for the segregation.
once bit twice shy does not fly here..
I would discuss the fact that it would seem that effort of segregation is very counter productive resulting in a decrease in the effectiveness doing your job and thus ultimately affecting the company in a negative manner..
various individuals within this thread have also stated "flawed, broken, unclear" Hallmarks of Bosses whom are looking to take advantage of a situation or various situations, perceived as all for the greater good.
I would get what you can out of them and move on.. With that sort of proposition its clear they dont value your contribution to the position @ hand, nor to future projects relating to the position.. It almost looks like they are looking for a SCAPE-GOAT to pin the previous failures on.
I think it seems that they are all Su*king c*ck for coke, and hoping you'll play the game with them as well.
Lame,
That the past architect was unable to get some things to scale or work well may be indicative of how you will be hamstrung in the same environment.
While it is best to not have admin access to everything in I.T., that can also result in designs/architectures that have missed critical requirements which were unknown at the time.
haha yeaa and i have a keymaker position for you..
As an architect you should only have read access. It's not your job to fix shit, it's you job to design shit, then when it isn't implemented correctly, diagnose the points of failure in the process; not the code/OS/switch/router itself and make the implementer fix it.
"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."
This small put is symptomatic of a larger issue of how the architecture role is seen in the company. Unless you are prepared to constantly battle to win hearts and minds, which will occupy the majority of your time (instead of producing real value), run away fast.
Architects who are kept isolated from the hands on activities in the long run are the ones who become divorced from reality and harm the organization. No you shouldn't be administering the systems on a day-to-day basis. Hell yes you should still be connected to the ground level.
This lack of understanding from the company is a large reason why Enterprise Architecture is fundamentally broken.
http://www.forbes.com/sites/jasonbloomberg/2014/08/07/enterprise-architecture-dont-be-a-fool-with-a-tool/
http://www.forbes.com/sites/jasonbloomberg/2014/07/11/is-enterprise-architecture-completely-broken/
He was on the Enterprise for the Midway operation, but the Enterprise had its own captain, and Spruance gave orders to him as well as the other captains.
Later in the war, he liked using an older heavy cruiser as a flagship. Big enough to hold a flag staff, pretty sturdy when under attack, fast, and a small enough part of the force that he could go where he liked and attach himself wherever without messing up the force deployment.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
"It is like asking someone to draw a map, without being able to actually visit the place that needs to be mapped"
An EA doesn't have to visit the place. An EA draws the map and then says "The land needs to look like this"
When you reach your final form you will realize that there is nothing special about production.
In your dev and staging labs you will auto provision a scaled down version of production infrastructure and validate with automated tests. You will deploy to production with confidence.
I've been with company's that give away full access way to easily and others that hoard it like a miser. Neither is right nor wrong (although too much access given to too many people would make me extremely nervous) and depends on how the company operates. Being in a similar position as the OP, I'd want full access to everything. If the company is hesitant, have them make you sign a security agreement. If they won't go that far, take what they give you and work with that. Eventually you'll get full access through need in my experience.
In WWII, basically all the admirals were often on some kind of flagship.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
mod parent up informative
mod parent up informative
mod parent up informative
I would NEVER accept a position as an EA specfically because that position is entirely political in nature and rarely is effective in doing anything except presenting buzz words to the CIO/CEO while simultaneously alienating the entire IT workforce who KNOW better what will actually work.
Dump your EA's, and stop thinking IVORY tower will solve everything.
Beyond that, I've seen persistent problems with some architects. They need to at least understand the operational and administrative environment. If they do not they wind up bypassing or ignoring standard tools and best practices in those domains.
For example, database backup systems. Use them. Do not reinvent the wheel! At best you will waste huge dollars and do a worse job than the standardized db backup systems. At worst you will destroy yourself and your company. Yet I've seen architects do this because they appear to be clueless about best practices in the dba world.
This does not mean you cannot have another backup layer. I found it highly appropriate to do so in fact. Enterprise (non-db focused) backup systems are suitable for bare metal restores, while database specific backup systems typically cannot do this at all. Note however that this is a different use case, it will be used less often, and backup cycles should be coordinated so as to be non-conflicting.
Just make sure you get along well with the admin. When problems occur you can look over his (or her) shoulder.
No, I will not work for your startup
If you're not performing an operations role as well, and you're doing design and strategy you shouldn't need access to the environment.
You know you are being paid to be the second to be blamed after sysadmin. You also know that money don't care if there is gravity in this planet. I do not need to mention that you like to not being able to handle this cause its a lot of money. But I need to mention that you don't have time to spent that money. And that's all the reason why people giveup being CEO or worse, make "mistakes" being CEO in order to run own non-profit business. What stakeholders have in mind is always a company that has so strong muscles that inertia would not allow the brain to have other choice. But the brain always have a graham number of choices, so if you touch what you can't touch by hacking enterprise you are in trouble by choice.
+1 The EA does not want access to ANY systems. That is not the role of an EA (or ANY architect to be honest).
The job of an EA is to be the bridge between the business and technology. You should not have enough time to be 'on the tools'. You need to be building relationships with the business and finding technology solutions to their problems.
Get yourself on a TOGAF course. You are lucky that the company does not realise that you are probably not actually qualified to the role of an EA. You sound like someone who knows technology, but I am not sure you understand what is required in a strategic role.
+1 The EA does not want access to ANY systems. That is not the role of an EA (or ANY architect to be honest). The job of an EA is to be the bridge between the business and technology. You should not have enough time to be 'on the tools'. You need to be building relationships with the business and finding technology solutions to their problems. Get yourself on a TOGAF course. You are lucky that the company does not realise that you are probably not actually qualified to the role of an EA. You sound like someone who knows technology, but I am not sure you understand what is required in a strategic role. (submitting as me, not as anonymous)
Unless I mis understood you r question my answer is not to give you admin rights into production systems... Access is a major audit red flag under division of responsibilities.. System in should be able to provide metrics and performance data to enable you to carry out your responsibilities. If you need hands on get access to test systems.
a commodore may also not be in charge of the ship itself. At least in the Royal Navy. I'm thinking of Commodore Harwood who was in charge of the cruiser squadron that engaged the Graff Spee in the battle of the river plate.
I also know that the Royal Navy have a Captain (D) role where the senior captain of a destroyer flotilla is in command of the flotilla as a whole.
I may watch too many old war movies as well, but that is a side issue.
First off, ignore suggestions that you are being given authority without access. For an architect, your access is through the people who have the system rights. You are going to move from "fingers on keys" to "speaking to people." It's the only way for you to scale, and if you cannot scale, you will not be effective. Secondly, welcome to Enterprise Architecture. I was promoted to Enterprise IT Architect over 15 years ago. It was a bit frightening because I was no longer in the position of "pushing IT to make it work." Now, I was in a leadership position. What saved me was good people to ask and provide advice. I screwed up more than once, and I've learned from both my successes and my failures. Seek out a mentor in the EITA community. Get TOGAF certified and leverage the various associations. There are a couple of conferences every year on Enterprise Architecture as well. Third, I'd like to make a small distinction between Enterprise IT Architecture and Enterprise Architecture. Right now, you may not see the difference, and that's OK. But as you mature in the role, in a couple of years, the distinction will become more clear. You are currently a technologist and you are about to be asked to lead to best practices in your technology practices. That is EITA. However, once you've put out the forest fires, you will find out that most of those fires are being started by business decisions that are disconnected from the knowledge needed to execute them. If you work to build trust with your non-technical stakeholders, you can become a key resource for helping to vet business decisions, priorities, and timelines. You will become more involved with helping the company to move towards their strategic goals, not just fixing the practices in IT. The real value of Enterprise Architecture (not EITA) is to help the company change the architecture of the entire enterprise. Not just IT. It takes a long time to get there, so don't be surprised if you are not ready, and your company is not ready, for that level of interaction. You can get there. I know it's possible because, after years of struggle, I got there. And my company was a good bit larger than yours (Fortune 50). (I've since started my own consulting practice to help mid-sized companies like yours to address EA challenges). You are just a few years younger than me, so in many places you are today where I was about ten years ago. It's a fun and challenging path, and one that is not easy to describe. I recommend reading the "Perspectives on Enterprise Architecture" white paper from the Federation of EA Professional Organizations (FEAPO). In addition, the same organization will be release a "Guide to Careers in Enterprise Architecture" in a few months (it's been in process for over two years). That will give you an idea of the competencies that are needed to be effective as an Enterprise Architect and how you can grow in your new role. LinkedIn has many discussion groups specific to EA. Join one. And welcome to the profession of Enterprise Architecture.