Using Data Lifecycle Management to Improve Operational Performance
When deploying technology in your organization, have you ever considered the integration of your various IT systems?
People consider integration as getting data from one system to another. It is a very simplistic point of view but unfortunately shared by many. A more precise statement of integration would be about business process information flow between software applications.
Why IT? Why data?
Your operational processes are supported by various IT systems. First and foremost, we need to understand the three basic facets of your IT support: direct IT support, indirect IT support, and agility.
Direct support is the support of your primary processes and highly process-oriented. Indirect support is the support of your secondary processes, such as data warehousing, business intelligence and predictive analytics. Agility presents opportunities arising from new technology that your business processes can benefit from.
It is imperative to understand when changing your business processes, your IT support should change at the same speed. In this context, data lifecycle management will be a comparative approach to manage your organization’s data, along with associated metadata, from creation, storage, to obsolescence and destruction.
As a matter of fact, data lifecycle management has always been the most important but often overlooked aspect of data architecture. However, with the introduction of the GDPR (European General Data Protection Regulation), as well as many other similar regulations that came into force in the US, we can no longer afford to neglect data lifecycle management.
Back to operational performance, data lifecycle management is specifically important to reveal which business processes and events are responsible for the various phases in the lifecycle of the data, and in which information systems they are registered or controlled.
A Collection Of Applications vs. A Network of Applications?
Business processes can be decomposed into sub-processes, which can be decomposed into tasks. From an ecosystem perspective, your processes, along with processes from other organizations, will make up the process map of a local economy, which is part of global economy.
Usually, various processes are covered by various IT applications. Process-application is never a one-to-one relationship.
Similar to processes, applications can also be decomposed into programs, which can be decomposed into subroutines (i.e. functions and procedures). And a well-design system of applications can form an applications network.
An applications network is a set of applications cooperating as a whole. If parts of the system don’t cooperate, then the system can’t function properly. In other words, integration of applications is at least as important as the applications themselves.
Things work better when they work together on purpose. Don’t focus on things, focus on how to make them work together.
To have a truly functional applications network, we must realize that cooperation requires coordination. If your communications and activities across the network are not coordinated, then your network will not be efficient, or might even fail.
Be Aware Of Unsuitable Integration Solutions
We have evolved from manually registering data on paper to automatically registering data on disk, only to discover that some data was redundant and could be shared between applications. We then focused on getting data from one application to another in a batch.
It worked very well in the last century, but with the evolution towards more and more real time business process support, these legacy import-export solutions have become unsuitable in today’s direct IT support. We rapidly ran into various issues resulted from these unsuitable integration solutions. And in real time systems, errors as such can be highly impactful to business processes.
Be proactive in your approach – the initial costs of an unsuitable integration solution may be low, but the total cost of ownership over the lifecycle of the solution can be very high. And oftentimes, these failures are very difficult to find, very difficult to remedy, and even more difficult to prevent, and impossible to predict.
Using Data Lifecycle Management To Improve Operational Performance Webinar
What Is A Collaborative Applications Network?
As an integration architect, Piet has his own definition of application integration which differs from the tech-oriented one on Wikipedia. He goes further than technology itself by defining application integration as a support of business processes across a heterogeneous landscape of applications.
To achieve application integration, we need to encourage organizations to stop collecting applications and to start building integrated applications network, in which the applications can cooperate as a whole. A functional application network demonstrates several key capabilities –
Furthermore, an applications network is not a point-to-point integration, or a middleware solution, or a fancy term for integration layer. It is carefully designed and structured in a way that connected applications can cooperate as a whole and create synergy.
Business Service Design Is More Than Data Gathering Service
Business Service Design is a powerful methodology to weave your business processes and applications network together. It is composed of business process context and information stream context.
To make sure that standardized information flows across various applications, canonical schema can be extremely useful to structure your shared content in an identical way. Besides canonical schema, there exist many other models available to choose from. You can also create your own schema adapted to your organization.
However, we should acknowledge that canonical models live only in the business process layer. For a Business Service Design, we also need a Greenfield enterprise model to structure data required in the business service layer.
The fabric of an applications network consists of integrations that implement the business process information flow between the LOB systems.
More than Data Gathering Service, Business Service Design derives from a message nature – it never exchanges objects, but messages, including commands, events, requests messages, submit messages, acknowledgements, response messages, error messages, records, etc., which are all relevant to your business processes.
Business processes govern the data that will be exchanged. The roles that various systems and applications play in the data lifecycle will govern the nature of the messages. The messages’ nature and trigger govern the choice of a message exchange pattern. And the message exchange pattern governs the choice of technology.
To learn more about how to avoid snapshot integration and use data lifecycle management to boost your operational performance, watch our webinar with Piet!
Piet is a corporate IT architect, specializing in enterprise application integration. While integration solution designs are mostly technology focused, he has learned over the course of more than three decades in various midsize to large organizations that integration issues are usually not technology related, but often have their origin in wrong design choices. The fact that very little guidance was available has prompted him to pioneer the realm of integration architecture, drawing on business process management and complexity science. Piet holds an MSc degree from Utrecht University and offers seminars on integration architecture for IT professionals. In his limited spare time Piet likes roughing it to remote corners of our world.Piet Knijnenburg
Read more blogs
EPC Workflow Software
EPC Workflow Brochure