Data Management Strategies

Are your assets fungible?

Blogger: Lyn Robison

Some assets are fungible, and some are not. Fungible means that the asset can be freely exchanged or replaced with another of like nature or kind. Oil is fungible. One barrel of oil is considered identical to, and can therefore be replaced by, another. Other assets, such as grain, lumber, and ¼” sheet metal screws are fungible assets. There is no need to keep track of instances of these assets, just their quantity.

American dollar bills are fungible. One paper dollar is just as good as another. Dollar bills do have serial numbers, so you can go to Where’s George and see where a particular dollar bill has been. And the Treasury Department probably uses the serial numbers somehow. But in the business world (even though it seems like a dollar isn’t worth a half-a-buck) one dollar bill is just as good as another.

Used cars, OTOH, are not fungible. One 1987 Ford Taurus is not just as good as another. Automobiles have vehicle identification numbers, because it is important to identify each individual vehicle, because they all have different options, different histories, etc. Therefore, used cars are non-fungible assets.

When we, as IT professionals, build a database to hold important business assets – such as, say, a customer database, it is tempting to think of that data as fungible. It is tempting to think of filling up that database with data the way that we might think of filling up a barrel with oil. Sure, inside the boundaries of that system, we realize that we need to give each customer record a primary key, but it is tempting to use some auto-increment field to automatically generate that pk for each customer record, and then fill ‘er up!

The problem is that customers are not fungible: one customer is not just as good as another. It is vital, therefore, to identify each customer, and to do so beyond the boundaries of any individual IT system. This is in essence the data silo problem: the inability to identify non-fungible assets across data silos.

I know of a large non-profit organization (a church, actually) that owns thousands of buildings all around the world. I say “thousands” because they don’t know how many buildings they actually own. Multiple IT systems contain information about buildings: construction systems, maintenance systems, financial systems. Each of these systems uses its own pk to identify each building, and there is no way to reconcile these individual, non-fungible assets across the data silos. How do they manage these buildings if they don’t even know how many they own? The answer is, not as well as they ought to.

This is the problem that Burton Group’s MODS (the Methodology for Overcoming Data Silos) is designed to address. It gives you a methodology for identifying non-fungible assets across data silos.

Think this isn’t a big deal? Think about a large enterprise that could finally identify all of the vendors/suppliers from which the enterprise buys good and services. They could begin consolidating purchases with each supplier to get better prices and payment terms and save hundreds of thousands, if not millions of dollars. And this is just a small example of the value of tracking non-fungible assets across silos. Every dollar spent on CRM systems is a dollar spent (and often squandered) trying to solve the data silo problem.

Now think of the ability to reconcile non-fungible assets across data silos with regard to structured and non-structured data. If you could identify non-fungible assets beyond individual system boundaries, you could combine data about that asset from every system in the enterprise, including structured as well as non-structured data. This is another concept behind MODS.

We have published some guidance on MODS here. We will talk more about it at Catalyst. And you can look forward to additional guidance on MODS in the near future.

The Smoking Gun

Blogger: Lyn Robison

My colleagues and I in Burton Group's Data Management Strategies service have long suspected that data management ineptitude has been a significant contributor to this economic recession that we are all enduring. Well, I have found the smoking gun.

An article published in February 1, 2008 issue of the business journal Mortgage Banking, illuminates how the data silo problem contributed to the subprime mortgage crises, whose ripple effects resulted in the current economic recession.

The article, written by the research director of a leading research and advisory firm that focuses on the global financial services industry, states: “The problems of inconsistent data names, definitions, structure, cleanliness, usability, transfer and governance are well known in the mortgage industry. We subsist on a steady diet of missing, incomplete and inaccurate data elements for loan origination, loan servicing, portfolio management and securitization processes.

“Dirty data persist despite the proliferation of automated computer systems for core lending processes and subprocesses. Similar to a ‘water-bucket brigade,’ where water is lost as water buckets pass from hand to hand, duplicative legacy systems, the lack of one database of record and less-than-seamless integration between lending subsystems result in lost, inaccurate and manually re-entered data. This results in slow, expensive loan processing; weak underwriting decisions; inaccurate loan pricing; excessive quality-control costs; incorrect portfolio management; loan buybacks; and other costs to lenders and mortgage investors.

“Poor data governance is a contributing cause to the current mortgage liquidity crisis in the U.S. nonconforming loan market. During the summer of 2007, subprime mortgage funding liquidity disappeared in part because subprime lenders and mortgage investors lacked the data to accurately reassess and reprice credit, collateral and prepayment risks. Many lenders that could not internally fund or sell their loans went bankrupt.

“Clearly, the unexpectedly high level of defaults is a primary cause, but subprime mortgage defaults are always very high. Bad, missing and inaccessible data exacerbated a difficult situation. Many nonconforming mortgage investors lack accurate data to support updated models and forecast assumptions to reprice existing credit and prepayment risks. Until this is rectified, subprime investors will remain on the sidelines or, in the case of jumbo mortgages, will continue to overprice new jumbo loans until they have better data with which to estimate risk and profit.”

See “Data quality: the cost of dirty data in the secondary market.” AllBusiness.com. 1 Feb 2008. Accessed online 24 April 2009. http://www.allbusiness.com/banking-finance/banking-lending-credit-services/8886090-1.html.

The Hippocratic Oath for Computer Systems

Blogger: Lyn Robison

As I have read and pondered our friend and esteemed colleague Joe Bugajski's life-threatening experience, I have come to four related points of conclusion, which I would like to express here. These opinions are mine alone -- other people, including Joe, might look at the facts and reach different conclusions. On a topic as momentous as this, we in the IT need industry need to get this right, so I am eager to hear your opinions on this topic.

1. Silos are always going to exist because of organizational boundaries – Joe's Allergist, the Urgent Care clinic, the ER, and the ICU all are silos, and to a certain extent, every nurse and doctor was their own silo too. This accounts for Joe having to give his medical history 11 different times, upon entry into each silo.

2. The lack of access to data residing in the other silos is a fundamental problem -- and not merely type, but instance data. A developer can define an object type and then can create multiple instances of that object, and computer systems must indentify each instance if they are to run properly. A type is defined in the object schema, and an instance of that type is identified by its address in memory. In a relational database table, the columns define the type, and the rows define the instances (and require a primary key to identify the instance). Knowledge of instances is absolutely essential for bridging data silos, because instance data is vital and fundamental to data handling. Doctors say they wish they could have again the paper medical chart hanging at the foot of the patient’s bed. The location of the data – its proximity to the patient – is how doctors used to keep track of the identification of that instance – the data moves with the patient. Given silo-ed IT systems, we need to implement the inverse of that: we need to enable the data to remain in its various silos, let the patient move around independent of the data’s location, and retrieve the patient’s data (based on the patient’s instance) from anywhere, on demand. (An alternative would be to put all of the data about a patient from every silo onto a small storage device that the patient carries with them at all times. This might be useful for identifying the instance, but this approach has several problems with conveying and rendering the information, which I can elaborate if needed.)

3. Too much structure in a medical data model can be deadly. As Joe has explained, medical terms are highly contextualized and nuanced. It is really, really hard to create a highly-structured model of medical data that is accurate. The oath behind every data model should be, “Above all, do no harm to the meaning of the data.” When data has to go from one doctor, into a computer system, and then on to another doctor, the computer system must above all, do no harm to the meaning of that data. The old-fashioned paper charts were semi-structured, and accomplished their job relatively well. A highly-structured and inadequate data model inside of an IT silo does not do this, as Joe’s experience illustrates. The meaning of medical terms is well-understood by the doctors but the meaning probably does not need to be understood by the computer systems involved. Medical computer systems would do well to just pass the information in an ungarbled manner between medical professionals. (BTW, the world wide web conveys information all of the time without its computer sytems completely understanding the meaning of the data, and the web does not garble the information in the process.)

4. Channels of information delivery are vital. Medical professionals need easy access to all of the information in every silo based on the patient’s instance, and they need to retrieve that information through multiple channels: tablet PC’s, laptops, PDAs, cell phones, in short, all of the electronic devices that are capable of conveying information. Our friends in Burton Group's NTS content area call this “unified communications”.

Imagine for a moment a medical information system that provides information based on a patient’s URI (uniform resource identifier). A medical professional could view this patient’s information, retrieved from whatever silos the medical professional chooses, on demand. The system could display both structured data such as food alergies, and semi-structured data such as medical charts, on which previous doctors have written important notes. The computer system does not need to understand those notes, but the doctors do. The computer system would need to use a flexible data model so as to never do any harm to the data that must flow between medical professionals. The previous doctor’s URI could be shown on chart to enable any subsequent care providers to easily contact that doctor if the notes they wrote are unclear. Such a system would enable the free flow of medical information, instead of hampering it.

Dear Mr. President, a Data Model for my Electronic Health Records Nearly Killed Me

Blogger: Joe Bugajski

Mr. President, your historic economic stimulus package (The American Recovery and Reinvestment Act of 2009), appropriated $19 billion for health information technology ("Technology Gets a Piece of Stimulus", New York Times, January 25, 2009). This week, your Director of the Office of Management and Budget (OMB), Peter Orszag, shockingly held that half of the US operating deficit can disappear with lower healthcare costs and these will obtain through electronic healthcare records (Daily Show, 6 April 2009). Today, the Wall Street Journal wrote that you proudly proclaimed that electronic healthcare records for the members of the US military, like my youngest son, and continuing through Veterans Affairs "will provide a 'seamless system' to facilitate information sharing and cut red tape, ending the need for veterans to transfer military records to receive benefits". Whereas Star Wars and Star Gate movie fantasies provide great fun, witnessing you, a world leader, spew delusional visions of a nation-covering, interoperable, secure, private, reliable, accurate, and instantaneous electronic healthcare data network is at best terrifying and at worst pernicious.

Two months ago and for 100 hours I battled for my life with a networked, state-of-the-art, secure, electronic healthcare record system. It connected two of arguably the most advanced medical facilities in the world. One was a modern clinic built by generous benefactors from the computer industry. The other was a world renown hospital at a top ten university. Both facilities bristled with brain-power and hi-tech gadgets. All records were "computerized" - that was what was so very wrong with the care that I did not receive, albeit competent and attentive nursing staff managed my care as they shuffled me around the emergency room (ER) and intensive care unit (ICU). (For more about what went wrong and how it went wrong, read my personal blog.)

The reason things went so wrong during my clinic, then hospital, stay, and the reason, Mr. President, your grand vision of a universal IT health data network is so screwy, is that healthcare data cannot be reliably modeled. An unreliable data model for health records; like those at the two world-class, completely electronic facilities, that "cared for me"; accelerate prescription errors, prevent staff from efficiently delivering services, heighten life-threatening risks, and dramatically increase costs. Data models are the technical instructions for software to make "computerized health records" possible. Indeed, data models make all computer records possible. According to my friend, colleague, and data modeling guru, Joe Maguire, "data modeling is a family of techniques used to describe the kinds of information that are important to an enterprise". Healthcare data is clearly important but that fact alone does make for reliable data models. Good models require stable data and good data modelers. Unfortunately, healthcare data is unstable. Sadly, good data modelers are scarce.

The first problem with modeling healthcare data is that models must represent certain concepts (and not others) that will remain stable and true long enough to be built into computer software then used by healthcare providers and patients. Mr. Obama, have you noticed just how much knowledge has, is, and will be accumulating in the medical sciences? Knowledge is codified using words - medical knowledge uses copious quantities of difficult words taken from several languages. Words that recur frequently in a particular context become imbued with a meaning that includes the context (e.g., the White House). Such words then come to symbolize a bigger idea than originally intended (i.e., a "house" that happens to be "white", versus your administration and not the house). In medicine, how many stable words exist? These words - nay, well-formed concepts, repeatable, agreed by the medical community - can be modeled and added to computers to store records. Go one step further. Specialization in ER, ICU, cardiac care, pulmonology, oncology, radiology, and other medical subjects exists because the cumulative knowledge defines a large ontology. The ontology, taxonomy, skills, and knowledge of an medical subject area then can be referenced with one word - the name of the specialty. Unfortunately, words that refer to a concept in one specialty often mean something different in another specialty.

The second problem is the lack of good modelers. These people, specialists in data engineering, a subfield of software engineering, transform concepts into graphical and lexical patterns that are used to create computer records. The concepts they model are words (nouns and verbs) plus concepts used by practitioners to describe a patient's medical condition, or a critical care pathway, medications, instructions to patients and nursing staff, tests, and diagnoses. Who among us has the modeling skills to encode this data? As information varies across specialties, how should it be encoded? Empirical evidence suggests that engineers who built the electronic health records network at the two facilities that "cared for me" tried to do this, but they failed. Their data model had irreconcilable silos of information spread across specialties and expressed as incomplete taxonomies (entities), inadequate ontologies (attributes), and poor associativity (relationships). Hence, when programmers added those bad data models to the health information systems, those systems later lost critical information about patients' condition, listed wrong medications,isolated prior diagnoses from current observations, in short, made very bad medicine.

Please do not misunderstand, Mr. President, the medical personnel at the clinic and the hospital were professional, competent, and knowledgeable. It is just that when they interacted with me and other patients, then translated that interaction into electronic health information systems, there was always a fight. Indeed, healthcare professionals wasted between 40% and 60% of the time they had allotted to patient care with making electronic health records work very poorly.

Since the time of my illness, I met and spoke with a dozen medical professionals and healthcare IT experts. They unanimously confirmed my sickbed analysis of the faults with electronic health records. Most longed for handwritten charts hanging at the foot of every patient's bed (see, Professor Dr. Armstrong-Coben’s New York Times Op-Ed ) - now, so do I.

Mr. President, before your administration pours billions of our grandchildren's yet to be hard earned dollars into the biggest, scariest, and most wasteful boondoggle of an IT project the world has ever seen, please instruct your health IT experts to carefully analyze the strengths, weaknesses, opportunities, and threats (SWOT) associated with building a national heath information network using today's technology. Tell them to take the simplest steps first. Make them prove results in small projects. Insist that your experts read my paper, "Data Integration: Fantasies and Facts". It explains how to start and manage a large scale data integration project.

If our nation simply accepts your vision while healthcare IT vendors collect a lion's share of the $20 billion stimulus bounty, individuals and businesses will pay higher medical costs, patients will receive inferior care, medical professionals will loose more of their precious time fighting IT systems instead of delivering better care, and you will be a one term president.

With profound admiration and respect,

Joe Bugajski

Where do I start?

Blogger: Lyn Robison

This is the question that was put to me recently by a Burton Group client (actually, a conference room full of clients). Their enterprise had grown through mergers, and now they had several installations of SAP, lots of redundant COTS software, hundreds of large databases, and more data than they knew what to do with.  Where should they start to get a handle on all of their unmanaged data?

I suggested three things:

1. Seize the high ground of IT metrics. Make metrics for information quality and for data management maturity an integral part of the metrics that their IT department uses to measure itself. These metrics will serve as a rudder to steer the entire organization in the direction of managing heretofore unmanaged data.

2. Understand their business and its data. Model the business enough to understand it. The whole is greater than the sum of its parts, and data people must understand the relationships between the parts of the business. Then model the important data, so the data that the business requires and the data that the business has and the delta between what it has and what it needs becomes well-known.

3. Establish data governance processes. For topics or subjects that are important to their enterprise, define systems of record, and establish businesspeople as data stewards on important enterprise topics. Make sure that IT leadership can answer this question: How do you know that the right businesspeople know that they own the data?

These are good places to start getting a handle on unmanaged enterprise data.

Why would you ever want to do that?

Blogger: Lyn Robison

Today’s enterprise IT systems perform lots of computations for people. The central purpose of many IT systems is to automate rote calculations to save people the work of having to crunch numbers by hand. Yessiree, process automation is what enterprise IT systems are all about.

Today’s enterprise IT systems can actually do more than merely perform thousands of rote calculations. IT systems are more than glorified calculators. IT systems can provide useful information to businesspeople who need it. (It is easy to assume that that is what BI and decision support systems do, but that is not really what I am talking about. This idea is a bit bigger than that.)

Today’s enterprise IT systems can be made to combine information, consisting of both structured data and semi-structured documents, from multiple, disparate application silos, on any topic that is important to businesspeople. These systems could deliver information that is timely, complete, and relevant to businesspeople at every level of the organization on any topic that is important to them. Businesspeople could have access to business information, independent of which IT system contains that information.

As I talk to IT people about this concept, I am often asked, “Why would you ever want to do that?”

The ready availability of business information from disparate silos would enable businesspeople to gain insights that they would never be able to gain otherwise. Those insights would enable them to make better decisions, accomplish their work more effectively, serve customers better, readily see new opportunities, and in short, make the enterprise succeed in ways it never has before.

Obviously, one of the reasons that the Web is so popular is because people can retrieve information they need without knowing the intricacies of the computer systems that the information resides on. (I can get information from cnn.com without knowing any details about CNN’s computer systems) And guess what? That is useful!

This question of “Why would you ever want to do that?” reminds me of when Rapid Application Development (RAD) first came out. One of the steps in RAD was to get feedback from users. I remember at that time IT people asking “Why would you ever want to do that?”

It was a silly question back then, and it is a silly question today.

Taking the Metrics High Ground

Blogger: Lyn Robison

I remember working as an Enterprise Architect for a large, bureaucratic IT organization in which almost everyone believed that IT’s primary job was to build and run IT systems. The CIO certainly believed that. So did all of the IT directors under him.

The problem I faced was how to get everyone in IT to realize that the IT department’s job is to deliver useful information to the businesspeople who need it. I wanted to get everyone to realize that the systems we implement are only one means to that end and are not an end themselves. I could say that a thousand times, and everyone would agree, or at least feign agreement, and then go back to their work of building and running systems -- systems that provide only a fraction of the useful information that they should. Then I realized that I needed to seize the high ground of IT motivation: metrics.

If you can change the metrics by which an IT department measures its own progress, you can change the IT department and the perceptions of everyone in it. That is why, now as a Burton Group analyst, I wrote an overview entitled “IT Metrics: Measuring IT’s Business Value”. It gives any information-centric IT professional the ammunition they need to change the metrics by which their IT department measures itself. By changing those metrics, you can change the perceptions of what is important in your IT department.

It turned out that the CIO in this large, bureaucratic IT organization knew that metrics were the high ground too, and he blocked my efforts to put information-quality-metrics in place. If I had possessed the ammunition in this overview when I battled that CIO, I could have taken the metrics high ground. Now I am eager to hear how useful this ammunition on information-centric metrics is for you.

A Bellwether, a Harbinger, and a Sea Change

Blogger: Lyn Robison

About three years ago, my colleague Anne Thomas Manes and I spoke at a seminar in Manhattan. Anne spoke on SOA governance and I spoke on IT portfolio management. The seminar was attended by people from several financial services firms in the NYC area.

After the seminar, Anne and I went to lunch with some folks who attended the seminar. One of the guys from Lehman Brothers told me that, while my talk was interesting, there was no way that they could ever implement any IT portfolio management. When I asked why, he explained that their IT department is organized around each software application. There is a team of IT people permanently assigned to each IT application at Lehman Brothers, so if they ever retired any software applications, it would cause major organizational upheaval. As a result, they never retire any applications. (Obviously, their IT department was not organized into the three buckets of plan, build, and run.)

I said, “I’ll bet that your operations and maintenance budget is continually taking a bigger percentage of your overall IT budget, and that you can’t undertake any new IT initiatives without increasing the overall IT budget first.” He agreed. I also said, “I’ll bet it is difficult to keep track of all the data that your software applications produce and consume.” He agreed with that too. I then said, “Do you know how to fix those problems? Implement IT portfolio management.” This seemed to be a revelation to him, and after a pause, he said, “I need to talk to the CIO about this.”

As Anne and I caught a cab to the airport, I told her that if she has any money in Lehman Brothers, she had better get it out now, because they are headed for a disaster. Clearly, IT portfolio management is a bellwether for the IT management competence. Inability or unwillingness to manage software applications and the data they produce is a harbinger for disaster. And ignoring data management problems leads to a sea change – and not a positive one – for the entire enterprise and for its customers.

Cold, Hard Realities

Blogger: Lyn Robison

When I read articles like this one (Job Losses Hint at Vast Remaking of Economy), I don’t see today’s enterprise IT departments in the driver’s seat of some positive business transformation. IT leadership will be lucky to convince business leaders that the current IT staff is still relevant in this lean and mean world of business reductions. Businesses are trying to get rid of dead weight, and the question is whether or not the current IT department will even remain a passenger in the vehicle.

Enterprise IT today is a slow-moving, ponderous, and very expensive organization, which implements IT systems through expensive, risky, and lengthy IT development projects. And those IT systems, when finally implemented, generally fail to provide the businesspeople with the information they really need. As a result, business leaders are highly likely to look at reducing and/or replacing their expensive IT staff and the ineffective information systems that the IT staff implements.

Business leaders are quite likely to consider SaaS and COTS packages in an effort to reduce their dependence on custom-built IT systems that their IT department is not all that good at building anyway. If the only thing that the IT department does is provide custom-built information technology, and if information technology is a commodity that can be purchased off the shelf or accessed over the Internet, then why not save some money by getting rid of that expensive IT staff and their custom-built technology? In fact, business leaders might consider outsourcing their entire IT department. Cloud is sounding better and better (even though it is not a reality yet).

The tragedy is that when a business uses COTS or SaaS packages, or when they outsource their IT department, they still do not reduce their IT costs very much and they still get information systems that fail to deliver useful information to businesspeople. Competent data management is the only path to information systems that deliver useful information. Outsourcing IT might look like it would save money, but IT outsourcing does nothing to improve competent data management. In fact, IT outsourcing makes data management worse.

The only way for enterprise IT departments to remain relevant and be successful in the current business reduction environment, it seems to me, is with guidance like this:

• IT departments must convince business leaders that they can implement useful information systems far more inexpensively than they have done in the past, so…
• IT departments and the information systems they implement need radical simplification -– IT departments need to get religious about becoming svelte and nimble
• IT departments must stop doing custom IT development –- building custom IT applications is too expensive, risky, and time-consuming for today's environment (developer productivity is an oxymoron)
• IT departments must get serious about managing their portfolio of application software -- the holy grail of IT is not reuse of code through OO or the resue of application logic through SOA, it is retirement of obsolete systems through application rationalization and application portfolio management
• IT departments must embrace COTS and SaaS packages, but must put in place the requisite data management to make those COTS and SaaS packages effective
• IT departments must start to bridge application silos through effective data integration -- silos are an unfortunate reality and they prevent businesspeople from getting the information they need to do their jobs
• IT departments must work jointly with their colleagues in the business to manage corporate information as the asset that it is

Information technology is a common commodity, but information is a unique a corporate asset. Those IT people who fail to come to grips with those two fundamental realities are fast becoming irrelevant in this lean and mean business environment.

Silo-Busting vs. Silo-Bridging

Blogger: Lyn Robison

Eliminating silos has proven to be an intractable problem. Application silos exist in every enterprise. Business functions are typically optimized using an IT system of some sort, and each IT system tends to become its own silo. Our two primary approaches to busting silos – SOA, and Enterprise Software Applications –are proving to be ineffective at busting silos.

SOA is an effort to eliminate process silos, but this effort has stalled, largely because of the difficulties inherent in process integration. Process integration requires distributed transactions across service calls, which are difficult to implement. Another problem with SOA is that one of its promised benefits – the ability to dynamically combine business processes – is not really very useful. In actual business practice, how often do enterprises really need to dynamically combine their business processes? Aren’t business processes usually pretty static and well-defined in big businesses today? Business processes which change a lot or which need to be dynamically combined with other processes are the exception. Most business processes need simple data integration more than they need over-engineered, SOA-based, dynamic process integration.

Enterprise-wide software applications are an effort to bust silos by subsuming small silos into big ones, but in actual practice, this approach complicates instead of solves the problem of silos. For example, enterprise-wide CRM systems are an effort to take one important enterprise data type – customers – and put customer data inside of a well-oiled silo. Okay, how about other important enterprise data types, such as vendors? Vendor information tends to be scattered across modern enterprises too. Are we going to build another big silo for vendor data? How about financial data? And how about employees, fixed assets, inventory, products, accounting, sales, billing, logistics, contracts, or supply chain data? Are we going to build big silos for each of these types of data too? Enterprise data types and the processes that work on them are too varied to be crammed into a small number of big silos – they won’t fit into a few big silos because there are too just many data types in modern enterprises.

Okay instead of busting silos, which SOA and Enterprise Software cannot do for us, what if we bridge silos instead? This new approach, which is well-proven, is to reconcile the data between the silos – make data consistent so that data flows smoothly between silos. The beauty of this approach is that it is based on nothing more than competent data management.

Burton Group will soon publish an overview that describes a case study in which two IT developers successfully bridged nine distinct silos within their enterprise. The overview is entitled, "The XQuery Development Stack: a Toolset for Content-Centric Applications", and will be published in early March. In mid-April, I will do a telebriefing on the topic of bridging silos as well.