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.

« September 2017 | Main | January 2018 »

October 28, 2017

Purposeful Enterprise -- some thoughts on shaping the enterprise of the future

Author: Sarang Shah, Principal Consultant

We are in the midst of an exciting stage in the evolution of the modern economy, where accelerating technological changes, highly networked world, demographic shifts and rapid urbanization are leading to a disruption that is not ordinary [1]. The effects of these disruptive changes are impacting the prime movers of our modern economy - the businesses' or corporations. In this blog post, I would like to share some of my thoughts and questions about the future of these prime movers.

Let us take a step back and talk about the corporation itself. What is a corporation? What is its relationship with the market? What determines its boundary, size and scope? Economists attempt to answer these questions using various approaches - I would like to specifically point out the idea of cost of market transactions or transaction costs as described in Ronald Coase's seminal work 'the nature of the firm'. Coase points out that 'people begin to organize their production in firms when the transaction cost of coordinating production through the market exchange, given imperfect information, is greater than within the firm' as illustrated in the diagram below.[2]

purposefulEA-Shah.png

Recent technological advances like mobile, cloud, social media, internet of things, augmented reality, block chain, and many more are causing disintermediation and dematerialization at an unprecedented speed and scale. These technologies directly lead to decrease in the transaction costs that we mentioned above and hence they influence the nature of the corporation also. We see these changes manifesting themselves in new digital business models, unbundling of corporations and redrawing of industry boundaries e.g. a mobile company provides payment services, an e-commerce retailer provides credit facilities, and so on.

Along with the technological changes, we are also seeing demographic and behavioral shifts in our economy. For instance, today's customer is more demanding in terms of value they get from the product or service than in the past, as they have easier access and the ability to consult and compare between various products/services in the market as a result of technological advances. In fact, even regulations are also promoting behaviors that allow customers more choice - e.g. sharing of payments data by the banks (Open Banking, PSD2) or mobile phone number portability across network carriers. The same demographic and behavioral shifts that affect the customers also influence the staff employed by the enterprise. We are beginning to see large parts of the workforce are now digital natives, who have access to information and are networked like never before. I believe these shifts impact the way the enterprise functions and is architected.

We are already seeing these shifts impacting the way enterprises function - enterprises that empathize with their customers and put them at the center more so then ever before; enterprises that understand that taking a long view on capital may be more beneficial for all the stakeholders; enterprises that are responsible towards the social and natural ecosystems they operate in and take a circular economy approach to the future; and enterprises that understand that in the future man and intelligent machines will work together collaboratively.

These changes lead us to ask some fundamental questions like: How will enterprises look like in the future? How will enterprises transform and adapt under volatile, uncertain, complex and ambiguous conditions? How should enterprise processes and policies be designed for digital natives and gig economy? How should enterprise ethics evolve as intelligent machines become integral to the enterprise? and many more.

I believe that taking a holistic and systemic perspective is required in shaping the purposeful enterprises of the future and we as enterprise architects have a unique opportunity to do the same. I and my colleagues at Infosys will be writing more about the same in the future blogs here.

 

I would like to thank A. Nick Malik & Steven Schilders for providing their suggestions for this post.

 

References:

[1] No Ordinary Disruption: The Four Global Forces Breaking All the Trends by Dobbs, R. and Manyika, J.

[2] The nature of the firm (http)

[3] The nexus of forces is creating the digital business, Dec 2014, Gartner (http)

[4] Unbundling the corporation, Mar 1999, Harvard Business Review (http)

[5] The self-tuning enterprise, June 2015, Harvard Business Review (http)

 

Note:

The terms 'business', 'company', 'corporation', 'enterprise' & 'firm' have been used interchangeably. The primary intent of this blog is for-profit enterprises, though some of the ideas described above are applicable to other types of enterprises also.

October 21, 2017

The benefits of leveraging information-centric enterprise architecture - Part 3

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


Continuing our three-blog series on information-centric architecture, this blog highlights the benefits of the data-first approach. While explaining how this approach drives agility, we want to emphasize that these blogs do not advocate a complete implementation of information-centric architecture. Rather, we are presenting an alternate view on the two most prevalent architecture paradigms.

In Part 1 and Part 2 of this series, we explored how organizations typically implement systems based on business capabilities rather than data. Such an approach invariably creates extreme data segmentation because system capabilities dictate what data is stored, how many copies are stored and how it is accessed. In today's age, no organization can succeed with fragmented data as data and its relationships - both direct and indirect - are the lifeblood of an organization.

Integration challenges in data warehousing solutions

Data warehousing solutions are quite popular for data integration. However, these solutions involve lengthy processing making it difficult to forge business-critical data connections, thereby diminishing the value of data. Further, data warehousing approaches - and the assigned 'data architects' - become tied to vendor data models. We use the term data architect loosely here. Invariably, these architects behave as vendor-specific master data management (MDM) or enterprise data warehouse (EDW) specialists rather than actual 'enterprise information architects'. Needless to say, this type of centralized and hierarchical approach nullifies any benefit that can be achieved through indirect data relationships such as artificial intelligence (AI) and machine learning.

To be able to make real-time decisions and scale quickly in highly competitive markets, you need to transform your enterprise into a hyper-connected and composable  organization. The danger from delayed decisions cannot be overstated in such an environment. To give you an idea of how important this is, we have put together a graph that illustrates the extent of value lost when there is a delay between a business event and action taken.

information_centric_EA_Shilders_Strah_3a_sm.png

Despite these acute disadvantages, application data architecture is often prioritized over enterprise information architecture. In some cases, this is because vendor-provided platforms and COTS products pre-determine data models and data access. In other cases, capability-based architectures that claim to represent business capabilities are actually application or technical architectures that collapse business capabilities. For example, consider how ERP systems tend to represent either finance, accounts payable (AP) or human capital capabilities.

This traditional approach exponentially delays the delivery of business insights and decision-making because data must be collected and copied across silos to get actionable information. Further, point-to-point integrations across multiple applications with disparate data architecture becomes an effort-intensive process for enterprise architecture as well as data teams. Finally, developing and maintaining these brittle and tightly-coupled architectures exacerbates the delay in the decision-to-value cycle.

Now, let us see how information-centric architecture unlocks value from hidden data to enable business-as-a-service capabilities in digital ecosystems.

Step 1: Integrate data across the organization

First, organizations must integrate data whether it resides in commercial-off-the-shelf (COTS) products, custom applications or microservices. In our earlier blog, we had proposed a layered information architecture approach (see figure below). Here, information architecture is not tied to either application or platform architectures that prioritize technical architecture. Instead, it lays the foundation for composable architecture by leveraging a hub model.

 

 information_centric_EA_Shilders_Strah_3b_sm.png

Information Centric EA: Layered Information Architecture

 


Step 3: Use fit-for-purpose data hub models to gain business-specific insights

 

Our previous blog also illustrated how information-centric architecture can be used in COTS as well as custom-built applications. Here is how the data integration hub architecture works in both cases (see figure below). The data hubs provide representations of data that are optimized for the specific needs of the business. For example, key-based data is leveraged for key-based entity relationships, graph-based data is used to analyze complex interdependencies, time-series-based data is used for sequential analysis, search-based data can be used for complex queries, and so on. Thus, information-centric enterprise architecture reduces the decision-to-value curve because data is grouped contextually and data hubs provide the relevant data attributes in a form that optimizes value creation.


information_centric_EA_Shilders_Strah_3c_sm.png

 

Step 4: Apply AI and BI on insights to achieve decision-as-a-service

 

Data integration hubs and contextual data grouping allow enterprises to design business intelligence (BI) capabilities and machine learning systems that merge programmed intelligence and AI. Further, BI capabilities can extend the base data with specific data requirements needed for analytics. They are exposed through BI services or decision-as-a-service executed for a consumer-specific data context. The key aspect of this design is that business-intelligent capabilities and services can be created, modified or removed without impacting the core and contextual data assets.

 

The end result?

  • Transitioning from traditional data warehouses to a fit-for-purpose model of multiple data hubs helps organizations leverage traditional BI capabilities and next-generation AI and machine learning
  • Prioritizing layered information-centric enterprise architecture makes data and decision-making organizational and architectural priorities

 

Simply put, adopting a strategic model instead of a retrofit model enables AI, faster access to enterprise insights and real-time decision-making. In an era where data is king, these are the key capabilities that enterprises need to become service-enabled.

 

Keep watching this space for enterprise-level case studies and best-practices of information-centric design in microservices, AI and data science.

 

In case you missed the previous blogs in this series, here are the links:

Part 1

Part 2



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


Why data should drive your enterprise architecture model - Part 1

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


Information-centric enterprise architecture is about putting data first during assessment, strategy, planning, and transformation. To create a 'composable enterprise', data must be mobile, local and global across departments, partners and joint ventures. This is important if enterprises are to liberate data to improve insight and develop disruptive and differentiated services. 

To achieve this, enterprises must first decouple business data from application and platform architecture. Decoupling business data gives organizations flexibility as well as valuable insights, which are very important during digital transformation, mergers, acquisitions, and divestiture journeys.

A case of the tail wagging the dog

Today, most enterprise architecture follows a variation of The Open Group Architecture Framework (TOGAF) model (business/information/technology architectures). Here, strategic planning and sourcing recommendations for application portfolios are based on decision-making flows such as buy-before-build or reuse-before-buy-before-build. In the TOGAF hierarchy, organizations are meant to define business capabilities, align information management strategies to the business and choose application portfolios that support those strategies.

However, if you were to speak to any experienced enterprise architect, they will tell you that this is not what actually happens. In reality, most decisions are driven by technical aspects such as applications and platforms rather than the actual business. Invariably, applications and platforms are retro-fitted to meet business needs. If we were to present this differently, it is a proverbial example of 'the tail wagging the dog'.

For example, portfolio rationalization is often marketed as business capability-driven. Actually, the focus is on purchasing commercial-of-the-shelf (COTS) products or components that have some out-of-the-box (OOTB) business or technical capabilities (or both) that can meet predefined business and technical requirements. To minimize extreme customization when choosing a COTS product, most organizations will actively seek OOTB capabilities that fit nearly 85% of their requirements and offer vendor-supported configuration changes.

In case there are gaps in the OOTB capabilities, the COTS solution will undergo some level of customization, which may or may not be recommended or even supported by the vendor. The organization may also build custom solutions, either in the beginning or over time, to support or enhance the COTS solution. In our experience, architects have traditionally designed custom-built solutions around business (or technical) capabilities - whichever is the priority. 

Tipping the scales for business vs. technology

Clearly, capability-driven enterprise architecture has an advantage over technology-driven approaches. It aligns business with IT and focuses on business processes and capabilities. However, it is also inextricably linked to specific applications and their inherent legacy architecture. In case you haven't noticed already, there is irony here: platform and cloud-first approaches often reinforce application architecture instead of business capabilities! This is because the business has to adopt COTS data models and storage options for their data. As a result, business capabilities are collapsed into the vendor or COTS applications rather than standing alone.

Let's see why this is alarming. While business requirements and their associated capabilities may change over time, core organizational data does not. Of course, technology also changes, thereby impacting the longevity of COTS and custom-built solutions, but let us ignore this for now. Thus, the common denominator in using COTS as well as custom capability-driven solutions is that information architecture is not a top priority during design. When data models become tied to vendor-provided models, they are unable to reflect organizational enterprise data models (if they exist) or offer flexible and adaptive information capabilities.

The dog wags its tail

Now, data is the most valuable asset that an organization can leverage to achieve market differentiation and success. No matter the condition - be it enhanced, embellished or partly redundant - core data is the lifeblood of any organization. In fact, one can argue that organizations may still exist if they lost all their applications but retained access to their data. The corollary is dangerously true, too: Without data, an organization would cease to exist.

So, if we were to switch these enterprise architecture paradigms, we could make a case to enable 'the dog to wag its tail'. Here, we would establish information architecture as the primary driver of enterprise architecture. This approach will disengage business capabilities from application platforms and vendor lock-in.

Creating an information-centric enterprise architecture

You may be wondering what the primary requirements of an information-centric enterprise architecture are. Here's a short list:

  • Business data should be segmented from business capabilities. This allows us to change/remove capabilities without impacting the underlying data and add new capabilities that can utilize the data when needed.

  • Business data should be separated from application-specific data that is artificially-coupled and may cause unnecessary bloat. This allows us to remove or add applications without impacting business data.

  • Business data should be segmented appropriately based on its domain

  • Each business data domain should be consolidated into a single version of truth

  • Business capabilities should be designed based on the domain-specific business data and associated functionality requirements

  • Wherever possible, business capabilities should be implemented as reusable services either in COTS or custom-developed applications

  • New or composite capabilities can be added by consuming the services

 

Figure 1: Information-centric enterprise architecture model 


information_centric_EA_Shilders_Strah_1.png

 

Ultimately, such an architecture model will incorporate perspectives of business, information, application, and technology. We prefer to liken it to the layers of an onion: the business is at the core followed by information designed to support the core business needs, applications to address business capabilities that leverage information above that, and the business capabilities mapped to the technology on top. The key premise of this architecture model is that the technology and applications are free to change without impacting the core business data and business architecture.

Deep-dive into the differences between capability-driven and data-centric approaches to architecture in our next blog.


Subscribe to this blog's feed

Follow us on

Blogger Profiles

Infosys on Twitter


Categories