/ Article Data Dives – Episode 5: Open Source

By Erik Oehler, Global Digital Content Marketing Manager

An interview with Daryl Heinz, and open-source consultant and evangelist

 

An interview with Daryl Heinz from DFHeinz and DugTalks around the benefits of open source components, the opportunities many companies are missing out on, and reprogramming programmers.

Welcome to Data Dives, from Alaris, a Kodak Alaris Business

Veterans in AI, Daryl's non-profit dedicated to training Veterans on programming best practices can be found here.

Subscribe to Data Dives on any of the following platforms:

Spotify | Subscribe
iTunes | Subscribe
Stitcher | Subscribe
Google Play | Subscribe

Transcript

Daryl Heinz: It still revolves around data. And, what's hitting them hard is when we start getting to the privacy issues, security issues, compliance issues, whether it's medical compliance, or it's European data compliance, or it's California compliance.

Erik Oehler: Welcome to Data Dives. My name is Erik Oehler. Today, we're bringing you an interview with Daryl Heinz. Daryl is the CEO of DFHeinz, a boutique consultancy focused on harnessing the power of data using open source tools. He's also the founder of DUGTalks, a series of webinars, videos, and seminars designed to educate businesses on the benefits of open source. My colleague Iva and I spoke with Daryl and his teammate, Jenna Buehler, about some of the misconceptions around open source, the opportunities most companies miss, and some very actionable steps that companies can take to start harnessing their data. I enjoyed the conversation, and I hope you do as well. Now, Daryl Heinz.

Erik Oehler: I guess if you want to start out, you could maybe introduce yourself and kind of describe a little bit about what it is you do.

Daryl Heinz: Sure. My name is Daryl Heinz, and for about eight years, I've been running a boutique consultancy that cleverly enough is called DFHeinz LLC. The whole purpose of the consultancy is that throughout my career, we have been dealing with data, as have most companies. But, the problem is that most companies, they deal with data, especially when they want to automate their usage or exploitation of it, they write applications toward one particular form of data. For example, it comes from a relational database, or if it comes from two particular forms of data, the application is written right toward those forms of data, where they come from. So, the application becomes highly non-reusable when I say, "Well, gee, let's bring in another type of data."

Daryl Heinz: By non-reusable, what I mean is the application has got to be torn apart. When a new piece of data comes or when the old piece of data goes away, the application is constantly opened and torn apart and closed up again. While this doesn't sound like a big deal, it really is one of the major influences of the cost of ownership of software. If you are an enterprise organization that uses software to generate your revenue and not just a software company, pretty soon, software starts to be seen as a burden, and it starts to be seen as a necessary evil that doesn't necessarily add to the revenue stream until of course we get the software in production.

Daryl Heinz: Back in about 2010, companies like Cloudera and then Hortonworks, then Pivotal and IBM started convincing the community that big data was the problem, and that those companies had the solution. So, they sold you a stack of services based upon specific software. When, in reality, they should have been much more truthful with you and said the real problem is that we write applications that are not adaptive to different types of data and different sources of data. And, different types of data and different sources of data will always occur and always disappear.

Daryl Heinz: So, why are we writing software so that when a new source of data comes in, it's simple to handle? When an old data disappears, or it becomes merged, it's simple to handle. So, in reality, big data isn't the problem, and it never has been the problem. Of course, when big data started being a well-known word, then IoT started being used, which is still just data. So, we finally sat back and realized that the problem is, one, companies are being misled. They should be taught how to write adaptive software. Two, if they do write adaptive software, they will very soon see the following benefits.

Daryl Heinz: One, a quicker time to market, because adaptive software needs a very specific development methodology that will guarantee a quicker time to market. In many instances, a quicker time to market is actually a competitive edge. But, along with a quicker time to market will come, one, because the software was written to be adaptive, it's written much like a piece of hardware is built, in pieces. And, when a piece of that hardware goes bad, you take the bad piece away and replace it with a new piece. What this really is, is it is component oriented development of highly adaptive software. So, it seems like I'm mixing metaphors, and I truly am.

Daryl Heinz: The first one is, data is data is data. The second one is, we've never learned how to write applications that are adaptive to new forms of data rapidly. So, what we do, is we first propose to the company, if they have the resources, by resources, I mean the qualified individuals. We propose to them a methodology which is called incubation methodology. The cornerstone of incubation is component oriented programming. So, in order to be successful with incubation and component oriented programming, they must know the components, because the components become the building blocks of the implementation of the application that company wishes to write. But, now here's the benefit.

Daryl Heinz: When that application that was pieced together with components is becoming obsolete or needing to bring in different types of data, the application is very easily extended by adding on components to understand this new type of data. When the application needs to be scaled from, I don't know, five or six servers if it's distributed to 50,000, 60,000 microservices, there is nothing in these components that has to be changed. So, therefore, they're completely agnostic to how they're deployed. Therefore, a company going from an on-prem to a in-cloud micro strategy is as simple as a couple of button pushes and not rewriting software.

Daryl Heinz: So, the value proposition to companies who hear this is, so we've been pretty much spending an awful lot of money on things we shouldn't have, because we've been writing software incorrectly, because they haven't been highly adaptive, because a highly adaptive piece of software means it's put together in components. So, what we do is we try to get people to understand this methodology. They soon become confused with, oh, but we're agile. Or, oh, we're waterfall. Or, we're object oriented. All of that is very nice, but it has nothing to do with the fact that they're still not using components. They're writing components from scratch. They don't know how to harvest reusable components even from the very applications they have already written.

Daryl Heinz: So, we show them how to do this incubation methodology, which very simple is, first, learn what components are. Two, learn where the components can come from. Three, learn how to look at a use case. Then, envision it as nothing more than Lego blocks of components strung together. Four, when the application needs to change, understand what component needs to be pulled out, or components need to be pulled out, and what components need to be put in its place? This methodology is something that's very foreign to a lot of companies. So, that's the first thing we do. We try to tell them that since the year 2000, component oriented methodology has been very successful. They just have to find the components.

Daryl Heinz: Here's the value add to those components. The ones we recommend to our clients are all open source and license-free. So, for example, we had a client that was heavily engaged in SAP. SAP, as you know, is this massive enterprise suite that comes at a very, very large licensing cost. We can easily take those use cases that they are getting value from SAP and get rid of SAP, because now there are open source components that do exactly what SAP does. And, again, those open source components are free, license-free, and open source.

Daryl Heinz: The only thing that's needed to replace SAP is to take a migration methodology of use case by use case by use case, prove that one of those use cases has been successfully replaced by component oriented programming, and then use that first use case as the learning tool and as the substrata of all the other use cases. So, for example, to replace SAP, while the first use to implement may take three to six months, two or three people, the next use case will probably take two people two month. The third use case will probably take one person one month, because they are rebuilding on top of the reusable components they've implemented the first use case with. Am I talking too much?

Erik Oehler: No, that's a good point. That use case with SAP is perfect. The couple things that stood out at me, I would challenge the quicker time to market proposition, because like you just explained, I think that very first use, when you're not just ... When you're essentially retraining an organization and reprogramming programmers on how to build out components versus traditional object oriented programming we're all funneled into.

Daryl Heinz: You're dead on, and I don't see that as a challenge. That's one of the first things that when we know that we are going to change or introduce a change of culture to the IT, that yes, the first use case is a learning curve of what components to use. But, that's where we come in in a second phase of saying, if you're not familiar with the broad variety of these components, and they come from all over, Apache, Netflix, Google, Amazon, HashiCorp, LinkedIn. There's a whole bunch of these open source components that are very powerful, very easy to use. So, our second part of coming in a company is not just to train them the methodology, but to serve as mentors.

Daryl Heinz: So, if they have a learning curve that is going to prevent them from meeting that three or six month deadline, what we will do is we will come in with the knowledge. We will show them why we chose certain components, or perhaps we'll give them three or four options of various implementations of a use case. We will ask them if they want us to implement. But, during that three to six months, they will still go into production. But, now the people who knew nothing about these components will be introduced to one, what components that we've used, what they do, how to maintain them, and how to go and fish for themselves the next time they want components. So, think of the components as the fish we give them the first time around. But, we also teach them how to fish.

Erik Oehler: And, there's another overhead piece there that you kind of just hinted at, and that's in the support end of things. Do you find that that's a barrier for companies too, to build out that support structure that they maybe were used to just relying on SAP for?

Daryl Heinz: Actually, I love how you think. I didn't hint that before, but you obviously know software. So, yeah, let's talk about that. We hope by the time that we introduce these components that the individuals in the company will have the time to learn. Therefore, when we leave, that learning will allow them to start to support what they've learned. Because, again, this is all open source. But, again, the other part of the company is that until they come to that expertise of support, we can help them support. But, wait, there's something even better. All of these component libraries come with, if you're a software person, a well established GitHub or Jira of bug reports, bug fixes. You just have to know how to say, "Oh, well, wait a minute. It looks like we've got a bug. Let's search on their GitHub for that bug or their Jira."

Daryl Heinz: And, since that bug is probably very well known from one release to another of the component, all they have to do is download the fix and implement the fix. Now, when they do that, we also want to show them in software that you don't implement a fix by tearing open the code. You implement a fix by using something called aspect oriented programming where when the wrong code is hit the execution thread, the execution thread is redirected to the good code. Then, the execution thread returns to the good old code. So, there are methodologies that many people will say, "Yes, I know object oriented. I know agile." But, what surprised me is that people coming out of school in IT have no idea that every runtime from C++ to Java to Scala to Python have an AOP framework.

Daryl Heinz: So, again, it's not just that we're combating the culture. Yes, support is important, and again my company, because we're fairly large, and we pretty much will always use components that we're very comfortable with, we'll again, gradually come in as support. But, more importantly, because we're a boutique consultancy, we will also fade ourselves out. The whole idea is self-enablement of the companies. But, and I've got a feeling your mind is starting to work and say, "But, what of the company doesn't have the resources or the mission to self-support?"

Erik Oehler: You're one step ahead of me.

Daryl Heinz: Yeah, sure. Well, in that case, we offer support. One of the beautiful things about being a very agile, boutique consultancy, we offer support at a considerably lower price, a better response time, and deeper competency than those companies that have these predefined stacks where people will call up, and they'll get the first tier support person, going to the second tier support person, the third tier support person. Then, when they have another call, they're unknown to the person they're calling.

Daryl Heinz: Because we're a boutique consultancy, we will guarantee you the name of the individual, their capability, et cetera. By the way, everything I'm saying about my company, these are the things that we offer the company once they're interested in applying what we do. So, for example, one of the current client where we're not replacing SAP, but we're removing an awful lot of license cost of SAP, because they've allowed us to start demonstrating that certain use cases can be done with these components.

Daryl Heinz: Now, it has to be a corporate-wise buy-in that, yeah, now that we've shown you that we've removed 1800 SAP licenses where you had 3600, maybe they might want to consider that millions of dollars we save per year, they might want to consider a full migration. But, again, that's up to the company. Remember, we will always make sure that for example, with SAP, that we are benign to SAP when we are running our use cases. And, with a flip of the switch, they can go back to their old SAP ways and turn off our stuff. So, we want to make sure that risk is mitigated, and no matter what level of individual that is, from a programmer all the way up to the CTO, to the CEO, we want to make sure that, yes, they have perfect control over the risk they want to take on and how to mitigate that risk.

Jenna Buehler: If I could just jump in really quickly, Erik, could I jump into your question on reprogramming programmers and the time to market that's associated with that?

Erik Oehler: Absolutely.

Jenna Buehler: More recently, in the last year, we have onboarded several folks who do not have a formal college education. These people are technical. They are developers. They come from a developing environment. They have an acumen toward math and toward programming, and that's it. These people are currently working at places like Mayo Clinic. They just got done doing the first ever AI implementation for one of the biggest hospitals in the United States. Reprogramming programmers, you're right. It's not for every programmer. Some people like to be told what to do. Some people are not interested in necessarily being in an educational stage, always learning on different projects. But, if your acumen is toward always learning and always problem-solving and understanding the components, then it's not hard to be a data scientist in three to six months.

Daryl Heinz: Erik, Jenna brings up a very valid point. I feel so strongly that I can take someone with just high school education, but again a good aptitude for programming and mathematics, and teach them essentials. As a matter of fact, we've already got the program active. In 102 hours, which is about a year, we take people who have shown aptitude and turned them into entry-level, in this case, Python developers with a data science expertise. The program has been so successful that we now are pitching it as something called Veterans in AI where we have a nonprofit set up. The goal is to not charge veterans, which there's lots of veteran programs out there, but we don't charge the veteran anything. We give them a computer. We set up their curricula.

Daryl Heinz: And, we have stated that if you successfully finish this program with our certification, we will place you. The thing is, because they're not college graduates, here's another cost proposition for the CFO. College graduates require or feel enabled to a certain salary rate. How about people who have never been given a chance, usually marginalized, now up to the skill level to walk into the professional world, and give them a salary rate which they think is extremely fair, extremely welcoming. But, yet, it's lower than the salary rate that people who want to repay their college education wouldn't touch. So, there's another cost proposition. Again, that cost proposition is insidiously masked in some companies as outsourcing.

Daryl Heinz: I'm sorry, I don't believe in that. I believe in you take care of your own. There are so many people wanting a door opened. So, these components from scratch, we show them, here's a component that does edge computing with IoT devices. You don't know what edge computing is? We'll talk about that. You don't know what an IoT device is? We'll talk about that. Then, therefore, by learning the component, they also learn the technologies. They learn the space that companies need. Yeah, Jenna brought up a good point, that the other cost savings is not only do we have people who are eager to be in this organization, this IT world, but we have people that understand the value of what they are doing rather than a form of enablement.

Daryl Heinz: Now, I'm making gross generalizations, and I apologize for that. If you want to take a look, our launch page of Veterans in Artificial Intelligence is very, very simple, but it works. So, we want to take that same program, non-college educated, but can become viable IT people, even into the high schools. So, that's where we're going. By the way, you're going to see, and I think you know there is a movement afoot in industry, not to necessarily hire college people, because they come at a cost. But, to hire capable people, intelligent people who want to succeed. So, we're kind of on that bandwagon to give off certifications and open doors, not give the fish, but give the opportunity to fish.

Erik Oehler: Yeah, and it's good because you're basically placing a bet on yourself and your methodology. UIPath is doing the same thing with RPA, where they're just making the training and the certs free, and just saying, "We want as many of them out there as possible using our platform and our method." You win in that scenario.

Daryl Heinz: Oh, I definitely do, because I'm just asking them to learn a method. I'm asking them to learn a technology. But, we're not asking them to use our platform. By the way, and Jenna hates it when I say this, and I know this is politically incorrect, but I'm nobody's employee. I'm 62 years old, and I've had the benefit of being director of training, leaders of large enterprises, worldwide enterprises, and now is the time to say, "What's really wrong with this industry?" So, in my own little small way, what's wrong is doors aren't opened, and invalid criteria is being used to build a good, sound team. So, that's my other side effect of doing this component oriented methodology.

Erik Oehler: Yeah. I want to go back a little bit to the buy-in piece of this with firms. I see programmers as kind of the low hanging fruit. I think a lot of them probably just want to find the best solution. I hear companies I've worked for, I hear dissent where it's, I don't know why we can't just use this open source software versus what we're using. As you go higher up the chain, I think there's some stigma attached to open source at the C level that maybe you've encountered that you have to overcome. Maybe it's, you get what you pay for, that kind of stigma, or a worry that open source is ... I know this is false, but maybe somehow less secure, even though it's maybe the most secure, debatably. What kinds of resistance have you encountered as you move up the food chain?

Daryl Heinz: Would you like to know the resistance, and how I get rid of the resistance?

Erik Oehler: Absolutely.

Daryl Heinz: It's easy. Prove it. The nice thing is, because we are component oriented, we know the components. If they say, well, for example, "It's going to take a long time," we'll show that that's not true. If they say, for example, "It's insecure," it's open source. You compile it. You control it. If it's, "But, it doesn't follow our security patterns," actually it does, because there's nothing in these components that are reliant upon a specific security pattern.

Daryl Heinz: So, if you want to, for example, put on HashiCorp's Vault or Anthem's entire process or something as crude and primitive as Kerberos and all that nonsense that we're doing with SSL, or it's not SSL, TLS. All of that stuff, the components are components you can link in any security system and make it as secure as you want. You want to send the data through blockchain? The components don't know the data is coming through blockchain.

Daryl Heinz: So, again, the way that I encounter fear is to understand what the fear is, and it's usually based upon experience. Then, to understand that experience and then say, "How many weeks can you give me, or how many days can you give me?" And, I'll generate the metrics, or I'll give you the resources, or I'll show you the references, or I'll have people speak with you. For example, by the way, I started out is a cryptanalytic mathematician for the NSA. The NSA is a big open source user. So, I'm thinking, gee, if the NSA uses open source, that's kind of a hard argument to defeat about the insecurity or the inability to secure open source.

Erik Oehler: Yeah, I know. In most cases, you're just arguing against misconceptions. Have you come across a legitimate argument against it from an organization, that you've just kind of thrown up your hands and said, "You got me"?

Daryl Heinz: No, actually, when I throw up my hands, it's because I realize that they're not going to change. You kind of alluded to that type of person. Well, this is what we've been doing. It works for us. It's what we always do. We don't know anything else. So, as soon as they say that, I know that they're not open minded. But, here's the way I try to defuse that. I'll ask, "So, you have a new endeavor coming. Let me ask you, are your developers going to do what they know? Or, are they going to know what they do?" Most of the time, a developer who only knows what they do is going to ... Excuse me, that does what they know, and says they will take the same practices even with a brand new technology and not understand that technology to realize that practice may be inadequate or indeed damaging.

Daryl Heinz: `But, if they know what they're doing, the first thing any intelligent person does is learn what they're working with. Two, how to apply it to their use case. And, three, understand that if you violate how the tool was written, you're going to add risk. So, the only time I've ever thrown up my hands is when I know I'm meeting irrational, non-open minded people. Let's face it, there's a lot of them out there that are saying, "No, we're afraid." I can't. They have to meet me halfway unless they want to pay me to defuse their fear, and I don't mind doing that, because sometimes when they pay me to defuse their fear, the biggest thing that's my problem is sometimes I want to say, "I told you so." But, they're paying me, and they don't want to hear that at the end, so I try not to say, "I told you so."

Jenna Buehler: Yeah, and Erik, to that point, just to add a bit more color to that, in a majority of our business is based on unfortunately 911 calls. That is, someone has bought a cluster or a stack that is no longer going to be supported, supported by whoever they bought it from. So, it's more expensive to go to the ER than to do proactive maintenance and to be productive about your health. In the same light here, we're going in to resurrect legacy systems that otherwise be supported in X vendor's domain.

Daryl Heinz: Jenna has a beautiful point, too. Imagine yourself in triage, large company which then they're bleeding money trying to get what they want to get done. There's a lot of panic there. But, once we know what they're trying to get done, we'll say, "Look, in a week, if we show you a prototype that alludes to the fact that we can do this, would you buy into it?" Even during that panic, if they start saying, "Now, use our data," that's easy. The components don't care where the data comes from. Now, put in our machine learning. That's easy. The machine learning is nothing more than a component to augment the component. Jenna is right. We've made a great deal of money in showing people that this is what they should have been doing all along. It's just when it's accepted that it's what they should have been doing all along. But, so far, we've had a great deal of success.

Jenna Buehler: We can't name the company, but just this week, one of the top three wireless service providers called. Urgent, urgent, we need you immediately. Sign our paperwork now. Yeah, latency issues. Yeah.

Daryl Heinz: Yeah, and by the way, you had mentioned something. So, you know our methodology now. The other way that we have a proven track record for the methodology is, well, one of the things we've done is we've created a very, very rigorous data plane to start migrating away from SAP. But, the same components of that data plane, since we use a great deal of streaming capability throughout the data plane for speed and performance, is take away a couple of components and add a couple components in. Now, that data plane that was used for SAP is now a data plane for a distributed data catalog and distributed query.

Daryl Heinz: Take away a few more components from that same basis set of components, and now that data plane is a data plane that does edge computing with video information that's coming from infinite number of drone sensors. So, again, to know these components, to know how to build a basis data plane, and to know that even the services that this data plane has because of the components in themselves become macro components. So, the whole idea of components oriented methodology isn't just a component that does a single function, but a group of, for example, microservices that do a function that can be pulled out and replaced with other microservices that do a function.

Daryl Heinz: So, the component oriented methodology abstracts very, very well to any form of deployment, whether it's cloud, edge computing, fog computing, or on-prem, or VMs. It's just the way to do it, and we just, when we get with a client, I will ask, "Do you have a week for us to prove it to you?" Usually, we have to get to the right people. Then, it is either bottom up infiltration of mindset or top down infiltration. To be honest with you, we find a great deal of bottom up mindset infiltration to be much more effective than top down, because the bottom up understands the technological basis that we work with, rather than the top down only understands the dollars and cents of it. So, that's the other thing we've found.

Erik Oehler: Yeah. When you get those 911 type calls, how much of the work is stopgap, and how much of it is, lack of a better word, a come to Jesus moment for them where they really take a holistic look at their data strategy and go full in on your recommendation? Then, of those that don't, are you seeing a repeat 911 call later?

Daryl Heinz: No, it's interesting you ask that, because I will now expose to you my black little heart and my cultish behavior on how I seduce them. They see the blood stop, so it's the stopgap, but they also see that we did it with our methodology, with our components. So, right then and there, they get the best of both worlds. They get the functionality they need, but we get the introduction of components. Now, because it's stopgap, the components are probably only doing 20 or 30% of their true functionality. But, it's enough to get them going fast, stopping the bleeding, and say, "Oh, by the way, you have another problem? That's kind of related to this problem."

Daryl Heinz: So, now our stopping the bleeding of that second problem is going to probably take less time because we're going to reuse the components that the first, that were solved with the first problem. Now, do I make them have a come to Jesus? No, because again, the only way you can change a culture is if the culture wants to change. The best way for a culture to change is to see the value of what has been added. So, when you stop the bleeding, they see value. When they see how you did it, then they'll see we have a pattern to our madness.

Erik Oehler: Yeah, that makes total sense. What do you see kind of coming down the road that a lot of companies aren't prepared for? Apart from your methodology, what are some of the trends that are just going to hit people like a bat?

Daryl Heinz: You know what? It still resolves around data. What's hitting them hard is when we start getting to the privacy issues, security issues, compliance issues, whether it's medical compliance, or it's European data compliance, or it's California compliance, they are still going to see that as, oh my God! But, that's perfect, because all that is, is an implementation with a component or components that are implementing the appropriate machine learning or decision tree that takes that business logic and plugs it in. So, we just have to say, "Look, this isn't hard. You have a source of data. That data starts feeding through your system. So, what would you like to do? Would you like to be conservative in what you take in or liberal in what you take in? But, if you're conservative in what you take in, then we put the compliance machine learning at the front."

Daryl Heinz: But, I really don't suggest that. I suggest that what you do is you become liberal in what you take in and conservative what you work with. So, therefore, the compliance is usually at the point where you need it as, versus overall, because if the compliance is overall, guess what? When the compliance changes, everything has to change. If you put the compliance exactly where it's needed, it's only that one component or those three components that change. So, the biggest thing that we are seeing is people are still not understanding that data is always going to change. The sources of data are always going to change. The formats of data are always going to change. And, how we view the value or the security of data will always change. So, why not have applications where that change is adaptive, and the adaption comes from components that can be the compliance of the day.

Daryl Heinz: So, when the compliance of the day turns into 16 compliances of the day, guess what? It's just more components to put in front of the thing that has to accept the data after it's been cleansed or filtered. It's still a matter of, data will always change. I'm sorry. I wish I could give you an answer of what's going to happen. What is going to happen is the following, people are still going to be resistant to understand that applications have to be adaptive to data.

Erik Oehler: Yeah, and part of it is because the value proposition of the out of the box fix is so attractive to people. That compliance piece is near and dear to Iva and I's heart, because we're kind of fighting that now, where we've tried to implement an approach to compliance that mimics GPR globally, because we're a global organization. And, it is just a struggle.

Daryl Heinz: Yeah, and again, I know you guys have worked hard on that, and you know that compliance of any sort is just implementation of machine learning, even if it's as simple as decisions trees. But, now the question is, and again my only recommendation is you should be liberal of what you accept and only at the places that need that compliance and fusion is where you place on that compliance behavior. Because, any time you keep the flow of data from going freely, and now starting to put behavior and analysis on it, you start losing your performance.

Daryl Heinz: That's the other thing that most of our clients want, is they want exceptional performance. By the way, if you would do me a favor, everyone you hear using the expression realtime, would you put a plastic bag over their head and seal it with duct tape on the neck? I am so tired of that, because realtime is subjective. Unless you and I agree to what the latency period is between the time the data is received and the data is processed, we'll never have a good sense of what realtime is. In reality, what we're saying is, here is my criteria for our service level agreement of timeliness.

Daryl Heinz: That's one of the first things we always ask our client, not only the use case, but for the end consumer, or to get the revenue from this data. What is your service level agreement? Now, the beautiful thing about that is because we have lots of different components, if there's a component that becomes a bottleneck, they can be declaratively configured for performance. Or, if the component just isn't right, we pull that component out and pull in another one. That's where the agile development comes in. It's all part of the methodology, and I don't know if Jenna has provided you the slides of the methodology, but we've got an introductory level set of slides that you're more than welcome to.

Erik Oehler: Yeah, that's awesome. Yeah, I poked around on your website, too. There's some great info on there. Iva, do you have any questions? I've kind of talked through as well. Anything come to your mind?

Iva Kanova: I was just thinking actually, so as far as I understand in your methodology, you're using basically open source software components to build something that works in a certain scenario. Given that you're using components from this open source community, how is your company contributing back to the community?

Daryl Heinz: I'm glad you asked that. The way we're contributing back is that the reason why we like open source is because it's not made by a single company with a single agenda. It's made worldwide, so therefore you have the best of breed worldwide. But, like any piece of software, there will be bugs, there will be omissions. Right now, I can name you two components that we've contributed back to. One is called Pig, which unfortunately, people are talking down, and it's because the vendors don't want to support it. Yet, it's a brilliant component set. The other one is called Pulsar, which the vendors don't know about, because it would supersede their pushing of Kafka. Since we've brought in Pulsar, we've found that a couple of the interfaces were not implemented fully. So, we contributed back.

Daryl Heinz: We firmly believe that what we learn should go back into the community. But, there's something else about the components. One of the other things we will do once a company buys into, wow, you did that fast, but what about all of our embedded subject matter expertise in our applications? One of the other things we do is we show them for our methodology how to harvest their subject matter expertise and put it into reusable components. So, it's not necessarily that the components in a data plane implementation for a client will all be open source. It may be a lot of the client's subject matter expertise where they've been shown how to build their own component library.

Daryl Heinz: And, it's interesting, because a lot of these component libraries that we've helped harvest from other companies pretty soon do appear as components in open source, because it's a business need that is needed all around. For example, SAP, it's a business need that's needed all around whether you're doing HR or Gantt charts or whatever. So, eventually, private industry or private code, because enough people have rewritten it over and over and over again, eventually does emerge as a component, as open source, because people are saying, "Look, we can do this better and get exactly what we want, rather than buying a company's one-off or very rigid framework."

Jenna Buehler: There's another really valuable why that we're contributing back in the sense that open source, they don't have a marketing team. So, right now if I want to train on Hive, I'm going to have to pay $5,000 and go to a conference that's another couple grand in order to learn Hive. Now, learning Hive is like, if I was an artist, selling me on the color green. Okay, I'm an artist. I now have access to the color green, but what else could I potentially create? So, what we've created is a series of talks that talk about all the individual components that are available that are really popular right now, and how you can combine them to get unique results for specific business needs. So, those are called DUGTalks. I don't know if you want to give a one-liner about DUGTalks.

Daryl Heinz: No, sure. DUGTalks were because again we walk into organizations where people are either not familiar with the availability of these components or what these components do. We have a global infrastructure called DUGTalks. Get it? Data user group talks, but it now sounds like TED Talks. Okay, we stole that. But, DUG is a cute little doggie. So, anyway, we have DUGTalks, and what we do is for free. We'll say, "Hey, you guys, have you ever heard about this component called Ignite? Or, we know that Cloudera and Hortonworks really, really push Hive, but did you realize that there's six or seven ways to have a SQL interface on distributed data?"

Daryl Heinz: People will say, "No, those aren't in the stacks." I'm saying, "Exactly, maybe you don't want to buy a complete stack. Maybe you might want to learn what components satisfy your use case and look at the best component." So, yeah, the DUGTalks have been very successful about, one, opening people's eyes to component oriented methodology, but also starting them to be able to build their repertoire of what components are of interest to them.

Erik Oehler: That's interesting, because you mentioned you don't have a marketing department. Really, open source communities people don't other than individual evangelists. So, do you find that, is there an active ... I've never been on this side of the equation, but is there an active fear, uncertainty, and doubt component to proprietary software's marketing?

Daryl Heinz: Okay, I'm getting to love you, because that was an expression I used to use in JBoss when we were trying to compete against JEE. FUD, fear, uncertain, and doubt. Human beings, when they don't know about something with certainty, they'll always have fear, uncertainty, and doubt. The way you remove all three of them is by knowledge. The beautiful thing about these components is, as I mentioned, prove it. It's very easy with either mentorship or learning on your own to prove it to yourself. Well, wait a minute. That fear that they were generating that Hive is the only thing isn't true. The uncertainty is, let's go out and find other companies that are using open source components. Now, there's a rub, because most of the companies who are using open source components aren't going to tell you, because that's their competitive edge.

Daryl Heinz: As far as the doubt, what thing removes doubt better than proving it for yourself? And, the beautiful thing about these components is that, go to one of these components. Go to O-F-B-I-Z, OFBiz, Office Business. OFBiz is the component suite that we're using to replace SAP. The beautiful thing about OFBiz is that because it's an Apache project, its website is organized such that, here's the documentation. Here are tutorials. Here are the blogs. Here's where you download. So, even from my own developers, the way they learn the components is I point them to the website and say, "Download the tutorials. Start learning. Then, download the documentation. Start playing."

Daryl Heinz: The answer to the question of fear, uncertainty, and doubt is the minute you start feeling that someone is starting to inject that into you, I would walk away and know that I'm intelligent enough to say, "I'll go and find out for myself." That's the beauty of these components. You can find out for yourself in a very short period of time. Or, you have people like us that don't have an agenda to sell you anything. Come to us, and that's why we did the DUGTalks. We want to make sure the DUGTalks have no agenda. As a matter of fact, DFHeinz is not mentioned in the DUGTalks so that people start learning about these components. So, yeah, open source doesn't have marketing, but open source does have crowdsourcing, and we're part of that crowdsourcing.

Jenna Buehler: There's a huge communications gap, which is why it's so great that people like you are doing what you're doing, Erik.

Daryl Heinz: Yeah, Erik, I can't thank you enough for this opportunity.

Erik Oehler: Oh, thank you. Do you have anymore, Iva?

Iva Kanova: I actually want to ask, do you think there is any limitation to what kind of software can be built using this kind of methodology?

Daryl Heinz: No, there is none, and that's the whole thing. This methodology is the result since 1940, 1950, 1960, 1970 where there was always that missing piece. That missing piece is again applications have behavior and data. The applications were always written towards specific data, specific behavior. Well, data and behaviors should be component-ized, and we snap them together. It comes from the hardware world, right? You get a board, and you snap together the components. You now have a functioning computer. But, when the CPU goes bad, you replace the CPU and stick it in with perhaps a better one than what you had before. But, we have not encountered any software, because ultimately, when you get down to a business case, like for example, let's say in our model.

Daryl Heinz: That's still a component of encapsulated subject matter expertise. Why not serve it as a component so it can be plugged in and plugged out rather than hardcoded to an application that can't be reused. So, it's the component oriented development that has really opened our eyes. By the way, I have to give credit where credit is due. In JEE, those were components, but they were very parasitic components. Then, I worked with Spring, and the idea was, what was wrong with those components? They're parasitic, so let's make them non-parasitic. So, again, the evolution of components is there, and it will always continue. So, that tells me that there really isn't any limit to how component oriented methodology can be used toward any application of software.

Erik Oehler: That's great, and we'll close with one more, if that's okay. What advice would you give to maybe a startup? Or, we've been talking mainly about enterprise, but someone building their tech stack from scratch here, what's a point or two, that they can be mindful of?

Daryl Heinz: Oh, very simple, and this is how we work. Know the problem, your use case. Know it from a business point of view, but have people there who can see it from a business point of view who can decompose it into a technical point of view. Once that use case is decomposed in a technical point of view, start going out and looking for components that can be clicked together to implement that technical point of view. Once you get it running, and if you're not running well, then start switching out components and seeing how the component switch changes. So, this is truly agile development, but ultimately, know your use case. Don't try to have one thing do everything. Know a use case. Implement it. Know another use case. Build upon the previous implementation. That's really how a large enterprise software IT system should be built. That's how it's built in hardware. That's how it should be built in software.

Erik Oehler: Great. That's a great note to end it on. Daryl, thank you so much. We'll send people to your website, DFHeinz, and is there another way you prefer to be contacted or social media you'd like to plug?

Daryl Heinz: Oh, absolutely. DUGTalks.com, and I would really greatly appreciate, because I believe in the cause very strongly, to have them take a look at VeteransinAI.org. It's the nonprofit. We just started a fund-me page. The whole purpose is, as soon as we get investments, we start searching for veterans. We start giving them computers, and we start turning them into IT professionals rather than people on subsistence and people who have been marginalized. So, DUGTalks.com, please pass them there. VeteransinAI.org, please pass them there. And, of course, our webinars are on DFHeinz. So, Erik, again, I can't thank you enough for this opportunity.

Erik Oehler: Yeah, thank you, Daryl, and thank you, Jenna.

Erik Oehler: My thanks again to Daryl Heinz and Jenna Buehler. You can find Daryl at DFHeinz.com as well as DUGTalks.com. If you are at all lost on your data strategy or considering open source tools, please check it out. Each and every episode of Data Dives is brought to you by Alaris, a Kodak Alaris business delivering scanners, software, and services that help businesses go paperless. If you enjoyed this episode, please consider leaving us a review on iTunes or wherever you get your podcasts. Please share it, like it, get it out there on whatever social media platforms you use. It's the way that we keep it going. For more episodes of the show, please subscribe wherever you get your podcasts, or check us out at AlarisWorld.com. For Alaris, a Kodak Alaris business, and the Data Dives podcast, my name is Erik Oehler. Thank you for listening.

Contact

Alaris Information Management products, services and support are available worldwide and sold through resellers. 

To find a reseller in your area, call us at 1-800-944-6171 or complete our information request form below and a reseller will get in touch with you soon.

Thank you for submitting your information. We will be in touch soon.
Submit error