Architecture Made Easy, Part 5

Companies spend large sums of money managing what are perceived as their most valuable assets. People assets are well-managed with a vast set of HR policies and process; and, similarly, financial and
property assets have meticulous oversight and are even insured where possible.

However, when it comes to arguably the most valuable asset of all – data – few of the protections that exist for people, finance and property assets have analogous counterparts to protect
data as a corporate asset. Yes, there are privacy rules and security rules for people and property data; but the plethora of other data, including transactional data, is all over the place like
clothes in my daughter’s bedroom. Yes, some of those clothes are organized in piles, some are hanging in the closet, and some of them are even folded in the drawers. This particular combination
of stuff defines her unique style of individuality.

Similarly, the data asset of each and every company defines its own unique form of individuality. A company’s data reflects its particular marketing efforts, business activities, customer
interactions, product sets, employees, and financial history.

And, just like when another girl in school has bought the same outfit, so too a competitor may duplicate operational processes, imitate products, purchase the same IT assets, and acquire some of the
same employees and customers, but the overall collection is still unique to each company.

Just as the need for particular clothes varies greatly, depending upon the activity, the business need for data also varies greatly, depending upon the area using it and what they are using it for.
In fact, customers, operational support, marketing, accounting, customer service, managers, executives, shareholders and regulators all place a different emphasis on the data they need and how they
are going to use it. However, if the data cannot be located, then informed decision making must give way to coping without solid information.

In a business climate where household names disappear overnight, stakeholders of companies are compelled to consider the risks and rewards of data asset management.

How can the data be exploited by the business to increase profits and manage risks? What data measures should be leveraged by regulators to inform authorities of the degree to which informed decision
making can be supported? What data measures should concern shareholders and investors when trying to determine the investment value of the company?

At a basic level, executive and line management are concerned about their ability to receive accurate, timely information. Customers want their data secured, ease of doing business, and often a
consolidated view of their accounts. Investors are concerned about the health of the business as a function of how it manages its data asset to compete. Regulators are concerned about the potential
exposure that a company running blindly might impose upon an efficient and effective marketplace. So then, perhaps the best place to start this discussion about the data asset is with the owner of
the company’s data asset.

The Owner of the Data Asset
Just as officers of the company are responsible for financial decision making that affects the financial assets of the company, business users need to be
responsible for their business activities that affect the data asset.

Consider a bank manager who must account for every penny of his branch’s transactions. While untold resources are spent to ensure that every financial account is completely accurate to the
penny, comparatively few resources are spent to ensure the underlying data collected from each transaction is equally valid. The customer’s name, address, phone number, tax ID number, birth
date, nationality, mother’s maiden name, and occupation are data that are collected for a purpose; and yet no matter how well the data services organization of the enterprise secures and
protects the data, the concern for its validity seems to be largely non-existent.

While many business users generally believe that the ownership of data and information is the responsibility of IT, others have correctly zeroed in on the fact that responsibility for data is not in
that distant “Land of IT” where all of those files, databases, disks and tapes reside.

What the business executive needs to realize is that the IT staff is responsible only for safekeeping and rendering the data back to the business on demand, whereas the ownership of the data must
reside on the business side with whoever creates the data. In a comparable analogy, accountants are responsible for organizing and reporting financial data that has been provided to them; however,
they are not responsible for the business decisions and activities that generated those financial numbers. In both cases, the responsibility for the accuracy and completeness of the information rests
undoubtedly with the business.

When someone in the business buys or sells an asset, the accountant tracks the financial assets, their cost basis, depreciation, appreciation, accretion and so on,
notwithstanding whether it was a good or bad financial decision. The accountants organize these calculations and tabulations, and then accurately report on them to management and the necessary
regulatory bodies.

Therefore, when someone in the business acquires a customer or up-sells an existing customer, it is necessarily part of their job to gather and properly record the related transactional data. Once
the data has been captured, it is then the role of IT to organize the resulting data and to keep it accessible, backed up and archived. Like the accountants, IT is responsible for reporting on the
data but not the accuracy and completeness of the data provided them. Yes, if automation can help validate the data, the business users should inform IT of the opportunity and need to validate the
data, but the user testing should reveal any such weaknesses in the automation if that had been overlooked.

Ownership responsibility for business data exists before, during and after each business transaction. Before the business transaction, the users need to record and confirm the basic information
necessary to process a transaction, such as defining all of the products and services the company has to offer. During each business transaction, responsibility then continues for recording the
transaction data. After the transaction has occurred, then responsibility for the follow-up servicing of customers or product inventory levels continues.

Throughout the process, it is the business person that is accountable to record the data that is necessary to support the various needs of the enterprise. This would include the collection of
information that may additionally be needed to meet regulatory requirements, as well as any company standards and policies, or information that management has requested to be collected to assist them
with decision making across the company (e.g., product development, marketing, mergers and acquisitions, expansion, divestitures, human resources, facilities and corporate restructuring).

Regardless of whether the data collected by the business user is ultimately retained in paper form, computer form, or taped recordings, it is the business user and the business that are best
positioned to determine the reasonableness and clarity of the data collected.

In fact, the business users that conduct or facilitate business on behalf of the company are the only ones that the various stakeholders can rely upon. Unfortunately, if the business user looks into
the room where the data is recorded and sees a tornado of confusing records, or they see lots of data that they cannot interpret, then the consequences for that company are probably dire.

It is important to note that there has been recent objection to the word “owner.” The problem stems from the fact that some “owners”
occasionally misconstrue the concept of “ownership” by choosing not to share data from their parts of the enterprise. As a result, the word “trustee” has been replacing the
word owner,” since a “trustee” is a guardian of a thing, responsible to protect and care for it, as opposed to an “owner” that halts the game by fetching his ball when
called home for dinner.

Data Asset Issues
The value proposition of data assets stems solely from their use. However, the ability to use it depends completely upon it meeting a threshold of
quality.

Imagine if accounting ledgers had dates, amounts, and descriptions with incorrect values, or had values that were of an inconsistent or invalid format. Auditors, executive management and regulators
would be up in arms.

In contrast, imagine that we add to the aforementioned quality problems the following:

• Duplicated rows of data1

• Missing data2

• Definitions lacking business clarity3

• Fields and values that are unrelated4

• Values that defy interpretation5

• Values encoded by applications6

• Replicated data getting quickly old7

An active and cooperative working relationship between business users and key areas in IT can go a long way to avoid these types of problems from occurring; the data services department and
application development teams can provide the services to avoid these problems involving applications that are developed with those departments.

As the aforementioned data-asset issues manifest themselves, the data assets of the corporation will continue to deteriorate. During these periods, while data assets deteriorate, the cost of IT
infrastructure will continue to increase while the usefulness of the data asset decreases with an adverse effect on business value. Eventually the affected portions of the data asset not only
approach having zero business value, but the value shifts can also become negative as unusable data increases confusion and turns into a liability incurring storage costs.

Data assets can become a large financial burden to a company; however, there are no requirements for reporting on the condition of data assets.

Impact of Legislative Efforts
Other than the assets of people and property, the condition and reporting on corporate “data assets” is outside the scope of current regulation in the United States.

Let’s begin by reviewing the legislative acts that affect data quality, which are the Sarbanes-Oxley Act of 2002 (SOX), the Gramm-Leach-Bliley Act of 1999 (GLBA), and the Health Insurance
Portability and Accountability Act of 1996 (HIPAA).

The Sarbanes-Oxley Act of 2002 addresses financial assets, such as:

• Responsibility of executives to certify financial reporting
• Prohibition of “material off balance sheet transactions and omissions”
• The inability to produce records that would impede an investigation

The Gramm-Leach-Bliley Act of 1999 addresses customer privacy, such as:

• Confidentiality of health, medical and genetic information
• Privacy of social security number
• Protection against fraudulent access by individuals or institutions

The Health Insurance Portability and Accountability Act of 1996 addresses health data, such as:

• Electronic healthcare transactions
• Medical privacy governing employers, insurers, and providers
• Restrictions on coverage regarding prior conditions

Some additional forms of legislation that are noteworthy include:

• The Corporate Information Security Accountability Act (CISAA) of 2003, which pertains to cyber-security
• The Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act (USA PATRIOT Act) of 2001, which pertains to intelligence gathering
• The Private Securities Litigation Reform Act (PSLRA) of 1995, which gives shareholders the right to bring a private action against a corporation to recover damages for securities fraud from
  material misrepresentations or omissions

• The Fair Credit Reporting Act (FCRA) of 1970, which governs the use and dissemination of consumer credit information

As we delve into legislation, we find that the condition of corporate “data assets” in the U.S. is outside the scope of current law, regulatory bodies, and investment disclosure
rules, and is also frequently below the radar of executive management, which is focused on people and property because they appear prominently on the company’s balance sheet.

That said, what is the business impact of data assets that are in stress?

Impact to the Business
Data is the means by which an enterprise records knowledge. Once collected, this knowledge can be called on to drive informed decision making.

Surprisingly, financial information can be one of the least significant indicators of a company’s health. A cash rich company that manages the knowledge it has amassed poorly, can rapidly be
overtaken by competitors that develop better products, perform marketing more effectively, restructure more rapidly to better adapt to changing market conditions, and/or provide better customer
service.

There are a number of value-creating and value-sustaining capabilities that foster continued financial health. Value-creating and value-sustaining capabilities must specifically combat the four
challenges of:

• High infrastructure costs8

• The lack of a unified view of customer9

• High speed to market hurdles10

• Speculative decision making11

When the corporate data assets are managed appropriately, the value proposition of useful information is that it:

• Permits lower infrastructural costs that allow competitive product pricing and/or increased profits
• Allows customers to be better understood and serviced
• Accelerates product development
• Enhances decision making

Companies that particularly excel at growing their customer base themselves are the ones that demonstrate the greatest control and management over their corporate data assets. The companies that
grow primarily through alternate means have a need to understand the dynamics at work. However, even companies that were once their industry’s leader at growing their customer base themselves
can face data asset challenges through no fault of their own by acquiring additional data problems of other companies with each new acquisition and merger.

Drivers of Data Asset Deterioration

Business Contributions

The business value of corporate “data assets” can deteriorate due to a number of events. Although deterioration usually occurs over a long number of
years, it can also occur surprisingly fast.

The most common events that lead to rapid deterioration include:

• Mergers and acquisitions
• Organizational challenges
• Developing stand-alone applications
• Buying third-party software products

Mergers and acquisitions – Companies that grow suddenly and rapidly through mergers and acquisitions often acquire a multitude of disparate data and
applications that impact data quality. If retained as separate applications and data, the infrastructural costs of IT to maintain multiple technologies and systems will necessarily increase. However,
the costs of true systems consolidation, as opposed to simply feeding a common general ledger, can generate substantial acquisition expenses that were previously unanticipated.

Organizational challenges – Companies that employ a federated business model, with multiple lines of business in terms of products and services, often
operate better as an array of business silos. Even in IT, silos are highly effective for technical specialties that correspond to a technical discipline, like the various specialties in medicine.
Although it makes perfect business sense to silo lines of business, the redundancy that results from IT creating support organizations that mirror line of business silos creates inefficiencies that
not only raise the costs associated with providing services, but also create more opportunity for inconsistencies across IT silos, thereby contributing to increased complexity.

Developing stand-alone applications – When every business automation effort calls for a separate solution, the most common result is to create many
separate applications, each with its own database. Although each stand-alone application outside a central architecture is quicker to develop, it ensures that the corporate data asset will continue
to increase in complexity. While attractive in the short term, the approach of creating stand-alone applications almost always leads to the highest total cost of ownership for the organization in the
long term.

Buying third-party software products – Purchased applications introduce yet another set of ‘data assets’ that have not been integrated into
the company’s data environment. Many companies choose not to map purchased data assets to their own data assets, further complicating the ability of business and IT personnel to correlate like
information. Introducing disparate data into the environment by purchasing software products can lead to the same toxic effect on corporate data assets as do mergers and acquisitions.

Well intentioned enterprise architecture principles, such as “Buy before Build,” can inflict substantial harm upon corporate data assets.

Present in most almost every company, the above-mentioned principle is an example of one of the most powerful business drivers that contributes to the deterioration of data; however, there are also a
multitude of technical drivers. As such, we will highlight the single most prominent factor that impinges upon the quality of corporate data assets.

Drivers of Data Asset Deterioration
Technical Contributions

Data is often more complex than it appears, and almost always more complex than it should be.

Often unappreciated by business users, the process of “data modeling” is an important one, which helps simplify the use of data assets more than any other activity. In fact, the primary
reason for even using a model of any type is to illustrate something so that it is easy to understand. The primary challenge that data modeling presents, however, is that each person that creates a
model views the world differently than the next person. The way that this manifests itself is in how the modeler chooses to create abstractions.

A good example of this is the confusion and complexity that results when “vendor” and “customer” information are modeled together. The business identifiers for these two
things are disparate from one another because customers are identified by personal information including their residence, whereas vendors are identified with their business information.

Once this over-abstraction has been modeled, the data relationships to other data assets become confusing. Vendors provide products and services; customers do not. Customers buy the company’s
products and services; vendors do not. In the rare event when a customer was also a vendor that the company did business with, it would not be able to determine that fact because the business
identifiers are disparate.

As such, the complexity of data in databases and the complexity of data models can have an inverse relationship. Data in databases becomes increasingly complex when
data models overly abstract the business requirements being represented. (See Architecture Made Easy: Rules of
Abstraction.)

Managing Corporate Data Assets
There are three basic steps that may be adopted to protect a company’s “data assets.” First and foremost, every company must recognize that
organizational ownership of their “data assets” is a necessity.
 
Ownership – As everyone learns at some early point in their life, no one cares for your favorite teddy bear like you do. Data is no exception; other
people are not going to make the effort to care for it.

“Public” property is subject to the whims of the various individuals that have the ability to affect it in any way.

The quality of the corporate data asset must be managed beginning where it originates, and then strict attention must be paid to each subsequent process that touches it. When the appropriate owners
of data are on the business side of the company, they are much more likely to have an appreciation of the business value that the data has to offer each area of the enterprise. It is equally
important for IT staff that deal with business requirements in architecture and design to acquire in-depth business knowledge by becoming licensed and accredited in the business where possible, with
mandatory job rotations into the core business areas of the company.

In fact, few companies have business owners for their “data assets.” However, official business owners are sometimes identified, in which case they are often referred to as data stewards
or data custodians.

Location – The next most important aspect of managing any asset is to know where it is. Not only is it important to know where the data is stored, but one
also needs to be able to retrieve the data whenever it can be at all helpful for making a decision.

Also, the ability to quickly identify and retrieve records to support internal audits or court orders can save the corporation the financial costs and public embarrassment associated with fines and
penalties that may be levied by either a regulatory body or a court.

Data architecture – The third aspect for properly managing data assets is to get a complete view and understanding of the five essential areas for
appropriately managing data assets.

The five key areas that illustrate the landscape of a company’s data assets include the following profiles12: 

1. Architectural profile
2. Data integration profile
3. Data management profile
4. Process maturity profile
5. Metadata profile

Some of the key questions to assess your architectural profile include:

• Does your firm have an enterprise information architect that communicates with the CIO?

• Is there a set of enterprise information architecture principles, architectural framework, strategy and best practices that guide the architectures of application
  development?

• Do the information architecture principles, architectural framework, strategy and best practices apply to software acquisitions?

Summary
As corporate data assets deteriorate, so does the ability to operate efficiently and intelligently, thus hindering the company’s ability to compete for new
customers.

Everything a company knows and can discover about its business is based on its data assets. This includes all of the information ever collected about the business in the past, present, and in the
future.

However, the rate at which a company’s data assets decrease is not usually obvious to the business users and IT staff. The reason is simple.

The deterioration of data assets is actually a form of “corporate dementia,” and like dementia, symptoms gradually appear over time and are often mistaken
for normality.

Sporadic data quality issues will always occur, which is why data assets naturally deteriorate without governance. However, if the frequency of data quality problems gradually increases, a sense of
urgency tends not to emerge. By the time data problems are deemed severe and systemic, it is clear that the data is not being managed as the corporate asset that it truly is.

Operating a business without the benefit of the knowledge represented by the company’s data assets, and making decisions without objective metrics and measures, places any organization at a
competitive disadvantage to another organization that has greater utility of its data assets.

In summary, when we consider the gaps in legislative, regulatory and executive oversight of data assets, and the risk that this poses to the health of a company,
perhaps it is time for investors to request an independent health check of their company’s data assets.

As for this enterprise architect, when I see the condition of “data assets” of financial services companies being acquired, it is no wonder why many of them are for sale at such
incredibly low prices.

However, without determining the cost of consolidation or the cost of absorbing the acquired infrastructure, it is like IT is being left holding the bag.

This lack of awareness that corporate data assets are a component of every company’s health and value that contributes to the “Trojan Horse” effect that toxic data assets have upon
an otherwise healthy organization. However, with the proper awareness, preparation, planning, and investment, almost any unhealthy data asset can be brought back to health.

That said, the level of investment that would be necessary to bring data assets back to health can be so high that even the fire sale prices paid for some acquisitions may be significantly too
high.

Please feel free to express yourself if you enjoyed this article, and don’t hesitate to indicate which articles in the “Architecture Made Easy”
series are useful to your organization. In addition, corrections, enhancements, and suggestions are always welcome and are requested.

[Assessing Company Health: The Asset That Investors, Regulators, and Legislators Need to Recognize is the 5th article in the AME Series] (JLuisi@metlife.com)

Stay tuned, because the sixth article in the series is intended to represent a cornerstone in the “Architecture Made Easy (AME)” series.

End Notes:

1. Duplicate rows of data – databases can protect against duplicate business data from being stored when business fields are used to uniquely identify
   data. However, databases sometimes disregard this by substituting business identifiers with sequence numbers that allow duplicate data.

2. Missing data – when performing data entry, users sometimes skip over the fields that are not mandatory, thereby proliferating missing data.

3. Definitions lacking business clarity – field names are often insufficient to accurately identify the business definition. Too frequently definitions
   are left blank, or are ambiguous.

   For example, a field named “Trade Date,” may be documented by IT staff as “The date when the trade occurred.”

   However, in business terms does it mean the date when the order for the trade was placed, the date when the order was approved by a principal, the
   date when the order was executed, the date when the order settled, the delivery date of the securities, or the date when the funds for the executed order finally cleared?

4. Fields and values that are unrelated – database fields can actually be reused for other than their original business purpose. This is caused by well
   intentioned individuals as a means of saving time and budget by not involving the data management services to define new fields and remove the ones that are no longer in use. The problem that
   emerges is that the field name and data value become unrelated to one another.

5. Values that defy interpretation – audits on data and rigorous field edits can help prevent interpretable data.

6. Values encoded by applications – there are various ways that application programs may encode data. Complex encoding can make it impossible to
   interpret data values without the aid of the corresponding application programs.

   For example, a person’s contact information may refer to the person whose life is insured, the person that paid the bill, the beneficiary, or a conservator or guardian. In such a situation
   the application would be needed to figure out which person it really is. This problem becomes exacerbated when a field has multiple possible business definitions. (See “Architecture Made Easy: Rules of Abstraction,” TDAN, Volume 12, Issue 4, April 2008.)

7. Replicated data gets quickly getting old – as soon as data is copied, the original data values can be changed, causing the data to be out of synch. As
   such, the age of copied data becomes an important means to determine the probability of the data remaining accurate.

8. High infrastructure costs – Infrastructure costs manifest themselves in the form of data storage costs, database costs, software license costs,
   hardware expenses and IT personnel costs.

9. Lacking a unified view of customer – This is a myopic condition that inhibits viewing a customer across channels, products, regions and lines of
   business. The common ways that it affects the business is that it impedes the ability to provide: customer service, identifying cross sell and up sell opportunities, and in financial services it
   also inhibits the ability to determine global financial exposure.

   For example, when it is difficult to associate multiple transactions to a customer it can only help activities such as money laundering and fraud more difficult to
   determine.

10. High speed to market hurdles – These delays are the culmination of a complex business analysis and software development process that must interface
    with an excessive number of applications and databases.

11. Speculative decision making – This limitation is a symptom of the gradual decrease of useful data. As this occurs, management has less and less data
    that can used to support objective analysis of the things around them.

Data asset survey from The IQ Works, (permission granted to the authors to reproduce the following as long as credit is given to its source: www.TheIQWorks.com)

Architectural profile –

• Does your firm have an enterprise information architect that communicates with the CIO?
• Is there a set of enterprise information architecture principles, architectural framework, strategy and best practices that guide the architectures of application development?
• Do the information architecture principles, architectural framework, strategy and best practices apply to software acquisitions?
• Is there an enterprise conceptual data model that identifies all categories of data across the enterprise?
• Do architectural disciplines span the entire SDLC?

Data integration profile –

• Does the enterprise have a single general ledger system, as opposed to multiple that feed into a corporate general ledger?
• Do applications strictly leverage data where it originates, as opposed to leveraging copies of that data?
• Does customer enter the company from multiple places within the business?
• Are all business locations and methods where customer data enters the company documented?
• Do all of the business entry points of customer data capture it into a common database?
• Do all of the business entry points of customer data capture apply uniform data editing rules?
• Are DMS designs enterprise-wide or application specific?
• Are third-party package database design mapped to the enterprise conceptual data model?
• Do projects share databases that are based upon the conceptual data model, as opposed to having a database per application?
• Does all strategic data have a single system of record?

Data management profile –

• Does your firm have a data steward or data custodian for each line of business?
• Are there business initiatives to improve data quality with formally defined measures?
• Does the CIO regularly report on data quality to the executives?
• Are data quality metrics included in management objectives?
• Does the DMS organization own, control and perform logical DB design?
• Does the DMS organization own, control and perform physical DB design?
• Do 90+% of all databases have logical data models?
• Are 90+% of the logical data models developed by business domain experts, as opposed to application development team staff?
• Do 90+% of the logical data models have complete attribute and entity definitions that the business would understand?
• Have 90+% of all logical data models been approved by the business, as opposed to IT business analysts or software developers?
• Do 90+% of all logical data models have a distinct physical data model associated with it, as opposed to logical models that mirror the physical design?
• Do the true business keys, as opposed to synthetic keys (sequence numbers), used to ensure database integrity enforced by the DBMS?
• Are applications required to pass through a data virtualization layer, or do they access physical databases directly?

Process maturity profile –

• Are logical data models used to develop test plans?
• Do application teams provide a profile of application usage that is maintained as input into the physical design process?
• Are rigorous conceptual, logical and physical data modeling standards applied across the enterprise?
• Is data access and manipulation logic kept completely separate from both business logic and presentation?
• Are 90+% of all DDL generated using physical data models?

Metadata profile –

• Is there a formal process for developing and maintaining the association of databases with the conceptual data model?
• Are physical database designs tightly associated with the conceptual data model?
• Is there a shared metadata repository for data model metadata?
• Is there a shared metadata repository for operational metadata?
• Are operational processes supported with automation, which specifically capture operational metadata?
• Is business intelligence used to visualize the dynamics of these operational processes?
• Is there a shared metadata repository for production data structure metadata?