How do I become an Enterprise Architect?
This is possibly the most common question I get asked in the architecture space. It’s one that can come from a variety of sources, which highlights that Enterprise Architects can come from many different paths. This is an important point, as Enterprise Architecture isn’t necessarily specific to any given career development path, and as a consequence, the required skills aren’t always present in an individual as you might expect if you were simply increasing your maturity in a given discipline.
The progression toward the role of Enterprise Architect is a journey. Many practitioners, although not all, will start this journey after years within an IT career. This is not surprising given the EA discipline grew out of a need to better understand how to deliver effective outcomes from IT investment. While some IT workers will be content with their role, others will feel a desire to understand how their work contributes to the bigger picture that describes the business they work in.
While everyone’s journey will be different, I’ve broken down a typical journey using my own experiences and a collection of conversations I’ve had with people over the years, where I’ve helped them to move in the direction of a role in Enterprise Architecture. These steps will help you transition from your current role, but be aware that this transition will take time. I’m going to break these down into bite size chunks to make this material easier to read.
Step one is below, and I’ll add more over the next few weeks.
Step 1 – Letting Go
As many people interested in a career in EA have come from technical roles in the IT industry, one piece of advice I’ve tended to impart is the need to begin distancing themselves from a hands-on technical position. This can be difficult for many, some of whom may have built significant expertise with a particular technology, or within an organization or industry. I’m not saying that you should turn your back on this experience. In many cases, a strong and deep understanding of a specific technology or industry sector will likely be of significant value as you move down the EA path.
What I am saying, is that while you may have become very good at working at ground level, building systems or infrastructure that meets a specific need, this is often at a project level. Of course, it is important that this is done effectively in order to meet the needs of that project, but the Enterprise Architecture perspective involves aligning that work to the bigger picture required to realize the company’s strategy.
To develop your understanding of how IT enables a business strategy, you need to start stepping back from the coal-face. It’s only then you can start to see the full picture. This bring us to the skills of Abstraction and Conceptualisation, along with the Holistic View required to picture the longer-term, more strategic outcome required by the business to compete in their industry. I’ll talk about these skills and others in a future post.
Is this something you’re comfortable to do at this point in your career? Can you step away from the console, the development tool of choice, the business workshops or the automated test scripts? For me, this wasn’t a difficult decision. After years (make that decades) working as a programmer, and seeing wave after wave of talented graduates coming through that had fresher skills in the latest languages, I faced a fairly simple choice; continue to keep up with the latest languages, tools and practices, or move up and away from the code. At the same time, I found myself talking with more and more senior management, and learning why they wanted something built, not just what they wanted. In my mind, these talks created much needed context about the problem I was trying to solve, but they also opened my eyes to a broader view of what management was trying to do with the organization. This
fascinated me, and drove my desire to see more and more of the big picture. How was the solution I was designing going to contribute to the overall performance of the organization? What did it mean for the people who were going to use the solution? How did it benefit our customers? How did the solution provide a better outcome for the organization, in order for it to grow and thrive? These are questions that drove my interest in a role in Enterprise Architecture.
Whilst that choice was simple for me, it can be difficult for those that have developed a sense of self-worth based on success (or even notoriety) through their technical abilities. Listen to what your inner voice is telling you. Are you comfortable with, or excited by, keeping pace with the latest design practices, newer versions of your chosen IDE, or the ever changing face of infrastructure? If that’s what the voice is telling you, that’s great. We need talented and motivated people building the systems that will drive organizations in the future, and we need them built well.
However, if your inner voice is telling you that what you are doing is part of something bigger, and you have a desire in shaping how that bigger picture looks, then it may be a career in architecture that is calling you.
In the next article in this series, I’ll be talking about the areas of learning required to move in the direction of
Enterprise Architecture. Remember, it’s a journey, and one of personal and professional development. That means there’s lots to learn, but if there’s anything I’ve noticed about the really good Enterprise Architects I’ve interacted with over the years, it’s a life-long love of learning.
Have your say!
What do you think? Do you think an Enterprise Architect needs to maintain his or her hands-on technical skills? Please join in the conversation by responding below, or by emailing us at [email protected].
We also want to know the subjects that are causing you professional pain. Please email your questions, and we’ll select one for a future advice column. The EA Practice Advisory Team is here to help.
