Despite the rapid advances in technology, it seems many enterprises are still stuck in the past in terms of system architecture. André Christ, CEO and co-founder of SaaS company LeanIX, finds too many enterprises are continuing to use older architectures rather than upgrading to newer systems.
This is starting to pose a problem as machine learning and the Internet of Things are becoming more prominent. Older architectures simply cannot be extended to support these new technologies, Christ explained.
With monolithic architectures “you have very long cycles of updating those applications,” said Christ. “Companies are seeing they will no longer be able to introduce new products, new channels, or new markets if they don’t ensure that their software architectures are flexible enough.”
According to Christ, those companies staying with old architectures are essentially being forced to spend resources maintaining their existing architectures rather than putting their efforts into new technologies. “Those legacy systems are killing the future business opportunity,” he said.
“As with any other major transformation, the decision to modernize is not to be entered into lightly,” said Christ. “Shifting away from an often-times decades old highly layered monolithic architecture comes with a set of challenges that is not for the faint of heart.”
The way enterprise architecture is addressed today is much more collaborative than it was five or 10 years ago, explained Christ. According to him, there are three factors contributing to the need to be more collaborative when it comes to enterprise architecture.
First is that back then, decisions, products, and approaches were much more central and top-down, Christ explained. “Right now, architecture decisions are decisions on which applications should be bought, or which software should be developed,” he said. “It’s no longer centrally decided and from the CIO, it’s much more widespread in the organization.” This democratization has led to more collaboration between business and IT, he said.
Second, access to modern platforms fosters collaboration because teams are no longer just managing applications that run locally on machines. They are implementing technologies such as virtualization, cloud computing, and microservices, which necessitates collaboration, Christ said.
Third, the increasing complexity of IT projects, such as digital transformation and support for IoT, led to the need for tighter integration within the enterprise architecture.
Some of the obstacles that he sees organizations running into when trying to undergo the transformation from older monolithic architecture are the data volume and integrity, autonomous service management, and the ability to run diagnostics.
Christ explained that the volume of data can cause major stress on an enterprise’s network, resulting in latency. There may be hundreds of services running within a single application, and requests could span multiple services. In addition, when taking a decentralized approach, such as with microservices, high-quality data becomes more complex, especially when each microservice has a different database and each database might use a different technology. This can lead to issues when services are referencing data in other services, Christ said.
Management of autonomous services also becomes more complex when teams are dealing with hundreds of interdependent services rather than just one deployment, he explained.
Finally, managing performance on microservice-based applications requires more effort than it would on a monolithic application. Applications may produce large numbers of logs that need analysis, which means debugging and running diagnostics becomes a laborious process, Christ said.
In order to overcome these challenges, it’s important to remember that this transition will not happen all at once, but the monolith with decrease every day. Monolithic code will live on in the system for years after making the switch. He explained that companies need to decide when and where these microservices can be integrated into existing applications.
Christ lists these six rules that a microservices adoption plan should follow:
- Services should be designed and responsible for only a single business capability.
- Each microservice should have its own datastore.
- Code should have similar levels of maturity.
- Deploy microservices in containers.
- Treat servers as replaceable members of a group that all have the same functionality.
- Monitor microservices with mechanisms such as response time notifications, service error notifications, and dashboards.
He also explained that when coming up with a plan, it’s important to think about how the application will be used. “Identify the goals in the context of the user’s environment, task or work flow and let the needs inform the design,” he said.
