Jed Maczuba
This is the third installment in a series about what it takes to build an enterprise-class software company. You cannot build an enterprise-class software company without enterprise-class software development. We combine deep wealth management domain expertise and enterprise software expertise, and deliver frequent, innovative solutions configured for our clients’ businesses—all while keeping their data secure and private.
How is “enterprise-class software development” different than just software development? When we talk about enterprise-class software development, we are talking about building software for a complex ecosystem.
- Not only the complexity within our clients’ environments but also the overall ecosystem of technology and data providers
- There is also the complexity of working in the financial services industry and the highly regulated environments that our clients live in
- We do all this while maintaining a focus on the scale and resiliency of our software and the quality and integrity of our data, which enables our clients and their advisors to make sound financial decisions
Our clients are unique in how they run their business and we must support the complexity of the individual businesses that we serve.
Our goal is to build a platform that can be tailor fitted to solve our clients’ unique business needs and standardized to keep pace with technological advancements while not creating challenges associated with bespoke solutions.
There are three major pieces to enterprise-class software development that set us apart from mid-size business software development:
- The tools and processes underpinning how we develop enterprise-class software
- The way we architect an enterprise-scale platform
- How our software release approach is tailored to our enterprise clients
Let me spend a few minutes on each.
1. The tools and processes underpinning how we develop enterprise-class software
When we develop enterprise-class software, we need to put into place the right tools to streamline the process end-to-end—from documenting product requirements, to facilitating the coding activities, to measuring the quality of the code, to enabling well-coordinated releases. Having a modern, integrated tool chain creates standardization across the process, which then creates efficiencies and reduces variability among the teams. It marries the benefits of the Agile development methodology with the rigor required by enterprise-class organizations.
How do we increase the output of the engineering organization while ensuring that newly introduced code doesn’t break existing functionality? By using a well-defined comprehensive automated regression test suite that monitors the output of tests. Too many software companies rely on their customers to be the testers of the software—this is about building quality directly into the software development process.
Understanding the progress of software development is difficult, which is why it is important to use data to ensure we are meeting the goal of high-quality output. As W. Edwards Deming said, “If you can’t measure it, you can’t manage it.” We set our engineering organization to succeed by:
- Minimizing the percentage of defects that escape the development and testing activities;
- Tracking development progress and continuous improvement initiatives using standard tooling and measures;
- Requiring that all teams use the same criteria to measure completion or “the definition of done;” and
- Providing transparency across the organization.
Having standardized processes and tooling also allows us to build capacity into the organization to do both strategic project work and client-directed enhancements and not suffer from quality issues or inconsistency in the process. We need to support our core product roadmap work and client-needed enhancements—which in financial services may include regulatory changes. Many times, the most important feedback from the field is not the major product roadmap enhancements to come—it is the small things that matter.
2. The way we architect an enterprise-scale platform
Understanding points of differentiation in the clients we serve and architecting that into the platform—we call this configuration. An example of this is Advisor360º's Digital Onboarding. All our clients have an account opening process but the workflows and required documents vary. We do not want to build bespoke custom solutions, so we built a low-code generation engine that supports variability in our clients' requirements and reduces implementation time. We have also built into our software “feature toggles” that allow us to enable or disable features across implementations while maintaining a single codebase. Enterprise clients do not all consume those same capabilities, so we architected a platform that avoids custom development (i.e., customization) and embraces dynamic configuration.
We do not want to build bespoke custom solutions, so we built a low-code generation engine that supports variability in our clients’ requirements and reduces implementation time.
Our clients also have scale—we designed our system to handle the workload of the biggest firms by implementing formal performance engineering disciplines within the software engineering process. Performance engineering is a complex discipline that not only requires understanding what to measure but how to investigate where the bottlenecks are coming from and address the root cause.
Also, our platform does not live in a silo. It is part of a much bigger ecosystem within our clients’ environments. We build standardized integrations between our platform and our clients’ other third-party software providers.
3. Our software release approach is tailored to our enterprise clients
Enterprise-class software development is not just about coding and releasing software as quickly as possible, it is about making sure our enterprise clients are ready to consume our software. Our clients operate in complex environments—often with sizable internal business stakeholders, IT departments, operations groups, advisor support staff, and sensitive advisor populations—which may or may not be employees of our clients. We must coordinate with internal staff and third-party technology providers to ensure seamless releases of our software.
The challenge becomes how do we turn out new product features and functions as quickly as possible but also ensure that our clients are prepared to take them? This often includes preparing internal technology and support staff for what is coming and providing support for the advisors to make this as smooth as possible for them.
The challenge becomes how do we turn out new product features and functions as quickly as possible but also ensure that our clients are prepared to take them?
This is not the simple build and release process that many commercial software companies do; this requires tight coordination with our clients. One way of making the delivery smooth is by working hand-in-hand with our clients on Alpha and Beta releases of our software and arming them with training and communication materials.
While each of our clients may appear similar on the surface, their needs vary drastically. We use enterprise-class software development to create configurable solutions that are both standardized and scalable so that we can keep pace with technological advances.
You might be interested in earlier installments in this series, What it takes to build an enterprise-class software company and Creating a culture of enterprise-class compliance
Enjoying this series? Sign up to automatically receive our blogs as they are released.
Jed Maczuba is Senior Vice President, Chief Technology Officer at Advisor360°, overseeing global technology to ensure our long-term mission, vision, and objectives align with the technologies of our business partners and clients.
