Announcing the Ascentis Technology Blog!
Ascentis isn’t your typical HCM SaaS company. It has more than thirty years under its belt, a healthy customer portfolio, and it’s a start-up. Or, at least, a company in the “start-up mode.” It is a start-up because we are working on re-inventing the HCM space through innovation. Our goals are ambitious. We don’t just offer products that are ahead of our competition — we want to leapfrog the industry as a whole by redefining the way HCM does business.
What does this have to do with technology and architecture? After all, developers build solutions based on requirements handed down to them by product managers and business stakeholders. I can talk about technology innovations vs. product innovations and it is certainly our role as the development organization to drive the technology innovation, but it is also our responsibility to make sure that our technology platform is a facilitator of innovation for the product teams.
What does that mean in practical terms?
Let’s examine what innovation is. It’s a process that requires a lot of experimentation. Ninety-nine ideas out of hundred can and likely will be discarded. Most will be discarded long before they are put to code. We see this today — product teams put together specification that go through a number of reviews and customer focus groups before they come to development where they are further refined during implementation. Even with this iterative process, there are no substitutes for real-life usage. Once an idea is taken from concept to code it can fail for a wide variety of reasons – from not meeting user’s expectations to not being cost-effective. In these cases, the large up-front investment that went into iterating the design is often lost. The goal is to strike a balance between up-front design and ability to do real life experimentation, to reduce cost and improve time-to-market. The sooner the “failing” idea is rejected, the less it costs the company and the sooner the “winning” idea can be surfaced and developed.
Our objective is to make sure that our technology platform makes the experimentation effective and economically feasible. This means that both our development process and architecture has to be agile. We have to be able to implement changes quickly and affordably. We have to be able to undo changes equally quickly, economically, and without impacting the maintainability of our code base. We have to stay current with the rapidly changing technology landscape and be able to take advantage of new technologies, best practices, tools, and patterns. Our system has to be able to evolve.
Few will argue against the idea that a system’s capacity to embrace change is critical to its ability to be the platform for innovation and for its long-term success. But how do we build a stable quality product that is also constantly and rapidly changing?
First step is acceptance. Instead of looking for ways to limit change, we have to find ways to embrace it. Once we accept that support for rapid change has to be a fundamental tenet of the architecture, we can start thinking about what that actually means to the technology platform and what improvements must be introduce into the code base, processes, and the way of thinking. Anticipating that the architectural and design decisions we make today may need to change tomorrow, we have to start thinking about aligning the system and its components to thrive in the face of certain variability. We have to consider the dispensability of each component as a core feature.
Second, we have to recognize that different layers of the application undergo different vectors (direction and velocity) of change. For example, code that is responsible for user interactions is more likely to change than the underlying data structures and the service code responsible for business logic. In order to minimize impact to the code base, it is useful to anticipate and define components that are less susceptible to change.
Next, we have to have confidence in the code. As we make changes, we have to be confident that we are not breaking something else, or if we are — we know about it as early as possible. Increased componentization and rates of change can also contribute to new types of bugs and code-base instability. We have to ensure that test suites extend full coverage for both unit and integration tests. Automated continuous integration and code-quality tools go a long way to help detect functional and code quality issues early.
Embracing change and building resilient components are the cornerstones of innovation. Components then have to be easily composable to deliver innovation efficiently.
The Ascentis technology team is an equal partner of our product and business teams and we are excited and committed to building a robust technology platform for product innovation that helps us bringing solutions to non-obvious complex problems. Concepts described above are proving to be powerful tools for us, and we are looking forward to sharing our successes and our failures as we continue on this journey.