Enterprise architecture at Infosys works at the intersection of business and technology to deliver tangible business outcomes and value in a timely manner by leveraging architecture and technology innovatively, extensively, and at optimal costs. Stay up-to-date on the latest trends and discussions in architecture, business capabilities, digital, cloud, application programming interfaces (APIs), innovations, and more.

« Why data should drive your enterprise architecture model - Part 1 | Main | The benefits of leveraging information-centric enterprise architecture - Part 3 »

The differences between data-centric and capability-centric architecture - Part 2

Authors:
Dr. Steven Schilders
AVP and Senior Principal Consultant, Enterprise Architecture
Marie-Michelle Strah, Ph.D.
Senior Principal Consultant, Enterprise Architecture


Capability-centric architecture and information-centric architecture are the two most prevalent models in today's organizations.

In Part 1 of this three-blog series, we outlined an information-centric approach to architecture. That approach places business data at the core by decoupling data from application and platform architecture. In this blog, we deep dive into some of the concepts mentioned in the previous blog. Firstly, we describe the key differences between capability-centric and data-centric approaches to architecture. We also explain how they each influence the design of commercial-off-the-shelf (COTS) and custom-built solutions. To know how to expose reusable business capabilities as services, check out our next two blog in this series.

First, a quick summary of our previous blog: Typically, organizations buy COTS solutions that match their business capabilities irrespective of how data is stored, accessed or made available for reuse. Such solutions are often marketed as capability-centric architecture. But, in reality, a COTS solution should be able to ingest external data and extract internal business data. Historically, both these processes use batch processing. However, in today's age of services, there is greater focus on run-time integration through APIs. Nevertheless, data primarily falls within the domain of the COTS application. 

COTS applications: Capability-centric versus information-centric approaches

In information-centric enterprise architecture, the above model is inverted. The COTS solution must integrate across the enterprise information landscape in a solution and vendor-agnostic manner. This approach also decouples data architecture and enterprise information architecture, which are often collapsed when application-specific data architectures are reinforced.

The following illustration and table will clarify the differences between these two architecture models.

Capability-centric versus information-centric architecture for a COTS application

information_centric_EA_Shilders_Strah_2a_sm.png


Differences between capability-centric and information-centric architecture for a COTS application

 

Features

Capability-centric architecture

Information-centric architecture

Data architecture

A black-box that is designed and optimized to support application needs

Remains in a black-box and all application-agnostic data is externalized and synchronized through event-based integration

Relation between application-specific and agnostic data

Intermixed

Decoupled from each other when externalized

Data taxonomy

Is  application-specific

Is externalized and depends on business domain and/or functional context

Exposing data

Done through application APIs or data replication

Done through data services using APIs or data integration/replication adaptors

Removing/replacing applications

Cannot be done without affecting data architecture

Causes minimal impact to enterprise information architecture

Data consumption/extension

Data is not readily available

Data is readily available

Interaction between data and applications

Application is the source and master of its own data

Applications act as systems-of-record by supporting all create-retrieve-update-delete-search (CRUDS) capabilities. Data services act as a systems-of-reference with only read and search-based capabilities (these may change in multi-system architecture)

Using external data sources

Cannot act on an externalized data source.  Application-agnostic data must be replicated into the internal store before process execution. While some applications can call externalized data sources during execution, the data still needs to translated and transformed into the application taxonomy before execution. Such integration creates performance issues and is unsuitable for high-volume and performance-bound transactions

Applications can support inbound and outbound data synchronization through event-based integration. In the illustration, integration is one-way as there is no other application manipulating the data

How applications access data

Several applications use the same data, resulting in data proliferation, multiple access points for the same data and lack of a single and accurate source of truth.

Data is accessed and shared through the system-of-reference data services.  Applications are redesigned to support single application mastering, where possible,  by restricting access (read-and-search only) or by removing capabilities within the application

Data integration

Requires significant effort to move and synchronize data between various applications 

Implementation focuses on integrating data with a reusable core through services

Real-time analytics

Limited to in-built application capabilities and can be applied only once data is moved to the data warehouse

Data is exposed for real-time analytics and AI-based processing

 

At first glance, information-centric architecture implementation appears more complex, doesn't it? But, consider the advantages of using information-centric architecture instead of capability-centric architecture when decommissioning applications or building new capabilities to leverage data.

Custom-built applications: Capability-centric versus information-centric approaches

Unfortunately, COTS solutions have distorted organizational priorities by prioritizing capabilities over information architecture and data reuse. As a result, custom-built solutions have followed the COTS architecture model whereby business capabilities are built over an application-specific data repository (we will discuss service-based architecture in the final blog).

 

Capability-centric versus information-centric architecture for a custom-built application

information_centric_EA_Shilders_Strah_2b_sm.png

 

In the information-centric approach, the key differences between a COTS implementation and custom-built application is how data storage is controlled and how data interaction is designed. Custom-built solutions can be designed to use externalized data stores and integration services.

Ever wondered why there is so much recent emphasis on enabling microservices? This is because more and more enterprises are realizing the value of an information-first approach. Such an approach simplifies the design of enterprise architecture, making it easier to execute digital strategies. As custom applications, microservices have complete control over data as well as business capabilities, leading to greater agility.

Capability-first versus Information-first architecture for custom-built applications

 

Features

Capability-first architecture

Data-first architecture

Data architecture

A white-box that is specifically designed and optimized to support application needs

Application-agnostic data is externalized and integrated with the application through data service APIs. Application-specific data acts as an extension to externalized data and can be designed and optimized to support application needs

Relation between application-specific and agnostic data

Intermixed

Decoupled from each other when externalized

Data taxonomy

Is application-specific

Is externalized, dependent on the business domain and/or functional context and can be translated to application-specific taxonomy, if needed

Exposing data

Done through application APIs or data replication

Done through data services using APIs or data integration/replication adaptors

Removing/replacing applications

Significantly impacts  data architecture

Has minimal impact on data architecture

Data consumption/extension

Data is not readily available

Data is readily available

Interaction between data and applications

Application is the source and master of its own data

Data services are the system-of-record for all application-agnostic data

Using external data sources

Application-agnostic data may need to be copied into the internal store before process execution.  Data services can integrate externalized data

Data services interact with system-of-record data

How applications access data

Several applications use the same data resulting in data proliferation, multiple access points for the same data and lack of a single and accurate source of truth

Data services APIs access and share data 

Data integration

Requires significant effort to move and synchronize data between various applications

Implementation focuses on integrating data with a reusable core through services

Real-time analytics

Limited to in-built application capabilities and can be applied only once data is moved to the data warehouse

Data is exposed for real-time analytics and AI-based processing

 

Release data for AI-driven processing

Now, let us take a look at the target state of capability-centric and information-centric approaches when we combine both types of applications. Surely, the main difference between the two architectures is how data is consolidated and constructed, which leads to varying levels of business agility. On the one hand, data-centric architecture consolidates data instantly, providing market differentiation. For example, enterprises can process business intelligence (BI) or artificial intelligence (AI) logic in real-time using the application, user context and the complete data set. On the other hand, capability-centric architecture requires data integration and mediation/post-processing for data consolidation - making it nearly impossible to leverage BI/AI-based processing capabilities.

Combined view of COTS and custom-built applications for capability-centric approach and information-centric approach

information_centric_EA_Shilders_Strah_2c_sm.png

information_centric_EA_Shilders_Strah_2d_sm.png


So, if you want a sophisticated and data-driven digital strategy, adopting information-centric architecture is the way forward. Interestingly, many organizations know this and are planning strategic initiatives to rectify issues arising from capability-centric architecture. However, actually inverting existing systems into data-centric ones can be challenging. While some may sidestep this process by wrapping existing systems with an additional layer of 'digital concrete' such as services and/or APIs, this will inevitably hinder agility and the ability to proactively compete in the market. 

Discover how information-centric architecture delivers agility for service-enabled enterprises in our next blog


Post a comment

(If you haven't left a comment here before, you may need to be approved by the site owner before your comment will appear. Until then, it won't appear on the entry. Thanks for waiting.)

Please key in the two words you see in the box to validate your identity as an authentic user and reduce spam.