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?
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.
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".
Jason Van Patten
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 guess I'm getting confused with the SME definition?
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.
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.
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.
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).
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()
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.)
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.
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.
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.
Otherwise, even for a IT company, they have the IT infrastructure from hell. I can't imagine 1500 different server applications in a company of 3,000 people.
"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
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.
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 would be funny if your comment had some context.
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.
Jason Van Patten
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".
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
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't have anything to do with that "system" but I had a hard time wrapping my brain around how that was meant to work. Not surprisingly, this company had been a mostly-outsourced IT shop for years.
10 plus years ago I worked in advertising and that was just a plain crazy business. Client business was often based in a specific agency office and each office expected to be able to run as independently as possible and given the account management and business goals and incentives, most offices had the juice to see it done that way. One office in Irvine had (in 2001!) nearly 800 GB of storage over four servers for a headcount of less than 30. Such setups were the norm, not the exception in the 4 local offices I oversaw.
The business structure abetted this -- our agency was run as a standalone company, but wholly owned by an international holding company dominated by about 4-5 major players. Most smaller agencies had management and reporting through one of the majors, and this led to all kinds of crazy attempts at consolidation of vendors, back end services and often competing cloud-like initiatives -- two of the majors had their own private cloud-like initiatives AND there was a separate, holding-company wide initiative (mostly backed by the 3 smaller majors) that overlapped with the individual ones. From what the CFO told me, while these initiatives made some sense from elimination of redundancy the biggest motivation was the juicy "management fees" that hit the revenue side of the books of the entity controlling the initiatives. We paid $100k/year in "IT management fees" to our reporting major for literally nothing other than changing large Dell PC orders behind our backs to meet their standards (shipment refused at the dock).
It was compounded by the holding company's habit of occasionally stripping a remote office from one agency and relabeling it as another agency's office to make some client at the new parent's office with a geographically local office in the remote office's city happy they had a "local office". You can only imagine the IT chaos this led to and usually the net result was that individual office locations mostly ended up being their own IT islands just to get the job done versus frequent rip-and-replace restructuring to integrate. A small agency in San Diego got turned into one of our offices and I had two senior management officials call me within a half an hour with totally conflicting directions. The head of creative was demanding maximum integration, as soon as possible, and the CFO told me not to do a damn thing but be nice as financially we would be spending $0.00 on any integration tasks along with a Godfather-like reminder of "who I reported to."
Anyway, it's not hard to see how IT can turn into a runaway train if you combine strange business structures and incentives with outsourcing.
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)
1500 VMs isn't that crazy for 3000 people when you have to use Windows. Every individual piece of software is going to want its own VM, often two or more for redundancy/load balancing, plus an equal number for the test environment, and often a few more for dev/upgrade environments. Many software packages with a server component are big cumbersome globs of many .exes that the vendor "recommends" be run on separate VMs because the developers have no clue how to write software and rebooting Windows is the first solution to half the issues. Think a 3000 person company doesn't have the necessary ~200 apps to reach 1500 VMs by this measure? There's usually several software applications that are specific to each department, and there are lots of departments: purchasing, accounting, distribution/receiving, each core business unit, HR, PR, engineering/plantops, business office, sales, and last but not least IT which is guaranteed to run dozens if not hundreds of separate apps to do their jobs. Sure; not all of them require a server, but many do, even if it's just a ridiculous license server. Data? Anyone processing video or images is just going to have a crapload of data period. Same for some raw scientific data from instrumentation. That said, it really does depend on the industry; I can imagine a 3000 person company where most employees are sales/warehouse/factory drones not needing that much software. Basically if most employees are "knowledge workers" (or shoehorned into it like healthcare where doctors and nurses are required to use atrocious piles of software to record minutia about patient care) then IT is going to be bigger than others.
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?
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.
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.
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!
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.
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.
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
Depends the infrastructure. I don't care if the company has 1 employee, if the infrastructure is comprised of over 1000 active VMs, then it's a big company imo.
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.
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.
The dangers of excessive individualism are nothing compared to the oppressiveness of excessive collectivism
I know that, you know that. But that was in 2009. In fact, I Googled it just to see how long ago it was. Hence, context was needed. Please note that my comment got modded up as funny while the OP comment wasn't modded at all. As they sale in real estate, "Context! Context! Context!"
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
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.
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 have the same base layout (Quark file, graphics, fonts, misc other stuff) times the number of markets.
Where it got fun is when the client wanted to see variations of the ad AND the way it had to change for various markets. If an ad had 5 variations, now you had 100 versions of the same ad and the graphics department never really made use of some of the storage efficiencies offered even back then (ie, graphic elements that never changed only existing once in the filesystem), so you literally would end up with 100 directories with graphics duplicated many times over.
I've noticed that graphics dedupes really well -- one client with 4 TB of raw graphics files gets 80% dedupe on that volume. Wish I would have had that back then. Between thin provisioning and dedupe, it would have made for a lot less equipment at least.
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
I guess it is a country thing but where I come from 50 employees is moderate size, 200 is big.
Oh anonymous coward, with your wisdom and cleverness, why must you hide at score: 0?
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. (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.
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.