A Day in the Life of an Aspiring Architect

Raza Qazi, Junior Enterprise Architect

June 4, 2018

I hadn’t even finished my computer science degree when I was offered a junior enterprise architect part-time role while I was in my last year of studies. I didn’t even know that an enterprise architect could be junior. Regardless, this was my big chance to figure out what area of IT I wanted to pursue while I was in university. How many students get a chance to work in an IT architecture group while still going to school? This was an opportunity to learn what architecture was and what architecture disciplines comprised enterprise architecture – data, process, application, technology, business, domain, solution, etc. I can honestly tell you that IT architecture is not something they teach us in school. Furthermore, this was my chance to figure out what architecture was and if it was something that I wanted to do.

I was hired and worked directly for the Manager of Enterprise Architecture for a government organization. When I met my new boss, he informed me that he wanted me to help his team diversify the practice of enterprise architecture, and to further establish the architecture community to support future needs at the organization. In other words, he wanted me to do the architecture grunt work for him, and I was more than happy to learn. At the beginning, I was unsure of my role as it was the first time I was not required to program, but rather assume the role of an architect. The first few weeks revolved around learning and understanding enterprise architecture in a government environment. I read everything I could on TOGAF and a modeling language called ArchiMate, which was an architecture modeling standard supported by their enterprise architectural tool. My co-workers provided a lot of assistance and guidance along the way while answering questions such as:

•  What role does enterprise architecture seek to fill in the organization?

•  How does it affect the organization’s long-term goals?

•  What does an enterprise architecture teamwork on day-to-day?

During my internship, I also gradually became more and more familiar with a modeling tool used by the EA team. I learned about the process and standards for developing process models, the key considerations and undocumented features in using the modeling tool, and the expectations of my team in helping them complete their architecture deliverables. At the same time, my role was evolving into new and exciting avenues as the practice matured. I started to use my development skills to automate repeatable processes carried out by the team. I also helped out wherever I could when it came to research and development. My boss was instrumental in giving me great advice during this time. I realized that my job performance meant that I had to be passionate about my role as an aspiring architect, willing to learn about new technologies and practices, cognisant of setting expectations with team members, and able to understand what role an architect plays in different organizational situations.

My manager had a mandate to support the evolution of governance and sustainment processes of the enterprise’s information content. This content, represented in the form of architectural models, encapsulated key functional areas of the organization and it was our objective to make it easily accessible to more employees. We decided to support this initiative by publishing web-reports of the models created using the enterprise architectural tool. This involved understanding what kind of models the team wanted to publish, what requirements to consider when designing possible interactive use cases, who the audience is, what kind of technologies we can use, and how the modeling tool can enhance the representation of the content. At first, it was a challenging and overwhelming task, but it didn’t take long to see the benefits. The modelling tool was meant to provide reports for architects, not business users. Thus, there was a language barrier when it came to describing architectural entities, processes, relationships, and systems to business users, which we had to overcome in order to resolve business problems. It was my job to help translate architectural jargons into something that was readable for outside users by developing a layer on top of the base report that accomplished “on-the-fly” translation using JavaScript queries. These translations relied on the help of my team. The report’s HTML structure was also modified to support other devices such as mobile phones, desktops, laptops, and tablets irrespective of screen size. It was critical to make the report-generating process sustainable for the team. Since I was the primary developer in my team, I wanted to ensure that they could add new features and translations to the report and extend its functionality while keeping it sustainable for the practice. I’ll take the credit for designing and developing a lookup table system so that team members could add/ modify/ delete translations as needed without extensively modifying base customizations over the report. Over time, we were able to resolve an extensive list of development hurdles. I also wrote extensive documentation in case the team needed to consult a reference of the customized report. I can proudly say that it became one of the most important initiatives that our team is evolving and supporting today, and I’m proud of what we accomplished in such a short period of time.

During my architecture journey, I have learned a lot of important concepts applicable to all kinds of roles. It is important to establish good communication with your team. I was able to develop my skills as an architect due to the responsiveness and support of my team. I’ve also learned that it is also important to be curious about the world of architecture if we want to excel in this field. When I started, I didn’t know anything about enterprise architecture. It was important for me to get acquainted within the practice and to provide a meaningful perspective for the team. It was also important to ask questions as my role expanded. This allowed me to gain a better understanding of an enterprise architecture practice from an architect’s perspective, especially since I was taking on a role that university courses don’t tend to get into. Overall, I can confidently say that getting exposed to and being part of an enterprise architecture practice has been one of the highlights of my career. I am grateful for the opportunity to work in this environment and learn new skills that will be applicable to other challenges down the road.