How to get hired as an Enterprise Architect in 2021

We know that Enterprise Architects are in demand, but what do they do for a living?

Enterprise Architects commonly experience an identity paradox, rooted mostly in the phenomena that the only members of an organization who seem to define Enterprise Architecture properly are other Enterprise Architects.

This acknowledgment is not intended as a criticism of business software at large. Certainly, the evidence would suggest that software infrastructure patterns are working and winning. System complexity increases as our business and consumer technologies become more ambient. Yet, the pace of software innovation surges forward, suggesting that Enterprise Architecture as a discipline is more important and widely practiced than ever before.

Perhaps it is this speed, and then the need for elasticity in the role, that makes the definition so difficult for organizations to pin down. Or maybe it is because Enterprise Architecture is a playbook, rather than a textbook, and one that changes to fit systems that fluently adapt to the increasingly hyperactive needs of the market.

If Enterprise Architecture is a playbook, then we can find commonality between modern Enterprise Architects, or at least some overlap in the patterns they employ in their day-to-day work. In service of this ontological study, I recently interviewed several of my fellow Enterprise Architects (EA) at OpenLogic. I wanted to zero in on the real, field-level responsibilities of an EA in today's landscape of accelerated DevOps (and its derivatives like DevSecOps), open source everywhere, and an industry barreling to the cloud. I asked each EA the same four questions:

• What is the difference, in your mind, between a Senior Developer and an EA?
• What is unique about being an EA who builds with open source primarily?
• What did you focus on to become an EA?
• What was your 'aha!' moment when you knew you were truly an EA?

I'll share their responses and what I've learned in listening to them to provide some insight into the practices that shape the integral work of Enterprise Architects in 2021.

What's the difference between a Senior Developer and an Enterprise Architect?

"One of the main [differences] is the outlook and the view an Enterprise Architect has over the enterprise is very different than the mindset of a Senior Developer, or subject matter expert," says Shuddhasatwa Bhatthacharya, Enterprise Architect at OpenLogic. He continues, "In a single project, a Senior Enterprise Architect is looking at not only the stuff, the ivory tower stuff. […] They are the spinal cord for the entire enterprise and understand where the enterprise is in terms of architectural maturity. […] Now, that is very crucial. And I don't think it would come across the mindset of a Senior Developer all that easily. It takes years of I would say, experience, where maybe you are not even a Senior Developer in all the projects, but maybe you're just providing technical oversight, or a lead architect, and you slowly come into this realization that every single character that we type on the keyboard that makes it into production, is of consequence."

Joe Carder, another of OpenLogic's Enterprise Architects, follows on with this theme of broad enterprise awareness, saying:

"I think the biggest difference would be that a Senior Developer is going to be developing on their area of expertise. They are going to be looking at their domain specific knowledge and apply that to a specific application, or even a group of applications, to provide a complete service. It could be that a Senior Developer will work on the shopping cart of an e-commerce site and the catalog. And they are going to be responsible for developing that. But the Architect, the Enterprise Architect is actually going to be looking at how all the applications play together."

Carder goes on to explain a little more concretely, adding: "For instance, how does the shopping cart interact with the catalog, interact with the checkout function and look at the holistic view of all the suites of applications and not just the e-commerce suite, but how are we funneling into our ordering system and how are we continuing from there?"

Joe adds that this particular example is really just in the context of where an Enterprise Architect provides value to an important project. Enterprise Architects also contribute to the broader strategic vision of a company. Carder explains:

"The Enterprise Architect has to consider how each change is going to play within that realm, and then not only for what they're doing today but where are they going tomorrow? How are they going to be moving into a microservices architecture from the monolith that they have now and have that 5-10 year roadmap down the road?"

Connor Penhale, also from the OpenLogic Enterprise Architect team, rounds out this thinking succinctly, stating, "An Enterprise Architect has an ability to understand a business problem."

Expanding on this point, he juxtaposes this to the mindset of the Senior Developer:

"The EA fully understands, where the people that have procured them, the people that have come to them and said, 'Look, you know, we have this problem,' the reason they came to him and not the Senior Developer, is they're not [just] going to hear about the technology, they're going to hear about the solution. They're going hear about 'How do we take this business problem and solve it?'"

What is unique about being an Enterprise Architect who builds with open source primarily?

Carder speaks about how open source provides tactical advantages and the ability to deliver low-friction or frictionless solutions to customers: "I think the coolest thing about it is my hands aren't tied," he says. "I can look at any project that's available from any corner of the Internet to be able to accomplish the mission that I'm trying to accomplish for our customers or for the business."

It's not all rosy, though, Carder clarifies: "By the same token, the worst part about it is I can choose from anything. So, my hands are tied in that there can be too many options available to you."

"You can kind of get to perfection paralysis like this isn't quite exactly right, and you can spend a lot of time going down in the weeds. So, I think one of the biggest benefits, of course, to open source is it's free and available, and there's a lot of it, and it's open. It's so malleable and you are able to change it and get it to do what you want it to do, but it's also so malleable that you can change it to the point to where you're doing stuff that it was never meant to do, which can be a problem. So, it's a walking that fine line is probably one of the biggest challenges for an [open source focused EA]."

Penhale looks at the cost savings of open source software as something that can increase his value as an EA, delivering powerful solutions for relatively low cost to his clients.

"Pick your big ESB (Enterprise Service Bus) that, you know, someone might make $10 million on a deal for [implementing], I mean, these are huge products," he says. "There might be teams out there that are making just oodles of cash doing that. That solution is a three-year solution that takes two years to build."

"The idea that I can have a Maven archetype that spins up three quarters of my solution in 20 seconds, and I've never even written any code, I've got the blueprint for something that's just open and ready, and I've got […] instrumentation and everything else, an ecosystem, and it's free, is so valuable."

Bhatthacharya zeroes in on the inherent reliability of software that has been put through rigorous paces by enterprises. He argues that there's a lot of faith we can place in the software's function, assuming it's a widely accepted piece of open source software.

"[We can realize] freedom without a doubt since this is open source, and particularly for popular products, these are being used all over the planet, in all kinds of circumstances. So, obviously, the chances are, that there isn't anything super critically wrong, that would prevent the end user from using it properly."

Bhatthacharya then compares this freedom with non-free software. He says, "Just imagine some of the stuff that we have to integrate in a corporate setting, where you have patents and trademarks, and all of that, it's very difficult to be able to move at the pace to efficiently integrate."

What did you focus on to become an EA?

Penhale doesn't hesitate in answering this question, as the path is clear to him:

"My advice to anyone that wants to get to get to [Enterprise Architecture] headspace would be to go talk to your boss and ask, 'What drives our business unit? What problems are we trying to solve outside of these tickets that are assigned to me? Or outside of you know, these burn-downs in my Agile chart here?"

Bhatthacharya validates this sentiment, painting a wide, concentric scope for Enterprise Architects:

"Well, ideally, a senior software developer would have to adopt a holistic view of the enterprise, and would have to understand the issues in play, in terms of not just what's the code that is executing, but how is the end customer impacted?"

I draw on an old platitude here, asking him if he means that we, as Enterprise Architects, need to be able to see the forest from the trees. Thankfully, his response is much more interesting than the question. He continues:

"There will be the beetle on the bark on that one tree, but you will have to look at the entire forest, and literally beyond the horizon. Even in our Professional Services roles, when we are suggesting products, we do have to look at what is the end of life of that product."

Carder rounds out this thinking, providing perhaps a more concrete story of his own rise into the role of Enterprise Architect:

He explains: "My background is network engineering and system administration, and I kind of fell into [Enterprise Architecture] in the mid-nineties, early-2000's, when application servers were starting to become a big thing, everything from commercial Microsoft to Tomcat. JBoss was just starting to first develop and there was a big need to bridge the gap between the system administrator and between the developer."

"I found myself just falling naturally into that slot where I was running the application servers. I was checking them out, scoping them, optimizing their performance, basically architecting the application server side of things," he reflects.

"But to do that, I had to really understand what the developers were doing. So, I focused on that middleware layer and just kept doing that for 10, 15 years until you called me one day!" musing over the time I hired him. We both give a little nostalgic chuckle at that.

What was your 'aha!' moment when you knew you were truly an Enterprise Architect?

"You know, I didn't realize it at the time, funnily enough," Carder begins. "Looking back five years later, I was like, 'wow,' that's some serious architecture kung fu that just went on there to make that happen. But when you're in the trenches, it's just you trying to get your job done, trying to get turned around, trying to get work done. There is a project that I did a long time ago where we were doing geographic failover and we had to have some, you know, sub-three-second session transfer from Chicago to Detroit."

"It was centered around Tomcat and [proprietary databases], and I was architecting not just the Tomcat side, but the racks, the network, everything, and at the time if you would have asked me, 'What's an Enterprise Architect?' I wouldn't have been able to answer that question. I'd never even heard of such a thing. You know, I was like twenty-two, twenty-three," Carder remembers.

"Looking back on it, once I was done, we did our follow-up tests and for the failover test I unplugged all four of the racks, power supplies and we just totally powered down the rack to see what would happen. And sure enough, everything switched over to the Detroit Data Center. We had no data loss and it was one of those true moments where I was like, wow, this was something cool, this was something impressive. But at the time, I never would have thought, hey, I'm an architect now. But looking back on it, I could see that that was something that was very architect-worthy."

Bhatthacharya echoes the sentiment that sometimes progressing to the architect's role just means having the right skills to seize on a moment in time. To recognize an opportunity to showcase your talent and take yourself perhaps a bit out of your normal role and comfort zone. Bhatthacharya reflects on such a time in his career:

"You know, it's sometimes by happenstance, sometimes otherwise," he says. "I can recall a time about almost 25 years back, I was doing an integration project and we were trying to understand the semantic and the syntactic connotations of the nouns and verbs in a canonical environment. Before I knew it, I was already part of a consortium, a worldwide standard, which advised about 400 companies at that point of time to help design the ontology of the subject matter. And the subject matter was very cool. The subject matter was 'customers' and the interaction customers have with the organization."

Penhale notes that Enterprise Architecture expertise often evolves from an organic business need for a central source of truth and technical direction. Sometimes, this level of knowledge is gained by understanding every detail of a set of interacting systems, more so than any others in a business.

He tells me: "I was at [a Telco services company] many years ago. My role was at the time a Tier 3 technician. There were like three people in this Tier 3 team, and they supported everything, the buck stops here between, you know, a whole global support organization."

"Some pretty high-end developers were working on some code for telephony, we were in the business of selling some really expensive installations, you know, $2-3 million individual bids, to some really big companies," he continues.

"When they had an outage, it was literally the CEO calling you, 'My boardroom doesn't work, what the hell is happening?' Or the largest insurance company in [country], calling us at four in the morning saying, 'We're going to stop doing business with you and move to [a competitor] if you don't solve this in the next two hours.' Right?"

"We need this working so we don't have to get on a plane, to fly to wherever to have this board meeting, you're delaying our board meeting, hurry up!" he reflects, smiling.

"When I realized I was an architect is when other groups started coming to Tier 3 and asking for solutions. Like, 'How do we do this?' When the developers are coming to Tier 3 for solutions, it's a good sign for a business, because they're delivering the customers' direct needs to the development group. Moreover, it is indicative that Tier 3 doesn't necessarily mean support, it can mean something that's used to doing that transition between customer and developer or between business and developer."

Indeed, the industry-standard definitions of Technical Support bear this out, describing the position of a Tier 3 technician:

These individuals are experts in their fields and are responsible for not only assisting both Tier I and Tier II personnel, but with the research and development of solutions to new or unknown issues.

_Source

Conclusion

While the role of Enterprise Architect may have changed tactically in the last decade, the value an Enterprise Architect provides to an organization dealing with software at scale remains largely the same. Enterprise Architects provide clarity and holism to projects and act as a trusted conduit between senior technical resources and critical non-technical roles. Moreover, Enterprise Architects have an opportunity to give influence and guidance outside of their organization, increasing the market value of that organization just by being a visible asset.

The widespread availability of free and/or open source software has only increased the efficacy of Enterprise Architecture as a playbook, with a much wider repertoire of accessible components for architects to choose from while working to solve business goals. Each of these experts has described the need to acquire quite a bit of diverse knowledge across not only the software landscape but substrate and infrastructure disciplines as well. Thankfully, at no point in history has so much free knowledge been made available to rising EAs!

If Enterprise Architecture is something you wish to have in your career future, take the time to explore the impact your role has on the business. Start asking some of the larger questions, as Bhatthacharya puts it, the ontological questions, about the larger purpose of your role within your organization and how your successes (and failures!) cascade through the rest of the business.

Be prepared to be asked about your knowledge, business, and how you maintain velocity as an Enterprise Architect. It's a great job to have.