Ask Slashdot: Advice On Enterprise Architect Position 198
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?
Welcome to the Group! (Score:5, Informative)
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!
Re:Welcome to the Group! (Score:5, Insightful)
What they're offering isn't out of the norm, though I might negotiate with them and ask for read-only access (non-root for servers) at least. I've been a network architect for a few years, and one of the things that comes with: loss of enable access to the routers and switches. Mind you, I was a data center network engineer for a whole bunch of years so I know my way around them. But the organizations would rather I "look, but don't touch". The great thing about it is: I can't be called for an on-call issue because there's nothing I can do to fix it. :-)
Welcome to needing to think strategically. Take what they're offering as a compliment and run with it!
I concur. Take the small wins (especially in big orgs), and help them make the transition. You don't need rights to anything YET. That's after you learn to trust your team to bring things into the newer enterprise model and they learn to trust you. A position of this magnitude, and the experience in performing the full migration will get you even better dollars and perhaps even CIO at a firm slightly smaller, or even the same size depending on how you play it.
If you were willing to stick it out for five years and got a major offer in that time, why not stick it out another two and see where it leads?
Re: (Score:2)
Agreed. Also I found it useful to sit with some engineers, looking through the systems and getting explanations from them and share your questions and goals with them. Beats a ton of paper every time and gets you surprising insights.
Dont concern yourself with the details, let your team(s) do their work and give them credit for it.
(BTW: If you ask to sit with them too often they will get you that read-only account anyway ;-)
Re:Welcome to the Group! (Score:5, Insightful)
i'd say take the position and try to grow it from there, if you need to.
if you need data about configurations, ask for it anytime you need it. if they cant get it to you in a timely manner, complain up a few times, then try to get more access.
sounds like not having to change things is a good way to not get called to fix them, however. also sounds like you are being rewarded and should accept it. maybe you'll find they are open to you doing more once you prove you can continue to handle your duties well.
Re:Welcome to the Group! (Score:5, Insightful)
Re: Welcome to the Group! (Score:4)
Agree with above. Architect is a strategic position. You're not moving the Legos yourself anymore -- you bring in your team to give high level overviews to you, you listen to where they feel improvements could be made, and you use that as leverage to make even more significant improvements. You don't need access to AD --- you get people to talk about it and you discuss possible enhancements.
Re: (Score:3)
100% Agree. EA is my new job.
I have access to a test lab. And when implementing things. And I can see all consoles/monitors. But I can't touch anything.
My new team will give me access at the drop of a hat by adding me to appropriate groups, if they feel I can help fight big ugly problems.. But this doesn't happen once a day, nor even once a month.
eSOX (Score:4, Informative)
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.
Re: (Score:3)
In an IT position without administrative rights, you don't have authority. Responsibility without authority = run away screaming.
Re: (Score:3)
Responsibility without authority = run away screaming.
Responsibility without authority = get a golden parachute in your contract. Or no go. That's the only thing that can make it worthwhile, and it's the only impediment to using you as a scapegoat.
Re: (Score:2)
In an IT position without administrative rights, you don't have authority. Responsibility without authority = run away screaming.
I'm not sure you completely understand the point behind an architecture role. The responsibilities are *different*. They're not tactical operations in nature. The role is strategic; thinking months if not years in advance, asking questions about something that no one else has thought about, seeing big-picture things (50,000-ft view) versus close-in things (1000-ft view).
Folks who can successfully make that transition get to enjoy the benefits of being an architect. One of the key benefits, at least in m
Re: (Score:2)
Indeed, but to do that they have to *look*. They have to log in to systems and see what's there. How the nuts and bolts fit together. How the computers interact with each other across what networks.
That allows the architect to ask the right questions. Why was this set up this way. Which in turn leads to achievable architectural improvements.
Without access, the architect can only paint with broad brushes, essentially providing you the same insights any consultant could deliver in a week. That is not useful.
Re: (Score:2)
erm. I can not log onto 60,000 VMs across 15000 servers, and that's just four of our data centres.
I don't want to. I don't even give a shit how they're configured.
I'm far more interested in whether they're meeting the needs of the business, the customers, the employees. I'm more interested in whether we have the right tools, processes and skills to take the business where senior management want it to go. I'm far more interested in assuring that the limited funds and resources are optimally invested to best
Re: (Score:2)
You don't need to log on to 60,000 VMs, but if you haven't logged on to any of them then there's no way you know the business well enough to suggest credible structural changes. The IT folks would then be right to ignore everything you say.
Re: (Score:2)
At which point the IT folks would get a very short, sharp, brutal and extremely educational experience.
Re: (Score:2)
Man, I'd love to work in your shop. Not.
What's the real problem? (Score:1)
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.
Worst management practice (Score:1)
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.
Re: (Score:1, Insightful)
Spoken like a clueless idiot who thinks he can do all tasks due to his divinely superior skills. Sorry, you sound like a whiny little punk with not enough experience to realize how utterly full of shit he is.
My guess it you'd be qualified neither as the architect nor the admin, but act like you know it all.
You're a fucking idiot. The fact that you think the architect is one of the "big guns" who should have the keys to the kingdom tells us this.
Once you get to a certain level of management, you don't get
Re: (Score:1)
As a sysadmin (technically systems analyst, but whatever) I'm currently in the process of trying to FIX all of the insane stuff our ARCHITECT did when building our windows infrastructure.
Our "architect", I refer to him as Castanza, or just Vandalay Industries, believes he is the be all end all of admins and should have unfettered access to every box, making undocumented changes and "testing" things on production boxes.
Example? Ok, a windows 2012 r2 server hosting citrix virtual labs and applications. RDP
Re: (Score:2, Troll)
I'm not defending your architect. He was
Re: (Score:2)
You know, reading the above I have to say I think your conclusion about open source is complete crap here.
An architect who is designing and building it at the same time, and doing stupid shortcuts and hacks in the process, is going to lead to terrible results no matter your damned platform. The architect designs, the admin and IT people build and maintain. If you design is any good, they can built it. If your design is crap, they'll come back to you.
But architecting and building at the same time usually
Re: (Score:2)
Re: (Score:2)
Great advice if you work in a pure-dev shop and the entire corporate food chain knows and likes Linux.
Career-ending advice, however, if you work in the other 99% of the IT industry and the CIO just wants the COTS ERP system to do its damned job.
I myself like and use Linux (at home), make no mistake. But suggesting someone "rewrite" the next version of thei
Re: (Score:2)
Re: (Score:2)
And I realize a bull-in-a-china-shop architect can demolish a Linux environment or FreeBSD environment as quickly as he can screw up Windows Server (or Solaris or whatever).
I was just whining about the fact that if you run proprietary applications, some of the time you wrestle with artificially imposed proble
Re: What's the real problem? (Score:2)
Yep completely rewrite everything to work in exactly the same way. That won't cost any money.
Re: (Score:2)
I just get painfully annoyed when I have to set up a server, or change a configuration file, or allow a third perso
Re: (Score:2)
Architect != sysadmin (Score:5, Insightful)
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.
Re:Architect != sysadmin (Score:5, Interesting)
Agreed. The architect should not be touching the operational system except for acquiring profiling data and layout information, which they should be able to work with the system administrator to get. They should not have "full access" like the person wants. The architect should be working in a testbed with simulated data or a copy of the live data, depending on the task at hand. Just the same as how an actual architect doesn't go onside and start welding things, they work in simulated models.
Re: (Score:3)
Re: (Score:2)
The role that everyone seems to be ignoring here is IA. Information Assurance should be the read only underlings that validate things are the way the EA thinks they are.
In summary: The Enterprise Architect needs no accounts other than that required to log on to their workstation. The System and Network Administrator personnel implement what they are told. The Information Assurance personnel guarantee to the Enterprise Architect that what was told the System Administrators was properly implemented.
For an organisation of your size - separate roles (Score:5, Insightful)
Apparently you don't deal with auditors (Score:4, Interesting)
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".
Segregation of duties (Score:4, Insightful)
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.
Sounds exactly the same as my position (Score:2)
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
Sounds normal to me (Score:4, Interesting)
Rice a roni... (Score:1)
It would be funny if he's been offered Enterprise Architect for the city of San Francisco.
Re:Rice a roni... (Score:4, Funny)
Re: (Score:2)
Metrics (Score:3)
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.
Meet the New EA. Same as the Old EA. (Score:1)
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.
No, really ... (Score:5, Insightful)
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.
From Infrastructure Architect perspective (Score:4, Insightful)
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).
Traditional internal facing IT shop .. (Score:1)
"I have been involved in a c
Re: (Score:3)
They could be doing a Citrix-like thing where everyone is logging on to server-housed remote instances. If each instance was one VMWare VM, then 3,000 employees and 1500 VMWare instances makes sense.
They could also be a company where each corporate customer, or groups of individual customers, require their own virtual server. For example: an SaaS accounting firm similar to FreshBooks may have a separate virtual server for every corporate customer, or Blizzard where groups of users have their own dungeon.
Re: (Score:2)
It seems excessive, but I've seen some weird shit.
I recently did some work for a company that had BOTH Office365 and a six server Exchange on premise system for maybe 500 users. Not a hybrid deployment, but two separate systems with some crazy SMTP smarthost configuration to make it act more like a hybrid configuration. Worse, the on-premise setup was a 2010/2013 hybrid with a mishmash of CAS- and mailbox-only servers and combined roles.
This same company had 30 VMs to support a single application. I didn
Re: (Score:2)
Advertising agencies use lots of media files and in 2001 (and probably today) was most likely doing a lot of print work, so I can well imagine the 800G of storage.
Re: (Score:2)
Managing 800 GB of storage back then was like managing 8 TB today. LTO tapes that only held 100 gigs, only 100 meg ethernet.
IIRC, only about 100 GB was really active, maybe another 50 was warm-ish and the rest was just cold data from old projects and forgotten crap, like today.
The problem was compounded by the client, a cellular company, who would come up with a promotion and then tweak it for the 20-odd markets the ad was supposed to run in. If it was a truly simple ad (which they seldom were), you would
Re: (Score:2)
As an Ops wonk.... (Score:5, Insightful)
I don't want leadership, management or anyone with any kind of oversight responsibility making changes on the live gear. That's the entire point of having an operations staff.
However, I see absolutely nothing wrong with read only access. The ability to change things - Not Good. The ability to gather information, that I would deem to be necessary for someone who's going to handle the care and feeding of the system going forward.
It also sounds like you need to clean house if your ops staff is pushing back at designed changes, however. Putting in a competent staff that will follow your dictates and provide you with the information you need would go along way to making access to the actual gear unnecessary
I wouldn't even ask for read access (Score:4, Insightful)
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.)
Re: (Score:3)
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.)
Well, for his situation, I think he needs it. The scene he sets is that of someone new to the job, the currently architected system held together with bale wire and duct tape, and a staff that's resistant to change. In that kind of situation, it's not unreasonable to insist on sneak and peek access to everything. The alternative is having to work harder to get information you need, the risk of that information being incomplete or inaccurate, and the only recourse is to blame other people. That is not going
Re: (Score:2)
Well, for his situation, I think he needs it.
For his situation he needs to absolutely avoid it. Otherwise he ends up doing his old job, not the new one.
the currently architected system held together with bale wire and duct tape, and a staff that's resistant to change
Welcome to every IT department on the planet. Get used to it. Learn how to work through it and deliver successful change anyway.
information being incomplete or inaccurate, and the only recourse is to blame other people
Of course the information is incomplete AND inaccurate. You know that's the case, even if you just logged onto the box and checked it yourself.
Deal with it. Certainty takes too long, costs too much and still results in space shuttles exploding. So stop playing blame games and
Re: (Score:2)
I don't know anything about this subject but I would be surprised if there isn't software that will catalog the network automatically.
They're position is reasonable (Score:2)
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
Comment removed (Score:3)
Re: (Score:2)
"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
Re: (Score:2)
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.
Re: (Score:2)
In WWII, basically all the admirals were often on some kind of flagship.
Access has it's issues (Score:5, Insightful)
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....
Enterprise Architect? Which one? (Score:2)
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."
Re: (Score:2)
NCC-1701J - Alternative timeline in the 26th century, shown to Archer by a 29th century Federation temporal agent.
http://en.memory-alpha.wikia.com/wiki/USS_Enterprise_(NCC-1701-J) [wikia.com]
Welcome to management! (Score:3)
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
Enterprise Architecture and Access (Score:3)
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.)
Nuts (Score:1)
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.
No, you don't. (Score:4, Insightful)
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.
Re: (Score:2)
If you are logging on to boxes, you are getting too close to operations and too far away from architecture.
This is a very good point. And failure to maintain an abstract, high level view of the enterprise is one reason that so many (poor) EAs get their panties in a bunch over system architecture and administration issues.
P.S. Errr, 1500 VM's for 3000 employees?
That may not be too far out of line. The days of one big mainframe or server handling a multitude of tasks seem to be behind us. In an IT intense business, there may be valid reasons to spawn a VM instance for each type of task being done.
Architect != Sysadmin (Score:1)
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
Enterprise architect here (Score:2)
You define the job (Score:1)
Well... (Score:1)
"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 comp
different roles (Score:1)
It's too late (Score:2)
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 com
That sounds like my job... (Score:2)
Re: (Score:2)
You dont need full access. (Score:2)
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.
Reasonably (Score:2)
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
Wrong job for you (Score:2)
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.
Authority (Score:2)
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'
Practical experience, common sense and policy (Score:2)
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? Wh
It's clear you do not understand the position. (Score:3)
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/... [wikipedia.org]
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
Give up your rights! (Score:1)
Columbus vs. Amerika (Score:1)
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 adapt
Roll with it (Score:2)
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 w
Sounds like my old company (Score:2)
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.
Been there (Score:2)
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.
Take the Job... (Score:2)
...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!
Thank You All (Score:5, Interesting)
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
Re: (Score:2)
Since I am certain you will not see my previous response to another poster, I think it would be wise for me to paraphrase the poster's response and my response for you:
Enterprise Architect should not be logging on with administrative credentials. An Enterprise Architect has two arms, Sysems/Networks Administrators and Information Assurance. Systems/Networks give you reports and implements what you want. Information Assurance validates (amongst other things). You need to do nothing in that arena.
Why? (Score:2)
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.
Bu-buy! (Score:2)
Rather a moot point, don't you think, since you just fired yourself...
I have root. (Score:2)
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.
Just make sure you get along well with the admin (Score:2)
Re: (Score:3)
A company with 3000 employees is small-to-moderate size. The market cap is impressive for a company that size, but the company itself isn't in any way considered "big".
Re: (Score:1)
Re: (Score:2)
Re: (Score:2)
In Europe that's considered a big company.
That's fair. I've worked for companies with ~200 employees, upwards of 20000 employees, over 100000 employees, and now just over 1000 employees. So my reference is skewed towards the US norms.
Re: (Score:2)
In the end your new role will involve a crap ton of meetings and moving boxes into other boxes for powerpoints.
Exactly. Enterprise Architects are not technical people. They're people people.
It's all people and politics; technology's the easy bit.
Any architecture role is 30-40% people, 60-70% technical. As you progress through the architecture roles that balance inverts, and a well functioning EA is primarily dealing with people, with politics, with budgets.
It's still problem solving. It's still fun. It just isn't logging on to servers.