Chief Architect Officer As Chief Bottleneck Destroyer

Architects design, plan, and oversee the heavy lifting of creating sound structures – and, really, the job description is in essence the same for a chief architect officer. The role requires keeping an eye on the ways a firm can utilize information technology more efficiently, especially in developing scale, as Urban FT CAO Larry Herbinaux describes.

PYMNTS: What does a day in the life of a Chief Architect Officer look like?

Larry Herbinaux

LH: Like everyone, the day starts out with meeting prep. Then, I contact the IT staff to discuss operational or development needs that require assistance. After that, it depends on where we are in the development process. During the requirements phase, I work with directors of IT and quality assurance, focusing on ensuring the business requirements can be mapped into the existing framework without jeopardizing usability or transaction scalability and robustness. During the design phase, it’s important to work with our engineers to ensure their proposed solutions are scalable and robust. And during the implementation phase, I’m likely coding for a seamless integration. And, of course, it’s important to make time to mentor the IT staff. “Educate and delegate” is my guiding philosophy.

PYMNTS: What is the most difficult part of your job, and why?

LH: Definitely, dealing with time bottlenecks. In our fast-paced FinTech environment, business requirements aren’t typically introduced at a steady pace. Sometimes they come in a flood. And, with so much to accomplish, employees — by necessity — are called on to wear many hats. While the pace sometimes leaves us professionally breathless, that’s the fun and challenge of doing what we do. It makes any other job seem boring in comparison.

PYMNTS: What do you wish you had more time to do?

LH: My passion is transactional scalability, and if I had a business wish, it would be for more time to address scalability proactively. The natural desire of every FinTech businesses is to continue to add value for its customers and clients. This emphasis often takes precedence over scalability issues, so I’d wish for more time to be even more proactive than we are.

PYMNTS: Chief Architect Officers have to herd a lot of cats in order to make the integrated delivery of products seamless. What’s your secret for doing that?

LH: The art is in architecting a system that doesn’t try to put square pegs in round holes. The process starts with a lot of communication with the teams responsible for providing the business requirements and working with them on solutions for requirements that don’t fit within the existing architecture. The next step is defining a uniform interface for integrations with products in the same category. It would be great if all third-party companies for products in the same category had similar interfaces, but they don’t so it’s our job to address that. The last step is implementing around any dissimilarities to provide a uniform customer experience.

PYMNTS: Speaking specifically of the payments and commerce space, what in your opinion is the most impactful innovation in that realm in the last five years?

LH: While not being the first to introduce mobile payments by a long-shot, Starbucks’ mobile application was impactful because it combined a very easy-to-use payment system and a rewards system that enticed consumers to use the application. The application was introduced in 2009, and in 2013 it reportedly handled 90 percent of the volume of mobile payments made in the U.S.

PYMNTS: What are the most important lessons that CAOs can learn from product failures?

LH: The first step is to figure out why the product failed to determine how to fix the issue. As an example, the transaction rate of one of our bill payment integrations was lower than forecasted. We used Google Analytics and noticed that users were dropping out of the transaction process due to incorrectly formatting the account numbers they entered. We saw that in most cases the required format didn’t match the format on the bill, and the service didn’t provide any hints for each biller. We were the first mobile client to integrate with this bill payment platform; all of their other integrations involved a clerk as a person in the middle to the consumer. The clerks knew all of the idiosyncrasies for the formats of the most popular billers which helped reduce the consumer frustration. Our solution was simple; we researched the correct formats and added this on to the integration to provide the consumer with the correct formats.

PYMNTS: What is a lesson you have learned in interacting with other businesses as a customer that you’ve applied to your work?

LH: Time is money, and one of my pet peeves is needlessly wasting my time when a more efficient solution can be provided. I try to apply this to the solutions I architect and the products our IT team delivers.