In the last post, we talked about applying the Kaizen approach to data management to achieve a culture of continuous improvement on our data teams.

In this post, we will use the KonMari method of simplification, recently made famous by Marie Kondo, as a lens for considering what to keep and what to purge in our business data repositories.

As always, we will also give some best practices for how to establish policies around archiving and purging your company data.

Data Lifecycle Management: Archiving and Deletion

As mentioned in previous posts, the final phases of Data Lifecycle Management are Archiving and Deletion.

These phases help to ensure that we keep and maintain only that data which is required for our business. But how do we determine what to keep active, what to archive, and what to purge?

We can apply some concepts from the KonMari simplification method to our data strategy here to help us decide.

Rule 1: Make the Commitment

Kondo states that the first step in KonMari is committing to achieving your goal. This may seem like an obvious first step for any endeavor, but many companies fail to establish a data retention strategy.

It is not uncommon for businesses to take the approach that keeping all data (sometimes even in a “hot”, or readily accessible, repository) is the way to go. This tactic usually stems from either:

1. an explicit belief that you cannot go wrong with keeping too much historical data
   or
2. from having no capacity to prioritize a retention strategy.

Either way, the “keep everything” strategy is misguided for 3 reasons.

First, the more data you keep, the more time it will take to recover in the event of a crisis.

Crisis can take the form of:

• a lawsuit or an audit that requires retrieval of specific information

or

• a natural disaster, human error, criminal activity or another event that demands restoration of data to a particular point in time.

In any case, restoration time is critical during these events. The more time it takes to retrieve the required data from your archive, the longer it will take for the business to recover.

Second, while data retention is a necessity, it is also a liability and entails responsibility.

Businesses must take the responsibility to respect consumer privacy rights very seriously. Part of this responsibility entails keeping consumer data for no longer than is required or for any purpose other than that for which the consumer gave consent. Even if your company does not fall under the regulatory jurisdiction of privacy laws like GDPR, CCPA, or PIPEDA, the business is nevertheless liable for securely and responsibly maintaining its consumer data.

With any data that is retained comes the possibility that it could be stolen, leaked, or misused. This risk is unavoidable, but preserving unnecessary archives of historical data is a liability that ought to be avoided.

Third, “Data stores don’t grow on trees…”

A well-crafted data strategy can reduce the financial cost of maintaining your data repositories, but increasingly large data stores cost the business money nevertheless.

There are also performance, time, system resource, and opportunity costs associated with maintaining large data stores.

So, in short – make the commitment to tidy up your unwieldy data repositories!

Rule 2: Imagine Your Ideal

Compliance regulations do some of the work of envisioning the ideal for us in the data world. Still, take the time to consider the ideal composition of your data repositories. Doing this can help you to think strategically about what should be kept, how and where to keep it, and for how long.

As mentioned in the previous post in this series, consider both regulatory requirements and the needs of the business for reporting, analytics, and strategic planning when determining what to keep. Consult business leaders and business analysts about what data is needed and for how long. You can even create a formal data contract for critical data elements in your business.

Rule 3: Finish Discarding First

Obviously, deleting data should always be done with extreme caution and forethought.

Nevertheless, once you have performed an audit of your data repositories and have determined your retention strategy, you should begin implementation by purging unnecessary data. We will discuss more about how to perform this action safely and according to best practices below.  

Rules 4 and 5: Progress by Category and in the Right Order

For the purposes of purging and archiving data, we should be thinking in a criticality/age matrix like the one below – beginning in the upper left corner and working down and to the right.

You should make incremental passes across departments in these stages, beginning with the oldest and least important data in each departmental area.

Rule 6: “Does it Spark Joy?”

Ok, ok – I admit this iconic final question from Kondo is much less suitable to data retention. However, there still may be an important (if less-than-perfectly-measurable) question that should be asked by data teams before coding a delete.

Does a business leader strongly prefer to retain certain data despite the lack of any clear regulatory or business-driven reason for doing so?

If so, keep it…unless doing so presents a serious risk or concern. If you feel there is a serious risk, continue to voice your concerns. Otherwise, just wait and continue to get clarification.

Now for some best practices…

Keep in mind that the practices listed here do not include the critical practice of backing up your production data, which has been discussed in previous posts (here, here, and here). Always make sure that backups are in place before beginning to archive or delete data.

1.     Replicate and archive data “in-flight”.

Archiving and/or replicating your data at various points in your pipeline is a best practice. Process failures in data pipelines are not uncommon, and you need to be able to recover data from earlier stages of the pipeline if you need to reprocess the data.

3 common examples of this practice, which should include purging data after an established retention period, are:

• Moving imported files to an archive folder
• Replicating transactional databases to a staging database before further processing by downstream systems
• Staging imported API data in its own table or database before integrating with internal systems.

2.     Archive in cold storage and protect the archive.

Consider how you will store data that has served its immediate purpose and has been determined to be a candidate for long-term storage. There are pros and cons to each method, and a combination of archiving methods may be appropriate for your different data sets. Here are some options and considerations.

• Onsite physical storage
  • Pros: ease of access in an emergency, familiar technology
  • Cons: vulnerable to tampering, theft, and physical damage/natural disasters
• Offsite storage (tape, optical disk, magnetic hard drives)
  • Pros: well-established, relatively inexpensive, usually more secure than onsite
  • Cons: slower recovery times
• Cold cloud storage
  • Pros: speed and ease of recovery, alleviated burden of maintenance, built-in security, inexpensive
  • Cons: potentially less familiar to established IT departments than traditional methods
• Data lake
  • Pros: accessibility, speed and ease of recovery, suitable for use with emerging technologies, built-in security
  • Cons: less-established, steeper learning curve, potentially expensive, requires careful governance of user access

3.     Don’t forget critical data that is managed by third parties.

Over time, businesses may find that a significant body of company data resides in data stores managed by third parties. Since maintenance has often been delegated to vendors in these cases, archiving this data is sometimes overlooked.

While there may be an ability to set a retention policy, it can be very beneficial for many reasons to work with your vendors to set up an extraction process to archive a copy of your data from these systems into your own repositories as well.

4.     Establish retention schedules and procedures for purging data.

Business, regulatory, and legislative needs dictate what should be saved and for how long, and these may differ between data sets. Establishment of policies and procedures for deleting data will ultimately be the responsibility of data owners.

These policies should address the following areas:

• Who is authorized to purge data?
• In what maintenance windows can this process occur since deletion can go slowly and data processing jobs/replication must be disabled?
• How will notification be given to the business?
• What validation and integrity checks must be in place?
• What rollback procedures will be used if necessary?

Just the tip of the iceberg…

There is much, much more to say about all these topics.

If you have made it as far as committing to cleaning up your data but the rest seems overwhelming, never fear! There are many vendors that are happy to help with all levels of assistance.

If you have a good handle on your archiving and deletion processes but would like assistance with a SQL Server implementation of them, reach out! We are here to help.

The post Archiving and Deletion Strategy…KonMari for Data Management? appeared first on The SERO Group.

This refrain is more common than you think in IT departments of all sizes. Or maybe you live that reality every day and are fully aware that clunky, error-laden processes eat away at your team’s efficiency (and morale).

Data management and continuous improvement may sound like they should always go together, but they often don’t.

Many times our data management practices involve too many business-critical data processes that break regularly and need to be improved, but we have no time to make the needed improvements because there are so many data processes that need to be “managed” (a.k.a. remediated regularly).

So, how can we break this cycle?

Welcome back to the second of three posts on how to refine your strategy for Data Lifecycle Management (DLM)!

In this post, we will focus on Data Management as the second of the three DLM stages: Data Collection, Data Management, and Data Deletion.

Kaizen for Data Management

The Kaizen approach, famously championed by the Toyota corporation, suggests that small organizational changes can lead to a culture of continuous improvement. This culture will ultimately lead to better processes, greater efficiency, improved outcomes, and increased morale.

The Kaizen Institute states,

“As part of the corporate culture, continuous improvement becomes an ongoing process integrated into the organization’s daily activities. Employees are encouraged to challenge the status quo, suggest ideas, and implement improvements. Continuous learning and development are valued, and mistakes are seen as growth opportunities.”

This means that adopting a Kaizen approach to your data management strategy can be a lever for driving a continuous improvement culture on your data team without sweeping, drastic changes.

Small improvements to existing processes can slowly bring significant reduction in process failures, and improvements in efficiency, accuracy, and team morale. (Here is a short article about applying a Kaizen approach in an IT context.)

So, how and where can we improve our data management?

Where should you look to start identifying small improvements that might be implemented?

Consider the areas below with your team. Most likely you will find that you are very strong in some areas, but perhaps there are areas that have not been addressed at all. Start with the lowest hanging fruit, and bit by bit you will find that you are slowly filling the gaps and addressing the technical debt that every established data team faces.  

First, analyze your data structures.

The applications, tools, and data processes in place for your company will impact the data structure that needs to be in place for it to be usable. Unfortunately, these requirements rarely align.

When you think about the flow of your data, think about consistency of format and type. As data flows into your system, it is often riddled with discrepancies in format, data type, and even the information it contains (but we will save that for another post).

As your data flows downstream toward the consumer, it should become more and more aligned in these areas. Why? Because the more points of contact that your technical teams must have with it (to transform it for particular use cases, etc.), the more points of failure you can have.

Strategic policies and governance and centralized data management can really help, but you don’t need an operational overhaul to improve!

In line with a Kaizen approach, try encouraging small changes in these areas:

Establish data standards

This will be an ongoing process. You will want to give thought to what your core standards should be, especially for mission critical data elements like identifiers, account numbers, etc., since these are more difficult to change once processes are mature. However, your standards will expand and refine as your business matures its data processes.

Adopt an enterprise modeling tool

Document and catalog your data standards using a modeling tool. Include all the metadata associated with your data objects and their relationships. The business will use the resulting documentation at every level (system administration, development, business analysis, and report consumption) for understanding and interpreting the data.

Transform your data with consistency

Wherever your transformation layer lives in your processes (and hopefully there are as few of these as possible), always architect toward your established data standards.

Establishing governance and centralized management can really help here, but feel free to start small! Apply these principles to new processes and only to established processes as they require other changes. Encourage a culture that celebrates these improvements and looks for opportunities to make things better.

Implement database source control

That’s right – employ a source control process for your database objects. Many companies do not take this step. However, having source control in place does not only protect your team from losing important data objects. It can also help ensure that new structures follow established standards when code reviews, pull request approvals, and other best practices are in place.

Structure your deployment process

Lastly, establish protocols around deployment. Some options include:

• Creating a deployment cadence that uses established deployment windows
• Setting up a change advisory board for reviewing changes before approving them to be deployed to production
• Designating deployment managers that are responsible for deploying code
• And, of course, you can always automate your deployments! Just be careful to include the appropriate guardrails.

Remember – slow and steady wins the race with continuous improvement.

Second, evaluate your data pipelines.

Outside of data structure, there are other data process considerations that need to be evaluated as well.

Accuracy & Reliability

• Are your data ingestion and replication processes accurate and reliable?

Sometimes when evaluating our pipelines, we find that issues with error handling, purge processes, SFTP, APIs, replication, logging or any number of other processes are causing duplicative, inaccurate, incomplete, or undelivered data transfers. Look out for these and correct them as you find them.

Maintenance & Scalability

Also, ask yourself these questions:

• Are you frequently stretching the limits of any of your allocated hardware, VMs, databases, or network resources?
• Are any of your system resources in need of upgrades or patching? Are you missing protocols to ensure that these are completed?
• Are there other systems, applications, technologies, or vendors that might suit your current or projected needs better?
• Are your data processes too slow? Do they struggle with the amount of data that must be processed by them?

If your answer to any of these questions is “yes”, then you have opportunities for improvement (slow and steady…).

Third, never forget about security with data management.

Security should always be top of mind when considering your company data. Here are some areas to evaluate.

Security – External

Review the security around the infrastructure supporting your company’s data processes for points of external connection. Pay particular attention to any processes that utilize third party tools or that export or extract data to/from external sources.

Security – Internal   

For internal sharing and usage, security measures should be concerned with careful provisioning of access to data and systems. For lower-level systems, be sure to mask or de-identify any sensitive data.

Further, for sensitive or confidential data, give careful consideration to protecting against any intentional or unintentional data leaks. Areas to consider creating policies around include:

• Unsecured physical devices or paperwork
• Keeping only what data is necessary
• Emailing sensitive data
• Downloading data to personal devices
• What to do if a suspected data breach has occurred

Is your head spinning? Don’t worry!

Remember that data management is an ongoing process of continuous improvement, and we will delve into many of these topics more deeply in upcoming posts.

In the meantime, if you have a pressing need and could use some help detailing a roadmap, let us know! We love to help empower continuous improvement with our clients.

“We cannot become what we want to be by remaining what we are.”

– Max DePree

The post Data Management Strategy: A Kaizen Approach appeared first on The SERO Group.

Welcome to the first of three posts on how to refine your strategy for data lifecycle management. In this post, we will look at how to evaluate your data collection processes for improvements.

Data Collection in Data LifeCycle Management (DLM)

As has been noted in a previous post on the difference between Data Lifecycle Management (DLM) and Information Lifecycle Management(ILM), there are fundamentally 3 phases of Data Lifecycle Management (DLM) into which all physical data-related tasks fall: Data Collection & Creation, Data Management, and Data Deletion.

As an IT leader, there are two important exercises you should perform to evaluate your data collection strategy. By performing these, you will produce living documents that should guide how your company creates, ingests, and consumes data now and in the future.

First, perform a data collection audit.

The first step in evaluating your DLM processes is to gain a complete understanding of the data collection processes your company is currently using. The best way to do this is through an internal audit.

Your data collection audit should include answers to the following questions:

• Where is data coming into your systems (websites, transactional systems, vendors)?
• What systems or processes are used to create or collect data (software, web forms, APIs, FTP)?
• What data formats are being leveraged by these processes (SQL, JSON, CSV, XML)?
• What security, threat mitigation, backups, and archiving processes are in place for these processes and data stores?  (Here is a good summary of what to look for.)

Finally, examine the information you gathered through a strategic lens. Look for vulnerabilities, inefficiencies, and pain points in your processes. Then work with your team to devise a strategic plan and implementation timeline for achieving improvements in these areas.

Second, create a data tracking plan.

Now that you have audited your data collection processes, you should give thought to why you are collecting the data that you are and what data needs to be collected. Consult business analysts in your company about which metrics they would like to track. This will help you understand what data points need to be collected. Likewise, find out what government regulations dictate about what data should be collected and retained.

Ask questions like:

• Is the right data being collected?
• Are there any missing data points?
• Are you collecting irrelevant or duplicated data?

Bridge the Gap

Undoubtedly, it is tricky to bridge the gap between the business, which has ideas about what data they would like to track, and the technical team, who knows how to track it. A data tracking plan is a tool that can help with this.

While some people strictly define what a data tracking plan must consist of, a simple plan is often sufficient. Your data tracking plan defines your primary business objects (customers, products, stores, etc.) and the metrics or events surrounding them that your business would like to have more information about.

Before spending time creating your own, take a look at the many templates available to get you started. Here is a link to an evaluation of a few free templates to start your research.

Create the plan

Once you have your template, start your internal planning discussions with questions like:

• What core business objects are we concerned with?
• What metrics do we care about for those objects (that is, what do we want to track about them)?
• Why do we want to track these metrics?
• What data needs to be collected to obtain these metrics and how will it be defined?
• Where can the data be obtained? Do we already collect it?
• Who will govern the information once we have it?
• Who will manage the data collection?
• What format does the data need to be in to be useful?

It can certainly be challenging on many fronts for the business and IT to come together to create a data tracking plan. However, facilitating this will be well worth the effort in terms of the clear data strategy objectives that will be produced. Avoiding the costs associated with misguided data projects will more than outweigh the time and energy spent in coordinated planning.

Finally, update your data strategy, and implement changes.

Once you have assessed your data collection processes and have identified improvements, you’ll need to assign priorities to your findings. Work with both the business and your technical team to set these priorities, as well as to build a roadmap for implementation.

As can be seen, the information you have gathered through cross-functional cooperation and through using these tools will help you to make a strong case to business leaders for the importance of these strategic improvements.

Want to learn more?

Looking for more information about Data Strategy and how it can help align IT and business goals? Check out these posts.

If you’d like to learn more about how we approach Data Strategy, or if you have some concerns about your SQL estate, give us a call. We can help.

The post Data Collection: Two Key Tools to Improve Your Data Strategy appeared first on The SERO Group.

Recently, we began a series of posts on data strategy by asking whether your company data is an asset or a utility. We then uncovered 10 Data Storage Considerations to Improve Your Company Data Strategy. In this post, I will argue that recognizing the distinction between DLM and ILM is important for IT leaders to help their companies get the most out of their data.

Now, the difference between Data Lifecycle Management (DLM) and Information Lifecycle Management (ILM) might initially seem like hair-splitting. However, while DLM incorporates management policies for the physical aspects of data as data (type, size, location, age, etc.), ILM addresses the content of the data as information (its accuracy, reliability, sensitivity/confidentiality, etc.).

Here are some of the differences and why both are important to consider.

Data Lifecycle Management

At its highest level, DLM addresses data creation, data management, and data deletion.

Within these categories, there are many other elements of data management that are included as well:

• Creation / Collection
• Classification
• Redundancy
• Duplication
• Integrity
• Usage and Availability
• Sharing
• Storage
• Security
• Archiving

All these data process elements when viewed through DLM are fundamentally concerned with the physical aspects of managing data. Failing to address these areas in your data strategy is to gamble with the health of your data structures and the value of your company data.

Information Lifecycle Management

On the other hand, ILM addresses issues associated with the information the data contains. ILM establishes policies that manage the data quality, business relevance, regulatory compliance, and legal liability of the data.

Many of the specific areas addressed by ILM establish protocols for processing data in a way that ensures data accuracy, reliable delivery, protection of sensitive information, and compliance with data privacy laws. Some elements of ILM can include:

• Data De-Identification / Masking
• Data Quality Frameworks & Audits
• Development and QA Environment Refreshes
• Source Control
• Master Data Management
• Classification and Governance
• Sharing & Usage
• Security
• Regulatory Compliance Audits

While many elements of the data lifecycle have relevance in both management models, they are viewed through a different lens in each model.

So…Who Cares?

So, why does recognizing this distinction matter? Will your business really suffer without it?

The answer is that it matters because if this distinction is not recognized, the two sets of management policies can get conflated, with one getting largely ignored. When either DLM or ILM is neglected, important elements of the data lifecycle can appear to be fully managed when in fact they are only partially addressed.

Perhaps even more importantly, when IT leaders do not see these management policies as distinct, they risk missing out on the benefits that come with using both together, like:

• Improved system performance
• Increased availability and accessibility of data
• Improved data quality
• Increased data consistency across the organization
• Improved recoverability
• Increased security
• Increased user satisfaction
• Controlled costs
• Improved regulatory compliance

In upcoming posts, we will unpack these models further while exploring more ways to improve your data strategy.

Want to work with The SERO Group?

Would you like some outside input in any of these areas? We love to work alongside IT leaders and their teams to help them establish the use of best practices in their data environments.

If that’s something you’d like to learn more about, let’s have a conversation.

The post Are Information and Data Lifecycle Management Processes Different…and Who Cares? appeared first on The SERO Group.

Recently, we began a series of posts on data strategy by asking whether your company data is an asset or a utility. In this post, we will look at 10 key data storage considerations that should be evaluated as part of your company data strategy.

What is Data Storage?

Data storage can be broadly defined as the collection and retention of information using digital technology.

Sometimes data storage refers to the physical hardware itself. Other times, it includes the processes connected with storing data. Both are important when considering data storage in the context of your company data strategy.

So, we can think about data storage in two categories. First, we will consider the storage infrastructure itself, including both the hardware and the data management systems. Second, we will touch on managing that platform – including backup, archiving, and retention policies.

Data Storage Platform

The data storage technology and vendor you choose will be a critical part of implementing your data strategy. Here are 7 important areas to evaluate.

1) Size and Growth

• How much data does your company currently store?
• How rapidly is new data generated?
• How fast and how large do you expect your data stores to grow?

Awareness of the current size and growth patterns of your company’s data ecosystem is crucial for accurate planning.

2) Data Storage Infrastructure

• What does your current IT infrastructure consist of?
• Have you recently made investments in updating hardware, or is company equipment nearing end-of-life?
• Do you have internal talent that is tasked with managing that infrastructure?

Any technology strategy must ask: What can and what should we manage internally? This question applies to data storage as much as to any other part of IT.

3) Data Types and Workflows

• Is your company primarily concerned with transactional data?
• Do you have large bodies of reporting data?
• What about unstructured data?
• Does company leadership have plans to expand the ways it uses or generates data in the future?

Different technologies support certain types of workflows better than others. So, knowing what your company wants to get out of its data both now and in the future will impact your data storage decisions.

4) Traffic

• How many data consumers do you expect to have and how will they access the data?
• How many concurrent users or connected devices do you anticipate?
• What types of data consumption are typical?

How and how much your data is consumed will also impact data storage requirements. Therefore, accurately projecting this usage can save countless headaches later on.

5) Data Storage: Cloud vs. On Prem

Evaluating whether to use a cloud-based or on premise data storage solution is critical to your data strategy. So, be sure to include all of these areas when performing your analysis:

• Security
• Budget/Cost
• Regulatory Compliance
• Location/Distribution

Do your homework. Prominent tech leaders have strong arguments on both sides of the cloud vs. on prem debate. So, what is right for your company may not be the same as what is right for your industry peer. Evaluate the options in the light of your company’s budget, needs, and current state to come to the best decision.

6) Data Storage Vendor

Choosing the vendor of your solution is your next big decision.  For a good article about questions to ask when evaluating vendors, see this article.

While we at The SERO Group specialize in SQL Server and Azure SQL, there are many vendors for data storage. Which vendor is right for your company? Budget, security, the requirements of the business, and the current state of your data environment will likely be your biggest considerations.

7) Licensing for Data Storage

Navigating licensing requirements can be a pain. However, carefully researching features that are unlocked with each licensing tier is important to getting the best service and support from your chosen data storage solution.

A careful cost-benefit analysis of licensing can be a game-changer for unlocking the highest potential of your data team as well. Sometimes advanced features are rightly deemed superfluous for your business case. However, at other times, higher licensing tiers afford security, recovery, performance, efficiency, or scalability options that are well worth the cost.

For SQL Server (whether on prem or on an Azure VM), this means considering Standard vs. Enterprise edition. Managed instances and Azure SQL databases have other important licensing considerations. See here for Microsoft’s description of the differences and here for a discussion of the differences between some of these options.

Management Considerations: Backups, Archiving, and Retention

8) Backups

• How are you currently backing up your data?
• Have you tested the recoverability of your backups?
• Would your backups still be available if a site-level disaster occurred?

Your backup strategy is critically important when thinking about data storage. Disasters and crisis events happen. In fact, we at The SERO Group have just about seen it all in terms of recovery efforts. Depending on your data storage platform, different backup considerations will apply to you.

There are usually three levels of backups that could be relevant to think about: local, image-level, and offsite. So, be thorough when creating your strategy. Remember – frequency and redundancy are keys to a strong backup strategy. Your future self will thank you if confronted with a crisis!

9) Data Archiving / Table-Level Snapshots

So, why archive or take table-level snapshots of data if you have a solid backup strategy in place?

While this may not always be necessary, taking a snapshot of point-in-time data can be helpful or necessary for important data that may fluctuate (financial data, for example). These snapshots can also act as a point of redundancy in your backup strategy for critical data.

However, archives can require a significant amount of storage. So, how and where to store large amounts of snapshot data should be evaluated if an archiving strategy is used.

10) Data Retention

• How much data do you need to keep and for how long?
• How long should your backups and archived data be in short-term storage?
• What about long-term storage?

You will need to consider any regulatory requirements that apply to your data when answering these questions, as well as the operational needs of the business.

Want to work with The SERO Group?

Data storage can be a challenge, especially for growing companies. How to store the data? When to archive it? Where to store it? Who is responsible for it? All can be be challenging questions.

Our clients depend on their data. They need to know that their data is protected, that it is reliable, and that they can leverage it to make more informed and better decisions.

If that’s something you’d like to learn more about, let’s have a conversation.

The post 10 Data Storage Considerations for Growing Companies appeared first on The SERO Group.

The problem compounds when IT departments are pressed to justify the expenses of managing data. This is especially challenging for small and mid-sized businesses with limited IT budgets. Managing data is often someone’s secondary responsibility. Perhaps someone in software development or infrastructure management is tasked to manage data – in their spare time.

Investment in data management is easily overlooked.

Is your company data an asset to be cultivated or a utility to be optimized?

A company’s response to this question is often a good indicator of the maturity of its data environment. It also reveals the foundation of the company data strategy.

Sometimes the company data strategy details a roadmap for leveraging its data as an asset… Fantastic!

Other times the strategy is implicit and defaults to ensuring that systems are secure and operating in terms that are acceptable to the business. Still good, but perhaps incomplete.

In some cases, though, the data structures are ignored completely until there is a major problem. No data strategy exists, and the omission threatens the business.

So, what do we mean when we ask if company data is an asset or a utility?

A utility is often defined as a good or service that is considered essential. An asset, however, could be considered anything that can be used to produce positive economic value.

Think of utilities for a business as those resources that a business wants to invest in just enough to operate the business. Assets, on the other hand, are valued inherently for their ability to be translated into monetary value. This white paper discusses in depth the importance and challenges of valuing your company data as an asset.

How does this concept apply to your data strategy?

Using data as a utility is a relatively reactive posture. Cultivating your company data as an asset is essentially proactive. In fact, to be forward-thinking with your company data, you must define your data strategy.

An analogy

Think of your company as a farm and the forces of nature as the data it needs to operate. The farm requires every natural element – sun, wind, rain – but it also can be threatened by them. Let’s think of wind specifically.

Now, wind is a powerful force with the potential to wreak all kinds of havoc. It is also a necessary and unavoidable force of nature. So, the first thing a farm needs to consider about the wind is protection against damage. This is fundamental. The owners might plant trees as a windbreak or position buildings and fields in the safest locations. They would avoid placing hazards that could cause damage to crops, livestock, or buildings during a storm. Thinking ahead, they would also make plans for how to mitigate damage in the event of a disaster.

We can think of this as security and disaster recovery for your data.

These measures are a significant first step. They are proactive in so far as they plan for storms and minimize threats. However, they do not consider how to leverage the wind as a resource to benefit the farm.

In time, the farmers start to consider harnessing the power of the wind to improve the farm and make work easier. They use the wind to aerate their greenhouse or to direct a controlled burn. They build a simple windmill for irrigation. At this level, the farmers see the wind as an asset and not merely as a necessary force of nature to contend with.

Consider this as entry-level business intelligence with ad hoc data retrieval.

In business, this is the realm of the complex Excel workbook, Access database, or Jupyter notebook. These tools are developed by the business to retrieve data through an ODBC connection and transform it into meaningful information to drive the business. While this approach is still fairly manual, businesses are empowered by using their data in this way without committing to large investments in infrastructure.

However, this approach is not scalable.

Back on the farm, the owners recognize that wind-power can only be harnessed in small, relatively manual ways without more financial commitment. To really leverage the wind, they must invest in infrastructure on the farm.  Our farmers begin to envision their whole farm and estate with the potential to be powered by the wind. They thoughtfully invest money into harnessing the wind to propel more than isolated actions. Instead, they look to fuel the farm with energy.

Here, businesses are aware of their company data as an asset and invest in systems and architecture for the purposes of reporting, business intelligence, and AI.

Finally, the farm grows to the level of a largely self-sufficient enterprise. It no longer fears the potentially damaging power of the wind, because it has continually increased its vigilance in managing threats. A solid disaster response plan exists for when the unexpected or unavoidable occurs. The farm has matured beyond manual inefficiency, and the wind is now fueling nearly every aspect of the ever-growing estate. The farmers even realize that the power they are harnessing from the wind can itself be monetized by selling power back to the grid or to nearby farms.

The investment pays off.

Companies see that they can turn their data into dollars in terms of driving profit and business efficiency. They may even see that they can monetize their data by selling it for use in machine learning or for partnering with other businesses. Their company data is leveraged as an asset.

Where to begin?

The downfall of strategic plans often comes in the implementation. Strategy sounds great. Company data as an asset? Wonderful. But if the rubber never actually hits the road, businesses can find themselves stuck.

So, how do you make sure your data strategy yields results?

Inform your decisions with your desired outcomes at every step. Start at the beginning with a strong foundation of security, disaster recovery, and database performance. Your data team must apply the principles of data management within the context of your company’s data strategy.

To go back to the farm analogy, where is your farm headed? Do you need to be careful about where you plant trees as windbreaks or locate the barn and shelters in order to leave room for future development of a wind farm?

By identifying your data strategy early (knowing that it will grow and change organically), your data team will be able to more thoughtfully advise you at the crossroads of your journey to enable your business to fully leverage company data as an asset.

What is your data strategy? Do you have a strategic roadmap?

In upcoming posts, we will dive further into some of the specific components of a thoughtful data strategy.

Want to work with The SERO Group?

Our clients need reliable and secure SQL Servers. They need to know that their data is protected, that it is reliable, and that they can leverage it to make more informed and better decisions.

If that’s something you’d like to learn more about, let’s have a conversation.

The post How to Justify IT Spend: Is Company Data an Asset or a Utility? appeared first on The SERO Group.