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.

« Calling all telcos: Monetize the power of digital using B2B2X model | Main | The differences between data-centric and capability-centric architecture - Part 2 »

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.


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.