I remember my first day at Moniepoint two years ago. It was the 3rd of January, and I was so excited to start the year on a new job. I came in as an Engineer with an overarching big-picture view of what my role could evolve into, the ways that my work would matter, and the possible futures ahead of me. 

And… as fate would have it, a couple of weeks into joining as an engineer, I was put on a project that moved me into the role of an Enterprise Architect. Now that I’ve worked as an Enterprise Architect for over two years, I can tell you what the role looks like.

Who’s an Enterprise Architect at Moniepoint?

Being an Enterprise Architect entails a number of things, but it majorly means being able to translate requirements into a finished product or a usable application. And that could mean designing in a particular way, applying some design principles, architectural disciplines and other things, while infusing your experience in that field/industry.

An enterprise architect at Moniepoint serves as a bridge between the business and the engineer who works on the major features. They are responsible for coming up with a design that best addresses the problem (the problem in this case is the requirements) and helping the developers understand how the business sees it and how they should see it as engineers. So, the EA picks the requirements and, at the end of the day, comes up with a finished product.

A snapshot of what every day looks like

My days aren’t exactly fixed or predictable, but there's a template that I like to follow because it brings structure to my life - I wake up early, do my morning rituals, and then get to my PC 10 minutes before 8 a.m.

Other times, I get to the PC before then doing code reviews. Otherwise, I'll go to my PC, prepare for the standup, and attend to team requests after the standup. 

Sometimes, I also have a day planned out. On those days, the highest priority could be production issues or open MRs. If the engineers need a deep dive, we block out time during the day to do that. Sometimes, if they have some blockers mentioned during standup, I could ask them to also wait behind.

To simplify it, it should be: attend standup in the morning, get feedback on the standup, attend to open MRs, plan for deep dive sessions, and stay open to checking for production issues. I also need to attend leadership meetings with my VP, and product manager just to be sure that we're always on the same page,  and that the OKRs we're committed to are still being worked on. And if we are experiencing any form of blocker due to resource constraints or any other constraints, we discuss those kinds of issues.

Keeping the process simple.

My main responsibility is to simplify the process. Regardless of how hard or big the requirement is, I should not transfer the complexity to the engineers that I work with. I should also be able to transfer the knowledge that I've gained from the business to them. 

Sometimes, this involves me sharing the approach we’re taking with each member of the team during their deep dive. I also need to walk them through the current, existing system and the proposed system and explain why we are doing things a certain way. This helps broaden their technical creativity or awareness. 

For instance, an engineer might think they're exposing an endpoint to get names, but in the long run, they're actually exposing an endpoint to get the names of about 10,000 users or more. That could help them say, “Okay, no, this shouldn't be paginated.” Therefore, they make good technical decisions along the way as well.

A recent fulfilling project

We recently did some work in East Africa, and I functioned as the EA, which kind of led the whole initiative. I derived a lot of joy in understanding their existing system and fleshing out the right architecture to merge it with how Moniepoint works – improving their technology with ours. 

There was a lot of work around preempting and building technical moats to merge the systems technically without issues. This extends to designing reliable and fault-tolerant systems and creating systems of services along the line. For example, the transfer process—defining it, the recurring transfer process, the user onboarding process, and several other components that play a major role in completing a business banking application. 

It is one of the biggest things that I really enjoyed because I was able to see the endless possibilities that exist in terms of expansion, technical scale, and everything happening along the line. I would say it's also helped me understand some core systems and be intentional about creating an extendable system that would be reusable for diverse initiatives and other countries.

If you like being at the centre of business, engineering, and things that scale, we have 2 Enterprise Architects roles open. Check them out here and here, to join our team!