A common challenge in traditional Enterprise Architecture is the need to integrate core applications for common business functionality such as CRM, HR, ERP, etc. It is not uncommon for larger enterprises to have many such applications across multiple organizational units. This creates lots of data silos and makes it hard to streamline automation of workflow and analytics.
These core applications entrench established vendors, require expensive customization to fit unique requirements, and sometimes require custom hardware or a closed managed cloud. Integrating data from these applications across other systems is both expensive and brittle,
Consider what happens when a new version of the application comes out. For example, when SAP moved to HANA. The user experience and workflow customization needed to be redone, integrations needed to be redone, new managed infrastructure had to be procured. These are not trivial costs and have significant business risks.
Although this may be an infrequent event for one application lifecycle, if your organization has many such applications, then this becomes a constant challenge.
Evolving our Enterprise Architecture to break this dependence on applications has been a focus for the IT industry for decades. The most recent changes were based on the idea of decomposing large monolithic applications into a set of loosely coupled microservices. In practice, these microservice approaches frequently became “small” applications, creating even “smaller” data silos, generating an additional proliferation of technology and subsequent anti-patterns.
The fundamental problem we have been struggling with is that we continue to see functionality as something that is implemented by an application, or microservice. That is, at some level, there are lines of code required to:
- Render a user experience that performs basic CRUD operations on a set of records that get stored in a data silo.
- Transfer data between silos (either internally or externally).
- Provide workflow, analytic, or dashboard functionality that operates on this stored data to add further value.
Although it is true that microservices are a good way to address the custom code required to implement 3 and to a lesser extent 2, they are not a good solution for 1. If we are still creating a hard coded user experience, then we are still dependent on technology and are adding to our data silo problems.
The solution is to abstract the functionality for rendering user experience and storing data from our applications, or microservices.
We can start this approach by adding two framework services to our next generation Enterprise Architecture:
- A Record Storage Service (RSS) that can store any type of record securely in a framework level repository available to all applications and microservices.
- A Dynamic Page Builder (DPB) than can use a combination of form definitions and records from the RSS to render any user experience and maintain any record in the RSS.
The RSS completely eliminates the creation of new data silos within the scope of control of the framework. There may still be application, or microservice, data silos within our organization which may exist for decades yet to come. We haven’t solved the whole problem; we have started a transformation roadmap to reduce future proliferation, and over time, to consolidate existing data silos into the framework.
The DPB completely eliminates the need to create new applications, or microservice, to render user experience. If we need a new type of customer, or order, we don’t need to write, test, and deploy new code. We can simply add a new form definition to the RSS and then immediately start to create new types of records. We also need to ensure that our DPB can enable the users of the framework to invoke microservice functionality for data transfer, workflow, analytics, or dashboards.
The combination of RSS and DPB enables us to abstract all the user experience and data storage functionality into configuration data. This means that this functionality is no longer bound to an application – it exists only at the framework level. This reduces our need to create new applications to solve our business problems. Over time, we can continue to migrate functionality into the configuration framework and retire obsolete applications in a controlled fashion.
Having RSS/DPB as services in our Enterprise Architecture decouples the functionality of our solutions from technology. If better technology arises in the future, we can simply rebuild the RSS or DPB and do not have to change our working abstracted functionality. Use of a DPB means that we can use configured functionality to render the same user experience across any technology including web, desktop, iOS and Android.
This approach also changes the dynamic of the IT roles and responsibilities:
- Non-technical resources can configure the entire user experience. This significantly reduces demands on developers enabling your existing team to achieve more.
- Developers can focus on high value customization of workflow, analytics, and dashboards.
- Testers have significantly less code to test, improving overall application quality and reducing risk.
- Greater consistency in user experience across all platforms/devices/applications simplifies user training.
- Only one development team is required to build across multiple devices (for example, web, desktop, iOS, and Android)
Adding RSS/DPB components to your next generation Enterprise Architecture is something any CTO/CIO should consider as a way of doing more with less and delivering value to the business faster.