Within MuleSoft’s ecosystem, there are numerous careers one can pursue. Whether you are interested in becoming a MuleSoft developer, architect, DevOps engineer, integration practice lead — it can be hard to figure out the best path to begin your career.
In this post, you’ll hear the perspective of two different types of MuleSoft Architects (an Enterprise and Integration Architect) as they share their career experiences. Hear from Ujjval Tota, an Enterprise Architect at Reckitt and Kyle Usher, an Integration Architect at Johnson Controls (JCI).
Ujjval Tota, Enterprise Architect at Reckitt
Ujjval has nearly two decades of IT experience, 17 of which have been in the ERP ecosystem. He currently works for Reckitt and prior to this, he worked at iGATE Global Solutions Ltd. (now Capgemini) and Deloitte. Ujjval started his journey in Reckitt as a Senior Manager-Technology Architecture, responsible for setting up technology competencies and running them. A year into Reckitt, he moved into the niche enterprise architecture team, as an Enterprise Architect – Integrations where he heads the strategy for enterprise integrations and supports the strategy in ERP and data architecture.
Kyle Usher, Sr. Manager, Integration Architecture at Johnson Controls
Kyle Usher has more than five years of MuleSoft experience, is a MuleSoft Mentor, and a Sr. Manager, Integration Architecture at Johnson Controls (JCI). He has many years of experience working in a variety of roles using MuleSoft. He’s been a hands-on developer and now leads an integration architecture team.
Below are three questions I asked Ujjval and Kyle to better understand the similarities and differences between the two architect roles:
What does a typical day look like for you?
Ujjval: The roles and definitions of an enterprise architect are skewed across the world due to the myriad of how IT organizations (in any form) have started defining the roles and responsibilities of enterprise architect. In some organizations, enterprise architects are technical or solution architects.
Enterprise architects are those who have matured beyond technical or solution architects and are more strategy focused. They are primarily responsible for aligning the enterprise business architecture and enterprise technology architecture with the business goals. While technical or solution architects are specialists in their field, the enterprise architects are strategists in their respective fields.
At RB, an enterprise architect (EA) has no “typical” day. As an EA, I end up working simultaneously as:
- Technology strategy advisor
- Salesperson and evangelist
- Architecture review authority
- And many other need based strategic roles
Each day is unique. The EA team at RB are like the internal “advisory” arm for technology. The advisory requirements range from assessments to overall due diligence of technology choice and decisions. Given the mixed set of high-level executive stakeholders involved and the myriad of situations that I get involved in, the need to be “agile” in thinking and articulation, become the most necessary skill to navigate in the day.
Despite the dynamic nature of my days, some workdays are static due to the formal tasks around architecture review authority, that are conducted via:
- Architecture review board (ARB)
- Technical review board (TRB)
My work output is measured primarily via the following:
- Strategy definition and effectiveness
- Advisory
- Architecture repository setup and contribution
- Architecture review
Kyle: My Enterprise Integration (EI) Architecture team has three main pillars we support – project support (intake estimates and design consultations), EI COE Enablement (best practices and governance), and enterprise alignment and socialization. On a typical day, I won’t spend time on hands-on development, rather I will work closely with EI partner architects and other JCI COE architects to align interface solutions to our goals (API reuse, cloud first, leverage the box system functionality), and report to senior leadership. With the team embracing MuleSoft’s API-led approach, our legacy integration approach has experienced almost 4 million dollars in cost savings in two years since we began our Mulesoft journey. As an integration architect, my job is to make sure the team is on track to meet our goals for each of three pillars we support.
More specifically, I manage integration architecture roadmaps by:
- Retiring integration technologies
- Evangelizing API-led methodology
- Working with partners responsible for enabling our developers with dev guides, best practices, making sure we have proper governance, and test controls.
Right now, we are actually onboarding our third partner, so my day is mostly packed with making sure they are aligned with our architecture and governance practices.
What is your experience using MuleSoft?
Ujjval: As an enterprise architect, I limit my experience to technology agnostic integration principles. Thus, I am more focused on generic principles such as service-oriented architecture (SOA), enterprise resource planning (ERP), services integration, and as of late, mesh architecture. It’s quite interesting how close MuleSoft’s foundations are to the “fundamental principles” of integration. Thus, despite having a low working experience with MuleSoft, it is quite easy for me to understand the concepts and the principles around which MuleSoft works.
Kyle: I started using MuleSoft in 2015 at Brookdale Senior Living while working on a CRM project when our system integrator recommended that Brookdale needed an integration strategy and tool to support their integration work. Once I started using MuleSoft, I stuck with it and have done all roles in the integration sphere from developer, architect, DevOps leading me to becoming an architect. MuleSoft is always interesting and is a product that does what it advertises. MuleSoft has done an amazing job with the tooling and platform working hand in hand with the API-led methodology. As with any tool, there are some hiccups, but MuleSoft has been a partner helping provide support and product development based on customer feedback.
What are some examples of projects you have worked on during your career?
Ujjval: Since my role includes many different responsibilities related to strategy, I do not work for any specific projects (as it should be in the case of an EA). The EA is involved early on in the decision-making process to strategically influence decisions involving:
- Technology and platform assessment and choice
- Business architectural alignment with enterprise architecture
- Technical architectural alignment with enterprise architecture
On that note, some noteworthy mentions of the work that I am involved in are:
- Major business transformations program architecture
- Architectural principles and patterns
- Conducting architectural review board (ARB)
- Conducting technical review board (TRB)
Kyle Usher: We are working on some challenging and important projects at JCI including advancements in smart building and healthcare facilities. One of my favorite projects I am working on is our ERP transformation project which includes creating global business process templates and global integration patterns to support the business templates. Building an API network is going to be key to unlocking the ERP assets, meet regulatory compliance by bending the API network, limiting customization to the ERP, and supporting rapid business changes. This project has allowed me to learn about the business of JCI as the interfaces are tracking back to core business capabilities and will be leveraged for multiple business units.
Being a technology-focused person, this has provided a unique experience to architect integration solutions that support the current business units requirement and be flexible to support other business units. For example, in my role, I ask questions like “why do we need to build the interface? Is the system interfaced with the ERP a strategic application? How do we build the interface for non-strategic applications so when there is a change the interface is enhanced and not redone?” and then bring this view to JCI leadership which they didn’t previously have access to.
It has also been exciting helping drive goals of system reduction and seeing the other COEs be in agreement. I enjoy coming to work and moving in the same direction as the company as a whole.
Kyle and Ujjval differ greatly in their roles on a day-to-day basis, as well as the projects they work on, however, their overall contributions and impact on their business’s outcomes are quite similar! We will be diving into a few more questions in the following blog.
