Introduction
In our previous blog, “Our vision on modern enterprise architecture – part 1″, we introduced Gartner’s “Pace layered application strategy,” “MASA approach,” and “Composable enterprise.” We highlighted why we believe that decoupling is key when it comes to making your enterprise software agile. Where exactly to decouple is not an easy decision. In this consideration, it is important to avoid three key pitfalls:
- Making it unnecessarily complex,
- Vendor lock-in,
- Too many customizations in proprietary software.
Vanenburg’s vision
As Vanenburg, we often use the diagram below to brainstorm with our customers on enterprise architecture modernization.
In our conceptual thinking, we differentiate between the following layers:
Layer 1: Core transactional logic, meant to support standard processes. In this layer, for example, off-the-shelf ERP and Accounting solutions have a place. They are designed for compliance and support the broadly accepted best practices for the domain. Unless the transactional processes of the organization are very special, it will generally make less sense to develop custom systems for this layer. Our advice is to minimize custom changes that will negatively impact the upgrade path and carefully look at the scope of the systems to avoid monolithic complexity, with the related high maintenance costs, license costs, and increased vendor lock-in.
Each customer situation is different, and as earlier stated, it depends much on the capabilities of your current application landscape, the vision and roadmap of your ERP provider, and the skills internally available in the organization. Also, the vision and cloud strategy of the customer does have an impact on the steps to advise.
We hear often from our customers that they are satisfied with the base functionality that their core system provides but that they feel a lack of support for the many upcoming innovations that they hear about from others. Core system providers often have a large customer base to serve, sometimes even in different versions of older technology, hindering them from embracing innovations quickly. If that’s the case, then we often help our customers to get in touch with their core system provider to have them open up their system so that applications on more modern technologies and frameworks can be developed on top of it in a decoupled manner.
When we see customers struggling with an ERP system that is limiting their flexibility and innovation power but they don’t have the luxury to move away from it, then we guide them using the following five consecutive steps:
In other situations, customers cannot find an off-the-shelf solution that covers at least 80% of their needs, and they decide to build the core system themselves. In the past, many homegrown solutions were developed based on Microsoft Access and SQL Server. Often the knowledge was only available to a small team of developers, which posed a risk to the organization.
When the company wants to be deeply involved in the design and development of the ERP system, the Thinkwise platform offers a decent solution. It brings domain experts, citizen developers and core developers together in a collaborative environment and controls the whole lifecycle from requirement gathering to feature delivery and usage.
The Salesforce platform also offers core applications with the ability to customize those or add custom extensions to them. There is an AppExchange where modules from 3rd parties can be purchased and added to the application landscape in an integrated way with the existing core functionality.
For startups and small companies that still have to select their core systems, Odoo can be a great choice. It can be used as SaaS from Odoo itself or deployed on AnyPremise. In the latter case, it is highly customizable. The open-source version can be used free of charge, but also the commercial edition is relatively cheap and provides you with more features and good support.
If your ERP provider is on top of the new developments and is actively working on adjusting and moving its architecture to the new era of Composable Enterprise, and you are satisfied with them supporting your business, it might be the best choice to quickly accept each of their new releases and migrate to the cloud if possible.
SAP, for instance, offers their clients the RISE with SAP program, which helps them simplify the transformation of their business for the digital age. In a future blog, we will write more about this and how Vanenburg can support you in this journey.
During the assessment of this core layer, we typically discuss the following questions with our clients:
- What is the maturity level of the organization when it comes to standardized processes? Those core processes are typically not yet stable in a startup, and the needs may fluctuate over time.
- What are the possibilities to modernize the core transactional systems?
- Will the core system provider offer an attractive path towards an open, cloud-based architecture?
- Can we solve the custom needs outside of the core system, or is the functionality too much related to the core to take it out?
- Are there any business reasons to split off certain pieces of functionality, for instance:
- Outside the core system, they can be easier reused on a global level.
- Experiment with the functionality and the ability to quickly adapt and try out various things in the market.
- A highly qualified team that can easily build new functionality in another technology.
Layer 2: Specific process. While in Layer 1, the design-time change responsibility is often outside of the organization, in Layer 2, the organization will be in charge of the design-time changes. The custom logic defined by the organization will be developed in separate components and aims to bring the organization a competitive advantage. A maximum alignment is guaranteed by having the business heavily involved in the generation of those components.
During the assessment of this specific process layer, we typically discuss the following questions with our clients:
- What will be the delta need for functionality when the core systems are kept generic and small or modular?
- How can this functionality be split up into logical components
- From a functional perspective
- From a technical perspective
- From an organizational (facilitating teams) perspective
- Can the required data be exposed from the core systems?
- How do we support the analytical needs of the organization when the data is stored in multiple applications and microservices.
- Do we need technology to support integrating microservices, such as an iPaaS platform or Mesh framework? Some cloud services, such as Google App Engine, have this already built-in.
- What technology will be used to develop the microservices?
If Java is an option for the organization, we showcase the capabilities of our Rappit Developer high productivity coding product which is excellent for quick prototyping together with the business and generation of code afterward and helps to drastically reduce the lead time and costs for the development of those microservices. More on this will come in a future blog on Application Modernization and how Rappit Developer can effectively approach that.
Layer 3: Task, meant to support the daily work of the knowledge worker. While in Layer 2, the organization is in charge of the design-time changes, in Layer 3, the knowledge worker is in charge of run time changes. Therefore the tooling needs to be extremely flexible and configurable. It’s like a spreadsheet in the hands of a knowledge worker, but then in a connected and controlled manner.
During the assessment of this task layer, we typically discuss the following questions with our clients:
- What is the tooling currently used by the knowledge worker to support their day-to-day work, especially what is developed and used outside of the governed systems? For example, in many organizations, sophisticated excel based logic is used in an uncontrolled manner but of vital importance.
- Does the organization have skilled power users that would be able to make quick adjustments to the logic when required?
We showcase the capabilities of our platform Rappit Composer which offers organization-controlled provisioning of task-oriented apps to the organizations and its business network integrated with the data and logic in the other layers. In a future blog we will write more about how Rappit Composer can give an organization this layer of flexibility.
Although this has proven to be an effective way to analyze an organization’s options for architecture modernization, the disclaimer is that the boundaries between those layers are not always easy to define and which layer to position a system is not always black-and-white. For example, a platform like Salesforce provides standard processes (layer 1) but also out-of-box support for customizations with the flow builder (layer 2) and also support for the knowledge worker with customizable dashboards and tasks (layer 3). So there might be good reasons to use the platform for all layers.
In the end, technology is not a goal in itself. Instead, an important thing that makes technology good or bad is whether it supports my business and makes me ready to embrace new business opportunities. Now and in the future.
Vanenburg, a typical tech entrepreneur, assists industry incumbents in realizing their digital transformation. We develop modern applications based on leading technologies and an architectural model that mimics the dynamism of the digital mesh. Vanenburg is a partner of Google Cloud Platform, Salesforce, and ThinkWise. We have expertise in the ERP, iPaaS, and Information Security domain and use these experiences and technologies actively to modernize the application landscapes of our clients. The organization is certified for ISO27001 and NEN7510.
