In 2016, we can see the future spread out before us like a sumptuous buffet. The possibilities are endless. We are moving toward that perfect Gene Roddenberry spot in time where we are freed from the drudgery of bolting things together, filling out spreadsheets or even punching a time clock. People will be freed to think and innovate and really come up with exciting and innovative solutions instead of bolting bumpers on Chevys or producing TPS reports.
How is this possible, you ask? Automation. The above-mentioned Chevy isn't bolted together by people anymore, it's produced by robots. Why should Bill Lumbergh be coming by Peter's office saying "We have a problem with the cover sheet on the TPS report" when he should be clicking a button to produce it, the way that Impala is built?
The next logical question is "Why isn't everything being automated?" The answer is complicated. First, the people that can replace entire systems aren't in leadership roles. In society today, either you do stuff, or you manage people who do stuff, but not both. These managers don't have the knowledge sufficient to look at the big picture and produce that one piece of software that does everything. Those days are coming to an end.
Let's take a little example. Our sister company Sentia Health, took a look at the process of health insurance and what precisely could not be done by a machine. You can't replace a doctor with a computer. You can't dig the memory of what the doctor did to any given patient out of his head (there is a visual) and record it for him or her. What you can do is to take that documentation, pull out the procedures and pay for them. That is basically all the insurance company does. The difference is that the traditional insurance company has a cast of thousands with medical coders, adjudicators, and big building and HR departments and generally wastes about 1/3 of your heard earned healthcare dollars. Sentia Health takes those same records with no human intervention and pays for medical treatments in near real time for a small monthly fee of $10 per month. This is about 1/10th of what the average insurance consumer pays his or her insurance company for the same service. That isn't the first, nor even the second industry we have completely automated.
Whether you like it or not, your company or the company you work for is a software company. Either you will get on board with the new way of doing business, or you will be run over by someone who has. David Kirkpatrick of Forbes agrees saying "those who fail to adapt with be obsolete." Joel Basgall says in Entrepreneur Magazine "You Need to Become a Software Company... or Die." That is pretty harsh, and absolutely true.
We've given you quotes from the best minds in the business and an example of something We've actually done. Heck, we have even automated the production of the software we are discussing here so you don't have to pay a fortune to have your business automated. If you've been following along, you've heard that message before. You have the ammunition you need to put your competitors out of business. It's your job to pull the trigger and make the changes. One of those competitors is taking aim at you right now.
Wednesday, October 19, 2016
Wednesday, October 12, 2016
Architecture Frameworks, Handy as a Pocket on a Shirt or As Welcome as a Fly in a Biscuit?
A few years ago, I was talking with a colleague at Duke Energy in Charlotte, NC about what he does on a daily basis as a software architect. He gives me the usual answer about meetings and donuts and drawing boxes. Then, he starts talking about Enterprise Architecture (EA) and how great it is and how I should learn it until basically I asked him for his driver's license to make sure his name wasn't Oral. (Yes, I know he's dead. Too soon? Oral, not the Architect)
I did a little research into what was going on with the various frameworks (EA, DODAF, FEAF, MODAF, TOGAF, Zachman). What I found was, at a high level, they are only good for documentation. EA and TOGAF actually give you some large boxes on where to put your code, but Zachman, DODAF, FEAF and MODAF just show you how to organize your thoughts and plan for the movement and integration of data.
So you framework people are telling me that I need help conceptualizing the solution, not actually designing and building it? No wonder nobody seems to be able to get things done. As a kid, I thought we'd be in the Star Trek Universe by now, where people were freed from the drudgery of work and making a living because the computers were doing all the heavy lifting, freeing us to think and innovate, to solve really interesting problems instead of producing widgets or TPS reports with or without the correct cover sheet. Instead, we have spreadsheets and email and business as usual, the same as it was in 1843, except that Bob Cratchit doesn't have ink stains on his fingers and he can email his spreadsheets to old Ebeneezer instead of hoofing them over. Sometimes they do still hoof them over. We call that SneakerNet. NikeNet if it's a really good network.
So today, I came across Paul Preiss' article "Why Frameworks Are Killing Architecture" and I thought, 'finally,someone who gets it. Paul does get it, kind of. Here are his five reasons he states NOT to use an Architectural Framework:
Build a database that contains all the entities, their attributes and relationships. Design and build a piece of software that looks at this database and builds a middle tier to support Create, Read, Update, Delete and Search (CRUDS (CRUD + Search)) and looking at related data in this database. If we have a database table of students and a database table of classes we need to generate the code to get a list of classes for each student and a list of students given a ClassID automatically. We don't want our developers to write that mundane stuff. Read all about developers a little below. Design and build a tool to generate a User Interface (UI) based on the generated middle tier.
So here is the thing about developers. They are worse than cats and getting them to all run the same direction at the same time and at the same speed is quite a bit more challenging. They are always (collectively) the smartest guy in the room. ...even when they aren't. It is a reputation they earned and are used to so they do what they like usually, and if you don't like it, what they built is better than what you asked for anyway. ...except when it isn't. I gave a group of junior developers a completed database middle tier and part of a user interface (as an example of what I wanted) to complete. After several weeks I demanded to see what they were doing (they didn't want to show unfinished work) and was shocked to find they had not followed instructions but had written an entirely new middle tier and added several tables. needless to say, these developers are no longer drawing paychecks. Just as bad is the fact that nobody, ever wrote an application according to best practices 100% through and through. Worse is when the technology changes or you have to add or update features, you get a new set of developers that don't know and don't care what the former developers did, and will tell you that it's wrong in any case, that the whole thing needs to be scrapped and started from scratch. The only way to adhere to best practices at all times is to generate the code. You have to do it for the developers and let them unleash their creativity on the User Interface. If you have a brain in your head, you simply give them a picture of the UI and tell them to write the HTML, JavaScript and jQuery to get it done.
I did a little research into what was going on with the various frameworks (EA, DODAF, FEAF, MODAF, TOGAF, Zachman). What I found was, at a high level, they are only good for documentation. EA and TOGAF actually give you some large boxes on where to put your code, but Zachman, DODAF, FEAF and MODAF just show you how to organize your thoughts and plan for the movement and integration of data.
So you framework people are telling me that I need help conceptualizing the solution, not actually designing and building it? No wonder nobody seems to be able to get things done. As a kid, I thought we'd be in the Star Trek Universe by now, where people were freed from the drudgery of work and making a living because the computers were doing all the heavy lifting, freeing us to think and innovate, to solve really interesting problems instead of producing widgets or TPS reports with or without the correct cover sheet. Instead, we have spreadsheets and email and business as usual, the same as it was in 1843, except that Bob Cratchit doesn't have ink stains on his fingers and he can email his spreadsheets to old Ebeneezer instead of hoofing them over. Sometimes they do still hoof them over. We call that SneakerNet. NikeNet if it's a really good network.
So today, I came across Paul Preiss' article "Why Frameworks Are Killing Architecture" and I thought, 'finally,someone who gets it. Paul does get it, kind of. Here are his five reasons he states NOT to use an Architectural Framework:
- Frameworks get in the way of innovation
- Frameworks put the focus on deliverable instead of outcome
- Frameworks create poorly skilled architects
- Frameworks make hiring architects more difficult
- Frameworks allow architects to keep 'killing patients'
I've linked to the article so you can research that last one yourself. He then goes on to explain why you should simply change your approach to AFs:
- Move to only working with individuals who a have achieved an experience based certification in architecture
- Optionally pay for the personal development roadmap of your current people, not your future staff
- Measure your architects based on business outcomes
- Start measuring outcomes related to design decisions and share results
Well, you had me at the first five. "Measure architects based on outcomes" is a great thing to do, but the people cutting the checks can't see or understand the design decisions and the reasons that they are made, so that kills the only one that really made any sense, number 4, pay for performance. Which brings me to the conclusion: Either you can write the code, or you can't. If you can't write the code, AFs are a really good way for you to get away with drawing boxes, attending meetings, eating donuts all day and getting nothing accomplished while drawing a paycheck.
If you've been following along, you know that only once have we pointed out a problem without offering a solution. Here is what we replace these Architectural Frameworks with:
- Identify the entities in the Enterprise, like employees, structures, capital assets, processes and everything else
- Identify the attributes of the entities, last name, date of purchase, hours run and everything else
- Identify the relationships between these entities, basically either one to one or one to many.
- Identify the desired outputs such as production reports, P&L, purchases, sales and even tax returns. We will no longer be producing TPS reports, with or without the correct cover sheet.
Build a database that contains all the entities, their attributes and relationships. Design and build a piece of software that looks at this database and builds a middle tier to support Create, Read, Update, Delete and Search (CRUDS (CRUD + Search)) and looking at related data in this database. If we have a database table of students and a database table of classes we need to generate the code to get a list of classes for each student and a list of students given a ClassID automatically. We don't want our developers to write that mundane stuff. Read all about developers a little below. Design and build a tool to generate a User Interface (UI) based on the generated middle tier.
So here is the thing about developers. They are worse than cats and getting them to all run the same direction at the same time and at the same speed is quite a bit more challenging. They are always (collectively) the smartest guy in the room. ...even when they aren't. It is a reputation they earned and are used to so they do what they like usually, and if you don't like it, what they built is better than what you asked for anyway. ...except when it isn't. I gave a group of junior developers a completed database middle tier and part of a user interface (as an example of what I wanted) to complete. After several weeks I demanded to see what they were doing (they didn't want to show unfinished work) and was shocked to find they had not followed instructions but had written an entirely new middle tier and added several tables. needless to say, these developers are no longer drawing paychecks. Just as bad is the fact that nobody, ever wrote an application according to best practices 100% through and through. Worse is when the technology changes or you have to add or update features, you get a new set of developers that don't know and don't care what the former developers did, and will tell you that it's wrong in any case, that the whole thing needs to be scrapped and started from scratch. The only way to adhere to best practices at all times is to generate the code. You have to do it for the developers and let them unleash their creativity on the User Interface. If you have a brain in your head, you simply give them a picture of the UI and tell them to write the HTML, JavaScript and jQuery to get it done.
There are tons of tools out there to generate the middle tier, and I dislike them all. (N)Hibernate and Entity Framework immediately come to mind but I don't like them because they create big, mysterious 'black boxes' that work black magic and might end up in possession of your soul at the end of the contract. You can't see what SQL is getting generated and what it is doing to your database. If you have performance problems, and you will, there is literally no way to solve them. Further, it is a security nightmare since the tables are opened up to the generated SQL they produce. This also opens the tables to hackers and what are called SQL Injection Attacks. We built a tool that uses Stored Procedures exclusively and locks down the tables to anyone who doesn't wear the System Administrator's underwear. Or shave his ugly mug in the morning. That's not mean, I'm the System Administrator. Mostly.
We have a tool to consume our generated middle tier on the desktop and Microsoft was generous enough to build a tool that creates MVC web forms based on the generated Model (middle tier) from above. Given a good database design, we can generate about 80% of a new application. The other 20% is making it pretty and adding visual gewgaws like datepickers and modal dialogs for additional input or information. That part of the development can be handled by a junior developer.
This does a couple of things for us. We have the ability now to generate ONE piece of software to run the enterprise. Think of the traveling salesman problem. As the number of stops increases, the time to come up with the best route increases. As the number of stops approaches infinity, the time to calculate a solution also approaches infinity. Until you generate the solution. That makes the ONE piece of software conceivable and even buildable. Further, since the framework is followed to the letter, this obviates the need for Zachman, DODAF, FEAF and MODAF becuase they are about figuring out where the data sits and integrating it. If we generate the code, we already have a framework that we might describe with the other two, EA and TOGAF, and since everything is done the same way, every time, we need minimal documentation which is really what they are meant to produce. Additionally, if we find later that we made a mistake, or we found a better way to do things, we change the structure of the database or we simply need a new version, we simply reconfigure the code generator and regenerate the middle tier.
Here at Sentia Systems We are moving away from an object oriented (OO) middle tier where adding a member to a collection adds it to the database, to a hybrid OO/Dependency Injection (DI) middle tier where if we want to use DI, we can but otherwise the default OO solution continues to work. When we pull that trigger, we'll regenerate the middle tier and nobody will ever know that they have a completely redesigned and rebuilt middle tier (about 65-70% of the application), it will just continue to work, just with the new DI capabilities.
So yes, Frameworks ARE killing Architecture. If you are a junior guy, you are probably going to use Access or loop through records in Java or make whatever other mistakes junior developers make, but you don't need a framework for that. If you are a senior guy, you don't need the frameworks getting in the way of doing the real heavy lifting of design and development and so some MBA feels better about hiring you to do something he doesn't understand. If you are about producing documentation, reams of paper, to tell you what was done and how it was done, nobody needs you. That stuff isn't even read most of the time, and doing things the exact same way, every time eliminates the need for that anyway.
The conclusion is that frameworks don't add value and they don't write software. They are a solution looking for a problem.
The conclusion is that frameworks don't add value and they don't write software. They are a solution looking for a problem.
Wednesday, October 5, 2016
Today, Mayo Posts "How to Fend Off Phishing Attacks." What About Data Security?
My buddy Bill Siwicki of http://healthcareitnews.com (well, I know him because I've been reading his posts forever. Maybe he will return the favor) posts a softball from the Mayo Clinic titled "Gone phishin': Mayo Clinic shares tips for fending off attacks" detailing how they keep hackers from quite literally hacking users of Health IT software or phishing.
Yes, it's about training and repetition and giving positive feedback when an employee identifies and reports a (fake) phishing attack. We can't help you with that. We are socially awkward geeks, so take Dr. Mark Parkulo's advice on the social side of security. Conspicuous by its absence is what Mayo thinks about security on the data itself. I think that phishing is about a tenth as prevalent as direct attacks because hacking software is what hackers do. Phishing requires the hacker to step outside the shadowy computer world that has definite rules into the social world of people where you have to convince them to do something you want them to do.
So why did Dr. Parkulo and Mayo decide to ignore 90% of cyber security? My guess is that they don't know much about it. Most practices don't. On Dec. 28, 2015, on the same site http://healthcareitnews.com, Bernie Monegain posted a list of the "10 most recent HIPAA breaches" that ALL happened in the first part of December. Even worse, at the bottom of the article there is a slideshow detailing all the big data breaches for 2015 and after that a list of all 1683 known HIPAA data breaches for 2015 according to U.S. Department of Health and Human Services
Office for Civil Rights (OCR).
Clearly Doctors focus on the human side, as they should. I keep crowing about security here, and have stated numerous times that nobody is getting into my database that doesn't shave my face in the morning (barbers don't generally shave me in the morning). I assumed this would taunt hackers into finding some kind of hole they could exploit, but as I suspected, they can't. Our sister company Sentia Health has securely published medical records to the internet in our Software as a Service (SaaS) Electronic Medical Records System (EMR) since 2009 and have never had a breach. Our database uses its very structure to limit the records an authorized user can see to only the ones belonging to patients who call their location primary. There are universal searches as practitioners may need to see records outside of their particular practice but that's only for practitioners with the oddball patient needing attention.
Each time a practitioner (or a patient) logs in he or she is issued a globally unique identifier (GUID) that is unique in the universe and identifies the confluence of that user and that user's session. When the user logs out or gets timed out, that GUID is deleted. The GUID must be supplied for every call to the database and the user is authenticated each time. Even if the User ID and Password were somehow stolen and used to hack into the database, the hacker could only see the names of stored procedures, not even the table names, and wouldn't be able to execute those procedures and/or get any data. I'm tempted to publish the User ID and Password here and let them try. They still won't get anywhere.
As for why Mayo and Dr. Parkulo didn't mention the other 90% of security, it's probably because they have had a couple of data breaches in recent memory as reported by the OCR. Go to the link above (or here), click "Show Advanced Options" and type "Mayo" into "CE / BA Name Search" text box. You'll see what I mean.
I'm positive that if I tried to "doctor" that there would be great gnashing of teeth in the land and I would probably end up in prison. So Doctors, leave the software to us programmers.
Yes, it's about training and repetition and giving positive feedback when an employee identifies and reports a (fake) phishing attack. We can't help you with that. We are socially awkward geeks, so take Dr. Mark Parkulo's advice on the social side of security. Conspicuous by its absence is what Mayo thinks about security on the data itself. I think that phishing is about a tenth as prevalent as direct attacks because hacking software is what hackers do. Phishing requires the hacker to step outside the shadowy computer world that has definite rules into the social world of people where you have to convince them to do something you want them to do.
So why did Dr. Parkulo and Mayo decide to ignore 90% of cyber security? My guess is that they don't know much about it. Most practices don't. On Dec. 28, 2015, on the same site http://healthcareitnews.com, Bernie Monegain posted a list of the "10 most recent HIPAA breaches" that ALL happened in the first part of December. Even worse, at the bottom of the article there is a slideshow detailing all the big data breaches for 2015 and after that a list of all 1683 known HIPAA data breaches for 2015 according to U.S. Department of Health and Human Services
Office for Civil Rights (OCR).
Clearly Doctors focus on the human side, as they should. I keep crowing about security here, and have stated numerous times that nobody is getting into my database that doesn't shave my face in the morning (barbers don't generally shave me in the morning). I assumed this would taunt hackers into finding some kind of hole they could exploit, but as I suspected, they can't. Our sister company Sentia Health has securely published medical records to the internet in our Software as a Service (SaaS) Electronic Medical Records System (EMR) since 2009 and have never had a breach. Our database uses its very structure to limit the records an authorized user can see to only the ones belonging to patients who call their location primary. There are universal searches as practitioners may need to see records outside of their particular practice but that's only for practitioners with the oddball patient needing attention.
Each time a practitioner (or a patient) logs in he or she is issued a globally unique identifier (GUID) that is unique in the universe and identifies the confluence of that user and that user's session. When the user logs out or gets timed out, that GUID is deleted. The GUID must be supplied for every call to the database and the user is authenticated each time. Even if the User ID and Password were somehow stolen and used to hack into the database, the hacker could only see the names of stored procedures, not even the table names, and wouldn't be able to execute those procedures and/or get any data. I'm tempted to publish the User ID and Password here and let them try. They still won't get anywhere.
As for why Mayo and Dr. Parkulo didn't mention the other 90% of security, it's probably because they have had a couple of data breaches in recent memory as reported by the OCR. Go to the link above (or here), click "Show Advanced Options" and type "Mayo" into "CE / BA Name Search" text box. You'll see what I mean.
I'm positive that if I tried to "doctor" that there would be great gnashing of teeth in the land and I would probably end up in prison. So Doctors, leave the software to us programmers.
Wednesday, September 28, 2016
Dumb Consultants: "Deloitte, KPMG, Accenture fight to help clients use robotic process automation"
Here is the worst thing I've ever read: big consulting companies are automating processes with bots. This was posted in the Australian Financial Review and written by Edmund Tadros.
So let me get this straight. These huge consulting companies are going to come into a company, recommend that they spend millions, or tens of millions of dollars on complicated software packages and then spend millions more to write bots to use them. Brilliant. Brilliant that is if you are a consulting company. You'll get the original markup on the software, the bill rate ($200 or more per hour) to install and configure it, $200 per hour to secure it (kind of), $200 per hour to copy and paste data in and out of it (forever) and then a couple of hunsky per hour to write these bots. That is a little bit like buying an old Ford Tractor, a 1976 AMC Pacer and a filing cabinet and hiring a bunch of engineers to cobble them together into a machine that you can use to haul hay.
If you are going to spend tens of millions on applications (some hospitals spend hundreds of millions) why not write something that does everything you need to do from scratch and be done with it? This eliminates the need for integration, it streamlines (and even makes possible) security, and will be far FAR less expensive. Look, you are writing custom software anyway with these bots, so why not get rid of the complication, look at the inputs and the desired outputs and go from point A to point B in a straight line at a known, measured pace?
I've said for years that I could run Bank of America with 20% of the people they use. That would eliminate 80% of the cost and either they could make 80% more profit or drop prices by 80% and put everyone else out of business. Both those outcomes are desirable.
Here is what your consulting company needs to do: Build one application that does everything your company does, does it automatically and spits out a report at the end of the month detailing how much money you made. We've done that with several businesses before. Not one, not two. Several. Sure, there are times you don't want to reinvent the wheel. If you have a machine that keeps its own database, internally, use that data. Use it right where it sits, but use it as if it were native. Don't import it.
Quit hiring the big consulting companies. Their job is to bill hours and clean out your pockets. If you need help, and you do, call someone who sees the big picture who will take your inputs and truly automate your processes so you get that report at the end of the month telling you how much you made. Free your employees to think and innovate and become profit centers not cost centers. If you see your software as a cost of doing business or a hurdle to be jumped or a necessary evil, you are looking at it the wrong way. We will help you reduce costs, make more sales and make things faster, better and cheaper. What we won't do is sell you unsecurable, prepackaged garbage that you don't need then add layers of complication that will cost outrageous amounts and end up breaking.
So let me get this straight. These huge consulting companies are going to come into a company, recommend that they spend millions, or tens of millions of dollars on complicated software packages and then spend millions more to write bots to use them. Brilliant. Brilliant that is if you are a consulting company. You'll get the original markup on the software, the bill rate ($200 or more per hour) to install and configure it, $200 per hour to secure it (kind of), $200 per hour to copy and paste data in and out of it (forever) and then a couple of hunsky per hour to write these bots. That is a little bit like buying an old Ford Tractor, a 1976 AMC Pacer and a filing cabinet and hiring a bunch of engineers to cobble them together into a machine that you can use to haul hay.
If you are going to spend tens of millions on applications (some hospitals spend hundreds of millions) why not write something that does everything you need to do from scratch and be done with it? This eliminates the need for integration, it streamlines (and even makes possible) security, and will be far FAR less expensive. Look, you are writing custom software anyway with these bots, so why not get rid of the complication, look at the inputs and the desired outputs and go from point A to point B in a straight line at a known, measured pace?
I've said for years that I could run Bank of America with 20% of the people they use. That would eliminate 80% of the cost and either they could make 80% more profit or drop prices by 80% and put everyone else out of business. Both those outcomes are desirable.
Here is what your consulting company needs to do: Build one application that does everything your company does, does it automatically and spits out a report at the end of the month detailing how much money you made. We've done that with several businesses before. Not one, not two. Several. Sure, there are times you don't want to reinvent the wheel. If you have a machine that keeps its own database, internally, use that data. Use it right where it sits, but use it as if it were native. Don't import it.
Quit hiring the big consulting companies. Their job is to bill hours and clean out your pockets. If you need help, and you do, call someone who sees the big picture who will take your inputs and truly automate your processes so you get that report at the end of the month telling you how much you made. Free your employees to think and innovate and become profit centers not cost centers. If you see your software as a cost of doing business or a hurdle to be jumped or a necessary evil, you are looking at it the wrong way. We will help you reduce costs, make more sales and make things faster, better and cheaper. What we won't do is sell you unsecurable, prepackaged garbage that you don't need then add layers of complication that will cost outrageous amounts and end up breaking.
Tuesday, September 27, 2016
Making EMRs Fast, Easy and Intuitive to Use: Removing the Burden of Structured Data
I was cruising around last week and came across "The Burden of Structured Data: What can Healthcare Learn From The Web Experience" from Andy Oram who's writing I have quoted here before. In the second part of the article (the second part is the reason I didn't respond to it last week) he states "ICD should be replaced with something that embodies semantic meaning" and then goes on to say "A big problem in electronic health records is their insistence that certain things be filled out for every patient." resulting in a "Cartesian explosion" and "bloated records."
As we have found before, Andy makes some good observations, but like the healthcare industry in general, he has no clue how to solve the problem or that the problem has already been solved. It seems to me that Google, Bing, and all the other major search engines pretty much licked this problem a long time ago. They give you a two stage search where what you type in generates suggestions AS YOU TYPE with popular searches. That isn't quite the entire solution for healthcare, but that is a great place to start.
The entire solution is to use a purpose built database like SNOMED CT that is designed from the outset for documenting patient encounters and combining it with Bing style searches. That is precisely what we have done here at Sentia Systems, for our sister company Sentia Health. Our solution takes it a bit farther even. We took all the concepts in the SNOMED and made a word table with the number of unique occurrences of every word in every concept. When the user picks a word out of the autocomplete list, we insert that word and a space making compound word searches possible. For example, "abd" would give you "abdominal" and "pa" would give you "pain" and f course we are bright enough to return the matching word with the highest number of occurrences first. Then we do the bing/google thing and search the appropriate concept type for places where "abdominal" is near or next to "pain." This isn't just a wildcard search either. For you techies out there, it is a full text index, meaning that we search for words that SOUND LIKE "abdominal" and "pain" in case the user didn't pick from the list, and in reverse order and NEAR each other, not just next to, or in the same description.
Here are a few pictures to illustrate what we mean:
First we navigate to the appropriate record, open the search window and type "lo":
Then we pick (or continue typing) lower and continue with "ab":
Then we continue typing (or pick) "pa":
Finally, we click the Populate button to actually do the search:
There are quite a few things to notice here:
So yes, Andy (or is it Mr. Oram?), we have conquered the structured data challenge. We document our cases in regular SOAP Notes that are in English (SNOMED also supports many other languages and will translate them automatically) with modifiers (like "left" or "severe") indented and prefaced with a dash.
This is what software is supposed to do: solve problems. We believe that we can enter in a note as fast as we could have typed it in and with far fewer typographical errors. Even better, we now can search for patients with a diagnosis, or with certain symptoms because those things are captured in a structured way.
So tell your Cerners and your Epics and every other vendor of electronic health records out there that they are just doing it wrong. When you factor in the fact that an Epic or a Cerner installation will cost hundreds of millions of dollars to implement, the response time is abysmal, the patient encounter still has to be coded to be paid by the insurance company, and our sister company Sentia Health will do all this, and do it better than the competition can even imagine, and do it for $10/month I think the choice is clear.
So no, Andy, there is no burden, you just need a few good programmers to show you how to do it.
As we have found before, Andy makes some good observations, but like the healthcare industry in general, he has no clue how to solve the problem or that the problem has already been solved. It seems to me that Google, Bing, and all the other major search engines pretty much licked this problem a long time ago. They give you a two stage search where what you type in generates suggestions AS YOU TYPE with popular searches. That isn't quite the entire solution for healthcare, but that is a great place to start.
The entire solution is to use a purpose built database like SNOMED CT that is designed from the outset for documenting patient encounters and combining it with Bing style searches. That is precisely what we have done here at Sentia Systems, for our sister company Sentia Health. Our solution takes it a bit farther even. We took all the concepts in the SNOMED and made a word table with the number of unique occurrences of every word in every concept. When the user picks a word out of the autocomplete list, we insert that word and a space making compound word searches possible. For example, "abd" would give you "abdominal" and "pa" would give you "pain" and f course we are bright enough to return the matching word with the highest number of occurrences first. Then we do the bing/google thing and search the appropriate concept type for places where "abdominal" is near or next to "pain." This isn't just a wildcard search either. For you techies out there, it is a full text index, meaning that we search for words that SOUND LIKE "abdominal" and "pain" in case the user didn't pick from the list, and in reverse order and NEAR each other, not just next to, or in the same description.
Here are a few pictures to illustrate what we mean:
First we navigate to the appropriate record, open the search window and type "lo":
Then we pick (or continue typing) lower and continue with "ab":
Then we continue typing (or pick) "pa":
Finally, we click the Populate button to actually do the search:
There are quite a few things to notice here:
- The autocomplete doesn't give you popular searches, like Google does. It simply corrects your spelling. This allows you to only get 25 results with two letters instead of scrolling through thousands of results that would take a long time up load in any case.
- You can type your entire entry with out picking anything. If you don't want to use the mouse or the scroll buttons, don't.
- The thing you actually wanted to see is at the top, number one position. Other things that might be similar are ranked below.
- If you choose to type, without picking anything in the autocomplete, the spell checking still kicks in. If you search 'hedayk' you still get a list of things with headache in the title, just like Bing.
So yes, Andy (or is it Mr. Oram?), we have conquered the structured data challenge. We document our cases in regular SOAP Notes that are in English (SNOMED also supports many other languages and will translate them automatically) with modifiers (like "left" or "severe") indented and prefaced with a dash.
This is what software is supposed to do: solve problems. We believe that we can enter in a note as fast as we could have typed it in and with far fewer typographical errors. Even better, we now can search for patients with a diagnosis, or with certain symptoms because those things are captured in a structured way.
So tell your Cerners and your Epics and every other vendor of electronic health records out there that they are just doing it wrong. When you factor in the fact that an Epic or a Cerner installation will cost hundreds of millions of dollars to implement, the response time is abysmal, the patient encounter still has to be coded to be paid by the insurance company, and our sister company Sentia Health will do all this, and do it better than the competition can even imagine, and do it for $10/month I think the choice is clear.
So no, Andy, there is no burden, you just need a few good programmers to show you how to do it.
Thursday, September 22, 2016
Beware of Buzzwords. Software Companies Are Selling You a Bill Of Goods
I was reading along yesterday when I ran across this from my buddy Anne Zieger over at EMR and HIPAA crowing about how Machine Learning might tame healthcare's Big Data. First, there is no such thing as Big Data. Depending on whom you talk to, the term big data was either coined by Dr. Francis Diebold at UPenn in a paper called A Personal Perspective on the Origin(s) and Development of \Big Data": The Phenomenon, the Term, and the Discipline or Roger Magoulas from Ultimately, big data is more about attitude than tools; data-driven organizations look at big data as a solution, not a problem. Either way, Big Data is a sales tool to get you to buy that worthless piece of nothing called Hadoop. Beware of Trojans bearing gifts and beware of people trying to sell you things. Hadoop and Map Reduce are combined to give a programmer the ability to sift through huge amounts of unstructured data. The problem with that is that they use Java to loop through this massive data store to look for things. If you've been following along with our blog, you already know why Java is particularly unsuited for this kind of work. Plus, we already have a tool for that and we've had it since 1979. Its called a database. No, databases can't handle unstructured data, but there is no such thing as unstructured data, there is only data that hasn't been structured yet. At Sentia, our solution is to structure the data, shove it into a database and run queries against it. That requires no new technology and the first query will take about as long as doing it the dumb Hadoop way. The second Hadoop query will take just as long as the first, because it works exactly the same way as the first, but the second database query will take thousands of times less, because the data is already structured. If your database server can't handle the volume of data that your Hadoop servers can, format the boxes that Hadoop is installed on and add them to your database cluster. That should solve the problem.
Second (did you forget there was a first already?) just like Big Data, there is no such thing as Machine Learning, at least not yet. Margaret Rouse posted this definition on TechTarget, where she states that machine learning is used by Facebook "... to personalize each member's feed. If a member frequently stops scrolling in order to read or "like" a particular friend's posts, the News Feed will start to show more of that friend's activity earlier in the feed."
We here at Sentia call that a query (yes, on a database) and have been doing it for decades. Here's an example of how we do it. In the Electronic Medical Records (EMR) application we wrote for our sister company Sentia Health, we query the database to find the top twenty diagnoses by doctor in a rolling six week average and rank them by number of occurrences. This allows us to show the doctor a list of the most common things he or she is diagnosing that changes over time. for example, in the fall and winter influenza (the flu) rises to the top of the list and when the doctor selects it, he or she can duplicate the first instance of that diagnosis and copy it over to the new patient, literally completing the patient documentation with one click. We wrote that query in 2002, before there was "Big Data," Hadoop or "Machine Learning." Heck, that was before there even was a Facebook and long before it was open to everyone and FAR before they started using "Machine Learning" to update your newsfeed.
Why do we mention all this to you? We told you above: Beware of Trojans bearing gifts. The people who came up with all this are trying to sell you something. The reporters, in this case bloggers, don't have the faintest idea what they are talking about. Their job is to publish or perish, not to tell it to you straight. While Walter Cronkite didn't have to know what he was talking about to report the news, he just told you what happened and he tried not to put a spin on it. That isn't the case today. The sales people, and everyone hates a sales person, don't care what you think or what the product is as long as they get your cash. They are paid to come up with new verbiage to part a fool from his money. If you are falling for this, yes, you are a fool. If you don't have the tools necessary to winnow the wheat from the chaff in your software purchases, you are an idiot and you deserve what you get. that's fine as long as you are happy with it, but this affects everyone. It is most of the reason that healthcare is claiming 20% of the Gross Domestic Product in the United States. Idiot administrators are buying buzzwords from dishonest salespeople.
Here's another example: Athena Health claims they are a cloud based EMR. Athena is practice management and uses VPN to log in to a desktop remotely. Yes, you log into a windows machine with an installed, windows based application on it. That means every one of their clients has its own installation of their product. Talk about an expensive administration nightmare. That doesn't even count setting up all those machines with the application installed on them. "Cloud" is their buzzword. They want you to think their product is SaaS (Software as a Service) like our sister company Sentia Health provides, but the can't because they don't know how to build applications that run in a browser.
We've talked about buzzwords before. Buzzwords are designed to obfuscate facts and to put lipstick on the pig that a sales person is trying to foist off on you. Yes, YOU, dear reader. If you go to a doctor (or any other business) that buys into this, and all of you do, you end up paying for that polished porcine piece of prevarication out of your own personal pocket.
If you want real software, built without using mind numbing buzzwords, you know who to call. Don't make out with the red lipped porker, or buy a pig in a poke.
Second (did you forget there was a first already?) just like Big Data, there is no such thing as Machine Learning, at least not yet. Margaret Rouse posted this definition on TechTarget, where she states that machine learning is used by Facebook "... to personalize each member's feed. If a member frequently stops scrolling in order to read or "like" a particular friend's posts, the News Feed will start to show more of that friend's activity earlier in the feed."
We here at Sentia call that a query (yes, on a database) and have been doing it for decades. Here's an example of how we do it. In the Electronic Medical Records (EMR) application we wrote for our sister company Sentia Health, we query the database to find the top twenty diagnoses by doctor in a rolling six week average and rank them by number of occurrences. This allows us to show the doctor a list of the most common things he or she is diagnosing that changes over time. for example, in the fall and winter influenza (the flu) rises to the top of the list and when the doctor selects it, he or she can duplicate the first instance of that diagnosis and copy it over to the new patient, literally completing the patient documentation with one click. We wrote that query in 2002, before there was "Big Data," Hadoop or "Machine Learning." Heck, that was before there even was a Facebook and long before it was open to everyone and FAR before they started using "Machine Learning" to update your newsfeed.
Why do we mention all this to you? We told you above: Beware of Trojans bearing gifts. The people who came up with all this are trying to sell you something. The reporters, in this case bloggers, don't have the faintest idea what they are talking about. Their job is to publish or perish, not to tell it to you straight. While Walter Cronkite didn't have to know what he was talking about to report the news, he just told you what happened and he tried not to put a spin on it. That isn't the case today. The sales people, and everyone hates a sales person, don't care what you think or what the product is as long as they get your cash. They are paid to come up with new verbiage to part a fool from his money. If you are falling for this, yes, you are a fool. If you don't have the tools necessary to winnow the wheat from the chaff in your software purchases, you are an idiot and you deserve what you get. that's fine as long as you are happy with it, but this affects everyone. It is most of the reason that healthcare is claiming 20% of the Gross Domestic Product in the United States. Idiot administrators are buying buzzwords from dishonest salespeople.
Here's another example: Athena Health claims they are a cloud based EMR. Athena is practice management and uses VPN to log in to a desktop remotely. Yes, you log into a windows machine with an installed, windows based application on it. That means every one of their clients has its own installation of their product. Talk about an expensive administration nightmare. That doesn't even count setting up all those machines with the application installed on them. "Cloud" is their buzzword. They want you to think their product is SaaS (Software as a Service) like our sister company Sentia Health provides, but the can't because they don't know how to build applications that run in a browser.
We've talked about buzzwords before. Buzzwords are designed to obfuscate facts and to put lipstick on the pig that a sales person is trying to foist off on you. Yes, YOU, dear reader. If you go to a doctor (or any other business) that buys into this, and all of you do, you end up paying for that polished porcine piece of prevarication out of your own personal pocket.
If you want real software, built without using mind numbing buzzwords, you know who to call. Don't make out with the red lipped porker, or buy a pig in a poke.
Thursday, September 15, 2016
"Thinking outside the box," buzzwords and other dumb things that business people say and do
Management consultants and business guys in general are infamous for their meaningless clichés like "drink the Kool-Ade," "open the kimono" or "paradigm shift." Unless you studied Latin or Greek (I did) don't crow to me about paradigms. The worst of these is "thinking outside the box." The business people I have run across don't have the training or experience to truly even know where the walls of "the box" are, much less what is inside or not. I'm not really sure what an MBA prepares a person to do, but I can assure you it isn't innovative thinking.
For example, Sentia had a contract with Jack Henry & Associates in Charlotte to help them add on some regulatory functionality to their Cruise application for Credit Unions. The regulation was called "Tila/Respa." I don't recall what that meant but it was a disclosure of loan terms to the borrower. the regulation was huge, about 50 entities and and average of 20 attributes per entity, or a little over a thousand database fields. My guy got there on September 1 last year and the functionality had to be implemented by October 1. Designing and building a database, designing and building a middle tier and designing and building a user interface using two guys for a thousand plus fields is getting close to impossible. My guy wrote a tool that took the specification, scraped out the names and datatypes of the attributes, assigned them to entities and generated a database. The other guy, meanwhile, was working on a tool to generate Windows forms (yes it was a Windows application, ewww) from the same specification. My guy then pointed Sentia's Object Relational Mapper (ORM) at the new database and generated the middle tier. After some trial and error with naming conventions and such, the generated front end was mated to the generated middle tier and while ugly, worked fine. This whole process took a week. Of course then then the specification changed (six more times) but because we chose to generate the application in toto, all we had to do was regenerate the application and make it pretty.
Why do I tell you this story? As problem solvers, those two guys really "thought outside the box" and delivered not what the client asked for, but what they needed and compensated for the changes they knew were coming. Instead of doing as they were told and "coding tila/respa" (whatever that means) they looked ahead to changed they knew would come (they always do) and instead of slaving away, they designed a flexible solution that would solve the real problem. It was still a lot of hard work, and harder work than "coding tila/respa" (again, whatever that means) but less of it, and flexible enough to compensate for the shifting sands of a requirements document left until the last possible second. So these same two guys knowing that Cruise itself was a complete train wreck with possibly a dozen ways to access its own database, procedural code that has been around since the VB4 days, and generally didn't work and couldn't be fixed, suggested that they use the same methods to cut out all the old middle tier code and replace it with the new code generated from the database schema.
What was the response? "That can't be done."
Well, yes it can and my guy just did it.
In fact, our sister company Sentia Health, just went through a complete rewrite of its EMR's entire user interface a few months ago. That is fairly comparable to what my guy suggested to Jack Henry. In another month or so, we are going regenerate the middle tier with an upgraded version from the new ORM that we have developed. that is PRECISELY what we suggested to Jack Henry and they said couldn't be done.
I still haven't given you the reason I made you read the Jack Henry Story. Here it is: Business doesn't want "outside the box" thinking. Further, they don't recognize it when they see it, or even when it is shoved down their throats and proven to work. There it is. THAT is the reason.
So yeah, we still haven't addressed buzzwords. The business guys don't get those either. XML, Web Services, XAML, Big Data, WPF, WCF, SOAP, REST, NoSQL, Hadoop, don't make sense in most applications and some don't make any sense at all. "The smart guys got a PhD for a dissertation on Big Data so I need some Big Data in my solution!" Well, no, you don't and there is no such thing as big data. Microsoft has a Big Data solution and it has been around for decades: SQL Server. Don't run procedural code against your unstructured data, structure it and run set based code using a database engine.
So once again, it is conclusion time. Until we quit letting the MBAs run anything, including their mouths, we are never going to get anywhere useful. Regular readers will recognize the Bob Cratchit theory: Businesses are doing nothing differently now than they did in 1843 at Scrooge and Marley's counting house, they just have the spreadsheets on a computer today.
The conclusion of the conclusion is to let the MBAs worry about funding and shares and corporate structure. Let the truly smart people decide HOW things are going to be done. THIS is what we have and THAT is what we want and we software guys will show you the best way to get from THIS to THAT. At Sentia we have automated entire businesses. Not just one, not two, but many. We took an existing business and automated it to the point that there is nothing to do but click the "Send bills" button at the end of the month. Literally. In the most recent case of Coffee County Alabama Office of the Constable, We spent three days writing a system for the deputy constables to issue electronic tickets. No paper. No filing cabinets. No lost documents. We wrote it for free and they use it for a $10 monthly subscription per login. The automatic generation of cases for the constables and the automatic generation of court dockets alone pay for the system, since they no longer have to pay someone to produce these reports. Even better, If you get pulled over in Coffee County, you probably are only going to be issued a warning, because they now have the ability to see if you are an habitual offender. You don't live there, so you get a warning.
That is the way we do things: Automation, make it easy. Doesn't everyone need some of that?
For example, Sentia had a contract with Jack Henry & Associates in Charlotte to help them add on some regulatory functionality to their Cruise application for Credit Unions. The regulation was called "Tila/Respa." I don't recall what that meant but it was a disclosure of loan terms to the borrower. the regulation was huge, about 50 entities and and average of 20 attributes per entity, or a little over a thousand database fields. My guy got there on September 1 last year and the functionality had to be implemented by October 1. Designing and building a database, designing and building a middle tier and designing and building a user interface using two guys for a thousand plus fields is getting close to impossible. My guy wrote a tool that took the specification, scraped out the names and datatypes of the attributes, assigned them to entities and generated a database. The other guy, meanwhile, was working on a tool to generate Windows forms (yes it was a Windows application, ewww) from the same specification. My guy then pointed Sentia's Object Relational Mapper (ORM) at the new database and generated the middle tier. After some trial and error with naming conventions and such, the generated front end was mated to the generated middle tier and while ugly, worked fine. This whole process took a week. Of course then then the specification changed (six more times) but because we chose to generate the application in toto, all we had to do was regenerate the application and make it pretty.
Why do I tell you this story? As problem solvers, those two guys really "thought outside the box" and delivered not what the client asked for, but what they needed and compensated for the changes they knew were coming. Instead of doing as they were told and "coding tila/respa" (whatever that means) they looked ahead to changed they knew would come (they always do) and instead of slaving away, they designed a flexible solution that would solve the real problem. It was still a lot of hard work, and harder work than "coding tila/respa" (again, whatever that means) but less of it, and flexible enough to compensate for the shifting sands of a requirements document left until the last possible second. So these same two guys knowing that Cruise itself was a complete train wreck with possibly a dozen ways to access its own database, procedural code that has been around since the VB4 days, and generally didn't work and couldn't be fixed, suggested that they use the same methods to cut out all the old middle tier code and replace it with the new code generated from the database schema.
What was the response? "That can't be done."
Well, yes it can and my guy just did it.
In fact, our sister company Sentia Health, just went through a complete rewrite of its EMR's entire user interface a few months ago. That is fairly comparable to what my guy suggested to Jack Henry. In another month or so, we are going regenerate the middle tier with an upgraded version from the new ORM that we have developed. that is PRECISELY what we suggested to Jack Henry and they said couldn't be done.
I still haven't given you the reason I made you read the Jack Henry Story. Here it is: Business doesn't want "outside the box" thinking. Further, they don't recognize it when they see it, or even when it is shoved down their throats and proven to work. There it is. THAT is the reason.
So yeah, we still haven't addressed buzzwords. The business guys don't get those either. XML, Web Services, XAML, Big Data, WPF, WCF, SOAP, REST, NoSQL, Hadoop, don't make sense in most applications and some don't make any sense at all. "The smart guys got a PhD for a dissertation on Big Data so I need some Big Data in my solution!" Well, no, you don't and there is no such thing as big data. Microsoft has a Big Data solution and it has been around for decades: SQL Server. Don't run procedural code against your unstructured data, structure it and run set based code using a database engine.
So once again, it is conclusion time. Until we quit letting the MBAs run anything, including their mouths, we are never going to get anywhere useful. Regular readers will recognize the Bob Cratchit theory: Businesses are doing nothing differently now than they did in 1843 at Scrooge and Marley's counting house, they just have the spreadsheets on a computer today.
The conclusion of the conclusion is to let the MBAs worry about funding and shares and corporate structure. Let the truly smart people decide HOW things are going to be done. THIS is what we have and THAT is what we want and we software guys will show you the best way to get from THIS to THAT. At Sentia we have automated entire businesses. Not just one, not two, but many. We took an existing business and automated it to the point that there is nothing to do but click the "Send bills" button at the end of the month. Literally. In the most recent case of Coffee County Alabama Office of the Constable, We spent three days writing a system for the deputy constables to issue electronic tickets. No paper. No filing cabinets. No lost documents. We wrote it for free and they use it for a $10 monthly subscription per login. The automatic generation of cases for the constables and the automatic generation of court dockets alone pay for the system, since they no longer have to pay someone to produce these reports. Even better, If you get pulled over in Coffee County, you probably are only going to be issued a warning, because they now have the ability to see if you are an habitual offender. You don't live there, so you get a warning.
That is the way we do things: Automation, make it easy. Doesn't everyone need some of that?
Tuesday, September 6, 2016
You Can't Automate Judgment and You Should Not Try
I have been corresponding recently with a couple of my code monkey buddies, both hard working, brilliant developers. They are complaining about the big applicant tracking packages employed by larger companies, that is, Oracle's Taleo, iCIMS, Bullhorn, et al.
They complain about several things:
Yes, there are some jobs that can't and shouldn't be automated. Stock trading. Engineering. Putting eyeballs on a resume. In the new age of information, We have people doing all kinds of menial tasks like opening and filling out spreadsheets and then emailing them around, that could and should be automated. Then we have some dumb piece of software actually making value judgments about something that even the person who came up with the requirements doesn't understand. Here is an example: My friend Randy is applying for a web developer job. One of the questions, after he retyped all his employment and education history that was in his resume of course, was "How much Web API experience do you have?" For those of you who don't know, Web API is nothing more than an MVC controller with HTTP methods like GET, POST and PUT. So instead of having a Create method in the Person Controller, you'd have a Post method with the exact same implementation. The only difference is the naming convention. Randy has built dozens of MVC applications, but has never even created a Web API application, because there is nothing to know. If he answers truthfully, he will certainly be passed over. If he give s a more correct answer, like 'all of it' he could been fired down the road for padding his resume.
This is indicative of the biggest problem in business today. The people running a company literally have no idea what the company does or how it does it and can't even recognize talent when it comes knocking. Years ago, the big buzzword was XML. Every job description you read REQUIRED the applicant to be able to read and write XML. Don't get me wrong, it's a great technology for inter-operation and essential to web services like SOAP. However in 20 some years of development, I've never had to read nor written XML. It's kind of like saying 'Do you have and can you explain your experience with breathing?'
'Yes, and no' in that order. Yes, I breathe, no, I am not going to give you a lecture in the chemistry of what happens in my lungs. You don't need to know.
Almost 30 years ago, I was helping my father frame a house. I stood up on the joists and he cut off and handed rafters up to me. Having been exposed to trigonometry, I was amazed that not only did Pop remember all the tables we had to memorize for trig, but that he was doing all the calculations for the rafter length in his head. I asked him how he did that. He said "you don't need to know."
I stewed on that for about 30 minutes and decided that I do need to know. I got a little belligerent and more forcefully posed the question again: "How do you know how long to cut off the rafters?"
He looked a little sheepish and replied "I don't know how long to cut off the rafters. It's built into the carpenter's square. Literally, you don't need to know." then he showed me how to cut off rafters with a carpenter's square.
What is the moral of the story? Sometimes, you just don't need to know. Randy doesn't need to know how long to cut rafters, he doesn't need to know how to breathe, he doesn't need to know XML and he doesn't need to know Web API. You just don't need to know.
In our post at SentiaHealth.com on September 2, 2016, Theory of Constraints: An Holistic Approach To Solutions Architecture: Why You All Are Doing It Wrong and What To Do Instead, we introduced Eli Goldratt and the Theory of Constraints and its application to the software industry. Mr. Goldratt states
Technology can bring benefits if and only if it diminishes a limitation. Long before the availability of technology we developed modes of behavior, policies, measurements and rules to help us accommodate that limitation. If we want to be successful with the implementation of new technology, we must find the things that helped us live with the old limitations and change the rules to take advantage of the new methods.
So what we need are smart people doing smart things, not Human Resources managers looking for buzzwords and weeding out people who don't have them. If you are going to successfully remove weeds, first you have to know what a weed looks like. Today we are picking on Human Resources but that department is just indicative of the larger problem. The problem is that literally nobody is taking advantage of the new technology to rid us of the limitations we have imposed to solve problems that we no longer have. You don't need spreadsheets anymore. Conversely, an in this example with Taleo et al, we have a limitation that technology cannot help with. You cannot (currently?) teach a computer to read a resume. You have to have human eyeballs and human judgement to figure out if someone is qualified for a technical job. That is it, No way around it. I say this, me, the guru or all things automation.
Even worse, Human Resources itself is attempting to do a job they aren't designed to do. They don't understand the technology, clearly, or they wouldn't be using software to automate an unautomatable job.
Yes, technology can help. Your "apply for this job application" should be a link to upload your resume. Process automated. You don't go to the hardware store and ask the clerk about the materials used to create your wrench or hammer or pliers. You don't know how to make those things so even if the clerk told you that this particular wrench was constructed from chrome plated, cold forged, 4140 chrome-molly billet, and he can't because he doesn't know either, you won't understand what that meant anyway.
Once more, if you can't do what I do, and you can't, don't presume to tell me how to do it. Go get a copy of Eli Goldratt's "Necessary But Not Sufficient." 80% of any business today can be automated. That means 80% fewer people, 80% fewer buildings, 80% electricity savings and 80% less cost. It also means you should be able to cut the price of your product or service by 80% and still make the same profit. I know this is true because I run MY business that way and I have automated 80% of the production of my products and I am 80% less expensive than any competition. Know what the 20% is that can't be automated, however. Get to know old Pareto. Let's remove the old limitations and free the spreadsheet emailers of the world to think and innovate and be a profit center, not a cost center. Let's think and innovate and NOT attempt to automate the unautomatable.
They complain about several things:
- duplicating information
- complicated password algorithms
- dumb questions with "N/A if no" answers
- half hour or more to apply for a job
Yes, there are some jobs that can't and shouldn't be automated. Stock trading. Engineering. Putting eyeballs on a resume. In the new age of information, We have people doing all kinds of menial tasks like opening and filling out spreadsheets and then emailing them around, that could and should be automated. Then we have some dumb piece of software actually making value judgments about something that even the person who came up with the requirements doesn't understand. Here is an example: My friend Randy is applying for a web developer job. One of the questions, after he retyped all his employment and education history that was in his resume of course, was "How much Web API experience do you have?" For those of you who don't know, Web API is nothing more than an MVC controller with HTTP methods like GET, POST and PUT. So instead of having a Create method in the Person Controller, you'd have a Post method with the exact same implementation. The only difference is the naming convention. Randy has built dozens of MVC applications, but has never even created a Web API application, because there is nothing to know. If he answers truthfully, he will certainly be passed over. If he give s a more correct answer, like 'all of it' he could been fired down the road for padding his resume.
This is indicative of the biggest problem in business today. The people running a company literally have no idea what the company does or how it does it and can't even recognize talent when it comes knocking. Years ago, the big buzzword was XML. Every job description you read REQUIRED the applicant to be able to read and write XML. Don't get me wrong, it's a great technology for inter-operation and essential to web services like SOAP. However in 20 some years of development, I've never had to read nor written XML. It's kind of like saying 'Do you have and can you explain your experience with breathing?'
'Yes, and no' in that order. Yes, I breathe, no, I am not going to give you a lecture in the chemistry of what happens in my lungs. You don't need to know.
Almost 30 years ago, I was helping my father frame a house. I stood up on the joists and he cut off and handed rafters up to me. Having been exposed to trigonometry, I was amazed that not only did Pop remember all the tables we had to memorize for trig, but that he was doing all the calculations for the rafter length in his head. I asked him how he did that. He said "you don't need to know."
I stewed on that for about 30 minutes and decided that I do need to know. I got a little belligerent and more forcefully posed the question again: "How do you know how long to cut off the rafters?"
He looked a little sheepish and replied "I don't know how long to cut off the rafters. It's built into the carpenter's square. Literally, you don't need to know." then he showed me how to cut off rafters with a carpenter's square.
What is the moral of the story? Sometimes, you just don't need to know. Randy doesn't need to know how long to cut rafters, he doesn't need to know how to breathe, he doesn't need to know XML and he doesn't need to know Web API. You just don't need to know.
In our post at SentiaHealth.com on September 2, 2016, Theory of Constraints: An Holistic Approach To Solutions Architecture: Why You All Are Doing It Wrong and What To Do Instead, we introduced Eli Goldratt and the Theory of Constraints and its application to the software industry. Mr. Goldratt states
Technology can bring benefits if and only if it diminishes a limitation. Long before the availability of technology we developed modes of behavior, policies, measurements and rules to help us accommodate that limitation. If we want to be successful with the implementation of new technology, we must find the things that helped us live with the old limitations and change the rules to take advantage of the new methods.
So what we need are smart people doing smart things, not Human Resources managers looking for buzzwords and weeding out people who don't have them. If you are going to successfully remove weeds, first you have to know what a weed looks like. Today we are picking on Human Resources but that department is just indicative of the larger problem. The problem is that literally nobody is taking advantage of the new technology to rid us of the limitations we have imposed to solve problems that we no longer have. You don't need spreadsheets anymore. Conversely, an in this example with Taleo et al, we have a limitation that technology cannot help with. You cannot (currently?) teach a computer to read a resume. You have to have human eyeballs and human judgement to figure out if someone is qualified for a technical job. That is it, No way around it. I say this, me, the guru or all things automation.
Even worse, Human Resources itself is attempting to do a job they aren't designed to do. They don't understand the technology, clearly, or they wouldn't be using software to automate an unautomatable job.
Yes, technology can help. Your "apply for this job application" should be a link to upload your resume. Process automated. You don't go to the hardware store and ask the clerk about the materials used to create your wrench or hammer or pliers. You don't know how to make those things so even if the clerk told you that this particular wrench was constructed from chrome plated, cold forged, 4140 chrome-molly billet, and he can't because he doesn't know either, you won't understand what that meant anyway.
Once more, if you can't do what I do, and you can't, don't presume to tell me how to do it. Go get a copy of Eli Goldratt's "Necessary But Not Sufficient." 80% of any business today can be automated. That means 80% fewer people, 80% fewer buildings, 80% electricity savings and 80% less cost. It also means you should be able to cut the price of your product or service by 80% and still make the same profit. I know this is true because I run MY business that way and I have automated 80% of the production of my products and I am 80% less expensive than any competition. Know what the 20% is that can't be automated, however. Get to know old Pareto. Let's remove the old limitations and free the spreadsheet emailers of the world to think and innovate and be a profit center, not a cost center. Let's think and innovate and NOT attempt to automate the unautomatable.
Wednesday, August 31, 2016
Due Diligence In Selecting Technology
Information Technology is not a religion. Your buzzwords are not a mantra. When a developer is confronted with a new technology s/he must evaluate this new technology and decide what the value is in relation to the learning curve, not just jump on the bandwagon. Even worse is the management type who decides he is going down a technological path because he met the Tableau salesman on the golf course.
At Sentia we take the technology selection process VERY seriously. We choose Microsoft not because we are told to or because we are familiar with it, we choose Microsoft because it is the ONLY vendor who provides a complete solution from database to desktop to web. We choose Windows not only because it is the Microsoft operating system, but because it doesn't require a six figure administrator to configure and make work. We choose SQL Server because it is faster than Oracle (the only other real choice) on Windows. We choose .NET because it has a well documented amazing Integrated Development Environment (IDE) in Visual Studio, and it doesn't need a ton of other tools to develop applications. Gradle. Eclipse. IntelliJ. YourKit. Clover. The list goes on ad nauseum.
We are so adamant about choosing the right tool for the job that we didn't even develop web applications until 2009 when Microsoft introduced their version of the Model/View/Controller (MVC) technology that got rid of the notion of statefulness across the internet and gave us a way to build web applications that made sense. At the time it didn't make sense to jump ship to Apache/PHP on Unix/Linux (pronounced Line-Ux, the guy's name is Linus Thorvald) just to get web technology that makes sense. I might make a different decision today.
Sure, Microsoft has made some grabs at the money tree with SharePoint and BizTalk. These applications are designed to make a complicated task easier than it is. SharePoint is nothing more than FrontPage (a WYSIWYG web page generating tool), along with document management. You already have a powerful tool to develop webpages and web applications in Visual Studio (the IDE we talked about above) and you don't need documents. No really. You don't need documents. An attorney MIGHT need a signature, but the contents of the document should be put in the database so it can be indexed and searched. SharePoint is the electronic version of a file cabinet and the people who advocate, develop for, and use it should be fired. BizTalk is more of the same. It allows developers to use disparate data sources as native. We already have a way to use any data source as native with SQL Server Linked Servers. In fact, Linked Servers is the basis for Sentia's Information Integrator, an ETL tool that is so easy to use we think anyone can do it.
Yes, we also know that we have to use JavaScript or can use jQuery or AngularJS or some other plug in to make out webpages look pretty and add functionality. Microsoft was so dead set on ASP and ASP.NET that they attempted to force everyone to use their technology. Now however with the advent of MVC and NuGet, we can use these plugins and maintain versioning on them (there seems to be a new version every week) easily with Microsoft tools.
What do we get for this loyalty? We get a single group of developers who can do everything that needs to be done, from start to finish, without having to learn the latest flavor of some dumb Java tool or write a servelet to make Apache work, or know nothing about database design and development because they have never seen one. We get to say 'This is the way we do things' and if that way changes, we all change together. We get to build tools that automate the development of software because we all agree that 'this is what we do, and this is the way we do it.' We don't have some new guy saying 'Gee I know this and I use that' We have the old guys saying 'this the the best way and we know because we spent the time and did the due diligence to make sure that it is.'
The conclusion is that with this methodology, and the tools we have developed to generate about 80% of the code we deploy, we always do the same thing, the same way every time. This makes the code base easy to read, intuitive and simple to maintain. That doesn't even count the elimination of 80% of the development time and expense for our clients.
Really, if you have anyone else develop your applications, you are making a mistake. If your project is done differently, it is done wrongly and you will save your time, money and effort. Even better, if we can automate what we do, we can automate what you do. We have clients who used to run themselves ragged 80 or 100 hours per week, dozens of employees, emailing spreadsheets and working fingers to the bone, who now only click a button to generate bills at the end of the month. 80-100 hours to 35 seconds and dozens of expensive employees to none. It isn't religion, it is efficiency. That is what we do.
http://sentiasystems.com
At Sentia we take the technology selection process VERY seriously. We choose Microsoft not because we are told to or because we are familiar with it, we choose Microsoft because it is the ONLY vendor who provides a complete solution from database to desktop to web. We choose Windows not only because it is the Microsoft operating system, but because it doesn't require a six figure administrator to configure and make work. We choose SQL Server because it is faster than Oracle (the only other real choice) on Windows. We choose .NET because it has a well documented amazing Integrated Development Environment (IDE) in Visual Studio, and it doesn't need a ton of other tools to develop applications. Gradle. Eclipse. IntelliJ. YourKit. Clover. The list goes on ad nauseum.
We are so adamant about choosing the right tool for the job that we didn't even develop web applications until 2009 when Microsoft introduced their version of the Model/View/Controller (MVC) technology that got rid of the notion of statefulness across the internet and gave us a way to build web applications that made sense. At the time it didn't make sense to jump ship to Apache/PHP on Unix/Linux (pronounced Line-Ux, the guy's name is Linus Thorvald) just to get web technology that makes sense. I might make a different decision today.
Sure, Microsoft has made some grabs at the money tree with SharePoint and BizTalk. These applications are designed to make a complicated task easier than it is. SharePoint is nothing more than FrontPage (a WYSIWYG web page generating tool), along with document management. You already have a powerful tool to develop webpages and web applications in Visual Studio (the IDE we talked about above) and you don't need documents. No really. You don't need documents. An attorney MIGHT need a signature, but the contents of the document should be put in the database so it can be indexed and searched. SharePoint is the electronic version of a file cabinet and the people who advocate, develop for, and use it should be fired. BizTalk is more of the same. It allows developers to use disparate data sources as native. We already have a way to use any data source as native with SQL Server Linked Servers. In fact, Linked Servers is the basis for Sentia's Information Integrator, an ETL tool that is so easy to use we think anyone can do it.
Yes, we also know that we have to use JavaScript or can use jQuery or AngularJS or some other plug in to make out webpages look pretty and add functionality. Microsoft was so dead set on ASP and ASP.NET that they attempted to force everyone to use their technology. Now however with the advent of MVC and NuGet, we can use these plugins and maintain versioning on them (there seems to be a new version every week) easily with Microsoft tools.
What do we get for this loyalty? We get a single group of developers who can do everything that needs to be done, from start to finish, without having to learn the latest flavor of some dumb Java tool or write a servelet to make Apache work, or know nothing about database design and development because they have never seen one. We get to say 'This is the way we do things' and if that way changes, we all change together. We get to build tools that automate the development of software because we all agree that 'this is what we do, and this is the way we do it.' We don't have some new guy saying 'Gee I know this and I use that' We have the old guys saying 'this the the best way and we know because we spent the time and did the due diligence to make sure that it is.'
The conclusion is that with this methodology, and the tools we have developed to generate about 80% of the code we deploy, we always do the same thing, the same way every time. This makes the code base easy to read, intuitive and simple to maintain. That doesn't even count the elimination of 80% of the development time and expense for our clients.
Really, if you have anyone else develop your applications, you are making a mistake. If your project is done differently, it is done wrongly and you will save your time, money and effort. Even better, if we can automate what we do, we can automate what you do. We have clients who used to run themselves ragged 80 or 100 hours per week, dozens of employees, emailing spreadsheets and working fingers to the bone, who now only click a button to generate bills at the end of the month. 80-100 hours to 35 seconds and dozens of expensive employees to none. It isn't religion, it is efficiency. That is what we do.
http://sentiasystems.com
Friday, August 26, 2016
Object Relational Mappers: Why and Why NOT Use Them
As developers, we find that the database king; it is the foundation on which all other software is written. The problem with that is that nobody starts out as a database developer. In our quest to become the perfect developer, almost all of us neglect the first and most important step, learning about databases. First, we find ourselves struggling to wrap our minds around set based programming (remember trying to find a quarter sized rock using tweezers and a magnifying glass instead of two boxes, one with holes slightly larger than a quarter and the other with holes slightly smaller?) Second, we have to pick some type of data access language and understand that whatever it is that we pick probably has memory leaks and definitely has a ton of overhead. If you live in Microsoft's world you have to remember to close your ADO.NET connection and dispose of your objects when you are done with them. Third, we have to decide how to model the middle tier objects and what logic goes where. There is little wonder that most (I've heard as high as 90%) new software begun has never seen production.
So there has to be a better way, right? Surely someone has written an application that does all this grunt work for you. Enter the Object Relational Mapper. Wikipedia states:
"Object-relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to construct their own ORM tools."
"That sounds great!" you say.
"I want one!" you exclaim.
"Which one do I use?" you ask.
Aye, but there's the rub. Honestly, if you don't understand what all this automagic stuff is doing, you probably shouldn't use it. First, I eschew using anything that doesn't allow me to pull back the curtain as see how it works. Microsoft provides Entity Framework which installs all kinds of visual geegaws to access your data, and all kinds of code with the warning (and I paraphrase) 'You don't know what this does so don't mess with it.' If that particular code doesn't do what I think it should do, I want to know why and I simply can't. All of the ORMs I have used and heard of suffer from this problem.
Another problem is that you don't know what kind of set based code is getting run on your sever. One of the biggest problems with any application is "it's running slowly" and everyone looks at the database. If you can't see the code running, you certainly can't troubleshoot it.
Best database design practices are to lock the users out of the table structure and all data access is done through stored procedures, so we can apply logic and security and auditing. Unless your ORM writes procedures (and it doesn't) you have to write them yourself. That kind of makes the ORM useless as a code generation tool, since you have to write your own code anyway. Even worse, all the set based code I've seen, is horrible. if you venture one little pinky toe outside of simple Create/Read/Update/Delete (CRUD) operations and you will, you have to do searches at a minimum, the set based code passed by these ORM tools gets hairy fast.
We, here at Sentia wrote our own ORM, and we call it the Object Relational Mapper (of course). We think of it less as an ORM and more of a code generation tool that we use to produce the same code that we would have written by hand anyway. Sentia's ORM produces all the stored procedures for CRUD and additionally provides a Search capability as well. More stored procedures are generated to access related data. If we want all the blue cars we do a search where car.ColorID = 36 (36 is blue and we can search for that as well) but we can also search for many to many relationships. If we want to get a student's class schedule it might look like this Class class = new Class(student.StudentID, GetClassesByForeignKey.ByStudentID). That might be the very first line of code we have written in this application, it uses stored procedures so we can be secure, and it is returned by code that a good developer might write, not some black box that has a skull and crossbones warning on it.
There are several things we've had to do over the years to make the code produced by Sentia's ORM more usable. We put all the generated code in a 'Generated Code' folder so we can tell what was produced and what was hand written. All the generated code is put into partial classes so that we can extend the functionality of them without having to come up with kludgy new names. We are working on an application where the user can sign up for the service. All calls to the database require a username and password that a new user won't have. We has to extend the Professionals class with a new method that took a new professional object with its properties set called CreateNew that didn't require a User Name and Password. This is all seamless to the downstream developer of course. he would expect to see professionals.Add or Professionals.Delete in the intellisense menu, and now s/he can also see CreateNew(Professional).
What is the conclusion? We decided that Sentia's ORM should write the code that we would write if we were absolutely perfect and did everything that we were supposed to do. In many ways, generating code like that is the ONLY way to get it. Otherwise, using nHibernate or the Entity Framework or whatever other half-assed thing you need to get the job done is ok, if you are writing a movie list application for your mother to access her collection online or you are a junior developer who can't get the job done any other way. If you are a junior developer and you can't get things accomplished any other way, know that you are going to have scalability and security problems. Even worse, you can't write the code that Sentia's ORM generates. We can't. Even we end up cutting corners sometimes, and it takes us weeks or months to do the same work completed in seconds with Sentia's ORM.
What should you do, dear reader? You should either come to work for us, or give up and have us write your application for you. Heck, if you sell it for the price you think you can produce it for, call us and we'll do it for half.
It ain't arrogant if it is true.
So there has to be a better way, right? Surely someone has written an application that does all this grunt work for you. Enter the Object Relational Mapper. Wikipedia states:
"Object-relational mapping (ORM, O/RM, and O/R mapping tool) in computer science is a programming technique for converting data between incompatible type systems in object-oriented programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language. There are both free and commercial packages available that perform object-relational mapping, although some programmers opt to construct their own ORM tools."
"That sounds great!" you say.
"I want one!" you exclaim.
"Which one do I use?" you ask.
Aye, but there's the rub. Honestly, if you don't understand what all this automagic stuff is doing, you probably shouldn't use it. First, I eschew using anything that doesn't allow me to pull back the curtain as see how it works. Microsoft provides Entity Framework which installs all kinds of visual geegaws to access your data, and all kinds of code with the warning (and I paraphrase) 'You don't know what this does so don't mess with it.' If that particular code doesn't do what I think it should do, I want to know why and I simply can't. All of the ORMs I have used and heard of suffer from this problem.
Another problem is that you don't know what kind of set based code is getting run on your sever. One of the biggest problems with any application is "it's running slowly" and everyone looks at the database. If you can't see the code running, you certainly can't troubleshoot it.
Best database design practices are to lock the users out of the table structure and all data access is done through stored procedures, so we can apply logic and security and auditing. Unless your ORM writes procedures (and it doesn't) you have to write them yourself. That kind of makes the ORM useless as a code generation tool, since you have to write your own code anyway. Even worse, all the set based code I've seen, is horrible. if you venture one little pinky toe outside of simple Create/Read/Update/Delete (CRUD) operations and you will, you have to do searches at a minimum, the set based code passed by these ORM tools gets hairy fast.
We, here at Sentia wrote our own ORM, and we call it the Object Relational Mapper (of course). We think of it less as an ORM and more of a code generation tool that we use to produce the same code that we would have written by hand anyway. Sentia's ORM produces all the stored procedures for CRUD and additionally provides a Search capability as well. More stored procedures are generated to access related data. If we want all the blue cars we do a search where car.ColorID = 36 (36 is blue and we can search for that as well) but we can also search for many to many relationships. If we want to get a student's class schedule it might look like this Class class = new Class(student.StudentID, GetClassesByForeignKey.ByStudentID). That might be the very first line of code we have written in this application, it uses stored procedures so we can be secure, and it is returned by code that a good developer might write, not some black box that has a skull and crossbones warning on it.
There are several things we've had to do over the years to make the code produced by Sentia's ORM more usable. We put all the generated code in a 'Generated Code' folder so we can tell what was produced and what was hand written. All the generated code is put into partial classes so that we can extend the functionality of them without having to come up with kludgy new names. We are working on an application where the user can sign up for the service. All calls to the database require a username and password that a new user won't have. We has to extend the Professionals class with a new method that took a new professional object with its properties set called CreateNew that didn't require a User Name and Password. This is all seamless to the downstream developer of course. he would expect to see professionals.Add or Professionals.Delete in the intellisense menu, and now s/he can also see CreateNew(Professional).
What is the conclusion? We decided that Sentia's ORM should write the code that we would write if we were absolutely perfect and did everything that we were supposed to do. In many ways, generating code like that is the ONLY way to get it. Otherwise, using nHibernate or the Entity Framework or whatever other half-assed thing you need to get the job done is ok, if you are writing a movie list application for your mother to access her collection online or you are a junior developer who can't get the job done any other way. If you are a junior developer and you can't get things accomplished any other way, know that you are going to have scalability and security problems. Even worse, you can't write the code that Sentia's ORM generates. We can't. Even we end up cutting corners sometimes, and it takes us weeks or months to do the same work completed in seconds with Sentia's ORM.
What should you do, dear reader? You should either come to work for us, or give up and have us write your application for you. Heck, if you sell it for the price you think you can produce it for, call us and we'll do it for half.
It ain't arrogant if it is true.
Tuesday, August 23, 2016
If You Are Using Email for Workflow, Excel or QuickBooks At All, You Are Wasting Time and Money
That statement probably just cheesed a whole lot of you off
and the sad part is that it is 100% true.
Here is what you are doing now: you get some kind of information over
email from someone in your organization.
You do a little number crunching in Excel and attach the spreadsheet to an
email that you then send to accounting.
In accounting, the spreadsheet is opened, maybe some more number
crunching goes on, the data gets entered into QuickBooks and maybe a check is issued or a report generated. Sound
about right? This is absolutely wrong,
and it’s not just the top three offenders here, it is every separate
application you type anything into.
Don’t feel badly, that’s the way everyone, from Bank of
America on down, does it. There is a better way. What if the person who generated the data
originally could type it into a custom built application that does exactly what
you do, for you? Let’s take an
example. You have a guy on the loading
dock receiving shipments. Usually, s/he
will count the number of boxes and sign a bill of lading and hand carry a copy
to Accounts Payable who types the items in to QuickBooks then issues a check. What if, instead,
the guy/girl at the loading dock, scanned each box as it came in and this
hypothetical piece of software recorded it, counted it, added it to inventory
and issued a check to pay for it and put it in the ledger all in one fell swoop? What if the warehouse person scanned the box
and the barcode at some location in the warehouse where the box is going to live until the
contents are needed? Then you know where
the box is, what and how many it contains, how long it has been there and what
it has cost you to warehouse it, since you know how many cubic feet are in the
warehouse, what the fixed and variable costs for it are and the size of the
box. You just eliminated all the
overhead in your company that doesn’t actually move the ball forward AND gained valuable insights into cash and inventory flow.
We already told you that everyone runs a company the former
way and not the latter. Many of you are
too young to remember Braniff, so we’ll use a more recent example (and we’ll also
discount the financial sector since they are not too bright (how to you have
billions in assets and go bankrupt? (the question is rhetorical, I know what
happened (and they are still idiots (and I know you love my nested
parentheticals)))) and the energy sector since they financial sector took them
down in 2008 (…and Enron cooked the books)).
USAir filed one of the largest bankruptcies in history for the same
reason Braniff did: they don’t know how much it costs to fly you from Point A
to Point B. Substitute Chrysler.
Substitute Worldcom. We use USAir because
what they do is more of a commodity. So
if they don’t know how much it costs to fly you where you want to go, and
someone else has a sale and can do it cheaper and the brass at USAir thinks
that nobody can do it better, they price their service lower, and less than it can be provided for, and
BAM bankruptcy.
I tell you the USAir story for one
reason. If they used a system like the
one I can build for you, they wouldn’t have failed. They would know that it takes X number of
pounds of kerosene for your particular trip and that the kerosene going into
that airframe was bought for Y dollars per pound and the airframe itself can be
amortized over Z years at a cost of W per year and the pilot makes V dollars
per flight and the attendant makes U dollars per hour and the maintenance is Q
dollars per month (they don’t wait for parts to fail, when they get so many
hours they replace them (you can’t just pull over on the side of the sky) and
on and on ad nauseum. The point is, it is
calculable, and they could have done it and didn’t, they depended on
YOU, dear reader, to bail them out. So if they knew how to calculate the cost
of your trip, they could add whatever profit they deem appropriate and go about
their business. When American or Delta
offers a sale that is less than the cost of providing the service, you can
laugh up your sleeve and let them. Then you can watch Delta and American go file bankruptcy.
Notice how we switched from USAir
to you? Yes this all applies to
you. Whether you are a roofer or an
accountant or Brian Moynihan (of Bank of America) if you are emailing
spreadsheets, or even have separate applications for HR, Accounting,
Warehousing, Project/Process Management,
you are missing the boat. You need one
application to rule them all so that when the product hits the dock, the check
gets printed (or ACHed, whichever). Or
when you make a sale, the proceeds go directly into accounting, no typing, and therefore no people required. People are expensive and they make mistakes. Software is comparatively free and doesn't need to type. If you have this kind of application in place
you can automate everything but the actual hammering of nails and selling of
houses (or building and selling Chryslers (they automate a lot of the production
too) or flying people around the country).
…and you can automate a lot of the marketing as well.
So yes, Virginia, there is a Santa
Claus. If nobody else is doing business
this way, and you can, you should. …and
put your competitors out of business. If
you go to one of our sister company’s website http://sentiahealth.com
we will explain how we automated the entire health insurance industry. That will save the American health insurance
consumer about 1/3 of their bill. Not $300,
$200. Not $1200 for your family,
$800. Collectively, we will save you
(all) one trillion dollars.
We have done the same for several companies, and we can do it for yours.
Subscribe to:
Posts (Atom)