Nobody likes Walmart. They are who they are, however, for several good reasons: purchasing power, warehousing, distribution, marketing, merchandising and most importantly, because it makes the rest of the enterprise go, financing. They have just about killed any small business who used to compete with them with these very powerful tools.
But with today's technology, cloud based applications Infrastructure as a Service (IaaS), Platform as a Service (PaaS) and Software as a Service (SaaS), smaller businesses can compete on a more level playing field with the giants of industry.
Because you only pay for what you use or pay a subscription fee, Sentia can write enterprise software for dozens or hundreds of (or thousands or millions or all of them) small businesses, to give them even better capabilities than their huge competitors, on things that software can automate. This gives mom and pop business owners the ability to do what they do best: providing great products and great services.
While its true that the solution will be a one size fits all, business is a one size fits all kind of endeavor. Every one fills out the same tax return has the same generally accepted accounting principles, has fixed and variable costs, capitalized equipment, sales and so on. what we foresee doing is providing all the tools to manage a small business in an enterprise kind of way, but at a low cost.
This doesn't, however, give a small business the purchasing power, distribution, marketing and other abilities that the large business possess. Once we have several business using Sentia's software we can leverage the power of numbers and start providing more and more services, like these, to our members. We can purchase warehouse and distribution center space for our members. We can eventually provide logistical and delivery support. We can offer a captive insurance company that provides health insurance for a company's employees, and we can do all this collectively, and we can do it with even more power than the Walmarts of the world, because collectively we are far larger.
It isn't just about what Sentia can do either. Once our members start using each other exclusively, costs plummet. Maybe Molly's Bakery needs a sign that Joe's Sign Company can produce. Maybe Joe keeps his sign creating materials in the same warehouse that Molly keeps her bulk baking supplies. We can automatically send the materials for making a new sign to Molly's shop with Molly's next flour delivery. Joe makes more money because his costs are lower since he warehoused and shipped his materials with Molly's, and he can pass that savings on to Molly. In the end, everyone wins. Molly's customers get great cupcakes at an affordable price, Joe makes more money than ever through built in marketing in the "collective" and the corporate, faceless Walmarts of the world get left out in the cold.
All we need is a great software company to design and build the applications that do all this for us and coordinate the management of everything. I just happen to know a likely suspect.
The only thing we are missing is a snappy name. How about "Everything as a Service (XaaS)?"
Wednesday, April 12, 2017
Monday, January 16, 2017
The Power of Any Application is in the Database
If you've been following along, you recognize that most of what we do here at Sentia is healthcare related due to having a sister company in the healthcare sphere: Sentia Health. Last Thursday's post "One Application to Rule Them All"was the exception that proves the rule. We examined Sentia's Object Relational Mapper (ORM) and why it is different and better, but not really the underlying philosophy behind it. Today, we are going to examine that philosophy.
There are only two kinds of code that get written: Procedural and Set-Based. All of your "Hello World" programs and your "for each" and "i+=1" (or "i=i+1") and Object Oriented (OO) and 95% of everything you have been taught is procedural. It is a "put this value in this variable and loop this many times" kind of thing. Java, in all of its various flavors is probably the world's most popular language. It doesn't even guarantee a database at all, and there are hundreds of ways to "get around" the need for a database, making Set-Based programming that much more rare. Set based code, however, doesn't (and shouldn't) work this way. Set based code says "give me a filter and let me dump all the data through it and whatever is left is a match."
Here is a metaphor we have used before. Your Drill Instructor orders you to 'get him a rock.' Having heard this story before and knowing that things will go more easily if you ask a few question, you ask "what kind of rock?" He states he needs a rock about the size of a quarter, Amy kind of material will work, but it is the over all size that matters, but he needs as many that match the criteria as you can find.
If you use a procedural methodology, you go grab a bag, a quarter and a pair of tweezers and you start picking up every rock you can find. If the rock is about the size of a quarter, put it in the bag. Sounds like it will work, but it isn't very efficient. Set-Based coding is far more efficient. being a smart guy you find a couple of pieces of plywood and drill holes in both; one a little larger and one a little smaller than your proverbial quarter. You then dump all the rocks through the larger filter filtering out the larger rocks, then you dump the tailings through the smaller filter and what is left fit the requirements.
Your goal as a developer is to write as much of the code for your new application in Set-Based code as possible. Another way to say this is 'as little procedural code as possible.' At that point the procedural code simply becomes an object oriented representation of your database, and therefore, you don't need nearly as much of it.
Yes, trips to the database are expensive. When you have lookup data that doesn't change often,you should probably figure out a scheme to cache it in memory on the web server, so you only have to go to the database once, or at least infrequently. These kinds of lookup values are things like color, or gender. (In 2017, gender might be more fluid than we initially thought, though)
There are some special database considerations. Your database should be additive. That means that you don't update records, you add new records. You don't delete records. Deletes are amazingly expensive and an update is merely a delete and reinsert. You should have separate tables for lookup values. See discussion above about caching. You should institute a primary key that has no intrinsic value. you should never show that primary key to anyone, particularly the user lest s/he assign it an intrinsic value. I use an integer datatype, you can make an argument for GUIDs. You should enforce data constraints to describe the relationships between the various tables (entities) in your database. You should add a foreign key to the many side of a one to many relationship and enforce the constraint between it and its primary parent.
Document storage databases, like NoSQL, are becoming increasingly popular. Don't use them. Instead save the document in the database itself as a Binary Large Object (BLOB) or on the file system with a pointer in the database back to the document. Store the metadata, maybe including the text of the document itself, in the database for fast, reliable retrieval.
Big Data is a buzzword used to clean the pockets of those who don't understand relational databases. Hadoop and Map Reduce both use procedural languages to loop through (like your private with a quarter and a pair of tweezers above) 'unstructured' data and pick out what is necessary. Instead, we should structure that data, and use our tried and true Set-Based programming language on it. While structuring the data will take about the same amount of time as running that first Hadoop query, the second will run orders of magnitude faster and you won't have to go buy an entire infrastructure to support "Big Data." Actually, there is no unstructured data, just data that hasn't been structured yet, and therefore there is no such thing as "Big Data."
So now that we have reduced the procedural needs of our application down to simply representing the database in a way that our user interface can understand and manipulate, we have gained the ability to generate all the code necessary for a new application given only a solid database design. We know this is true, because we have done it. We have developers who single-handedly are pumping out two completed applications every week. This is so fast and inexpensive that we are generating prototypes for our clients to log in and use free of charge. Then, and only then, do we start doing the deep dive on requirements gathering, since the client has a baseline of what's possible and in what amount of time, and scope creep literally goes away.
So yes, Virginia, this is true. We have this tool. It works and it works better than your Entity Framework, nHibernate, LINQ, or whatever else you are using. It is more secure than anything else on the market and that security is built in, and that means generated.
This is the future of software. You can call it AI if you like, but it isn't. Yes, you give it different inputs and it gives you different answers, but AI (and machine learning and deep learning)doesn't truly, and may never exist.
In conclusion, we've shown you why the database-centric approach is the best. We've demonstrated why very few use the database-centric approach. We've shown why Relational Database Management Systems (RDBMSs) are superior to document-based or "Big Data" approaches. We've shown that we alone have the ability to generate applications based on good database design.
If you go back to our article on Thursday, that we mentioned above, maybe it will make more sense in light of this explanation.
Maybe you should give us a call.
There are only two kinds of code that get written: Procedural and Set-Based. All of your "Hello World" programs and your "for each" and "i+=1" (or "i=i+1") and Object Oriented (OO) and 95% of everything you have been taught is procedural. It is a "put this value in this variable and loop this many times" kind of thing. Java, in all of its various flavors is probably the world's most popular language. It doesn't even guarantee a database at all, and there are hundreds of ways to "get around" the need for a database, making Set-Based programming that much more rare. Set based code, however, doesn't (and shouldn't) work this way. Set based code says "give me a filter and let me dump all the data through it and whatever is left is a match."
Here is a metaphor we have used before. Your Drill Instructor orders you to 'get him a rock.' Having heard this story before and knowing that things will go more easily if you ask a few question, you ask "what kind of rock?" He states he needs a rock about the size of a quarter, Amy kind of material will work, but it is the over all size that matters, but he needs as many that match the criteria as you can find.
If you use a procedural methodology, you go grab a bag, a quarter and a pair of tweezers and you start picking up every rock you can find. If the rock is about the size of a quarter, put it in the bag. Sounds like it will work, but it isn't very efficient. Set-Based coding is far more efficient. being a smart guy you find a couple of pieces of plywood and drill holes in both; one a little larger and one a little smaller than your proverbial quarter. You then dump all the rocks through the larger filter filtering out the larger rocks, then you dump the tailings through the smaller filter and what is left fit the requirements.
Your goal as a developer is to write as much of the code for your new application in Set-Based code as possible. Another way to say this is 'as little procedural code as possible.' At that point the procedural code simply becomes an object oriented representation of your database, and therefore, you don't need nearly as much of it.
Yes, trips to the database are expensive. When you have lookup data that doesn't change often,you should probably figure out a scheme to cache it in memory on the web server, so you only have to go to the database once, or at least infrequently. These kinds of lookup values are things like color, or gender. (In 2017, gender might be more fluid than we initially thought, though)
There are some special database considerations. Your database should be additive. That means that you don't update records, you add new records. You don't delete records. Deletes are amazingly expensive and an update is merely a delete and reinsert. You should have separate tables for lookup values. See discussion above about caching. You should institute a primary key that has no intrinsic value. you should never show that primary key to anyone, particularly the user lest s/he assign it an intrinsic value. I use an integer datatype, you can make an argument for GUIDs. You should enforce data constraints to describe the relationships between the various tables (entities) in your database. You should add a foreign key to the many side of a one to many relationship and enforce the constraint between it and its primary parent.
Document storage databases, like NoSQL, are becoming increasingly popular. Don't use them. Instead save the document in the database itself as a Binary Large Object (BLOB) or on the file system with a pointer in the database back to the document. Store the metadata, maybe including the text of the document itself, in the database for fast, reliable retrieval.
Big Data is a buzzword used to clean the pockets of those who don't understand relational databases. Hadoop and Map Reduce both use procedural languages to loop through (like your private with a quarter and a pair of tweezers above) 'unstructured' data and pick out what is necessary. Instead, we should structure that data, and use our tried and true Set-Based programming language on it. While structuring the data will take about the same amount of time as running that first Hadoop query, the second will run orders of magnitude faster and you won't have to go buy an entire infrastructure to support "Big Data." Actually, there is no unstructured data, just data that hasn't been structured yet, and therefore there is no such thing as "Big Data."
So now that we have reduced the procedural needs of our application down to simply representing the database in a way that our user interface can understand and manipulate, we have gained the ability to generate all the code necessary for a new application given only a solid database design. We know this is true, because we have done it. We have developers who single-handedly are pumping out two completed applications every week. This is so fast and inexpensive that we are generating prototypes for our clients to log in and use free of charge. Then, and only then, do we start doing the deep dive on requirements gathering, since the client has a baseline of what's possible and in what amount of time, and scope creep literally goes away.
So yes, Virginia, this is true. We have this tool. It works and it works better than your Entity Framework, nHibernate, LINQ, or whatever else you are using. It is more secure than anything else on the market and that security is built in, and that means generated.
This is the future of software. You can call it AI if you like, but it isn't. Yes, you give it different inputs and it gives you different answers, but AI (and machine learning and deep learning)doesn't truly, and may never exist.
In conclusion, we've shown you why the database-centric approach is the best. We've demonstrated why very few use the database-centric approach. We've shown why Relational Database Management Systems (RDBMSs) are superior to document-based or "Big Data" approaches. We've shown that we alone have the ability to generate applications based on good database design.
If you go back to our article on Thursday, that we mentioned above, maybe it will make more sense in light of this explanation.
Maybe you should give us a call.
Thursday, January 12, 2017
One Application to Rule Them All: Automating Software Production
In the business world today, there are two ways to do things: put all your data on spreadsheets and email them around to the various departments (manufacturing, human resources, accounting, warehousing, etc.), or buy a bunch of proprietary software for each department and then struggle to integrate and secure that software. There is some custom development, but it suffers from the same problem that buying software does, difficulties in integrating and securing it. Today, we are going to look at why this is a problem and offer a methodical replacement for these two systems of running your business.
The replacement is to have one application custom designed for your business that automates as much as possible of what you do, reports on it automatically, has one repository for security and doesn't require integration because it is already integrated.
Architectural Frameworks are all the rage. If you go to Dice.com you will find that ~90% of the Technical Architect jobs require either TOGAF or EA. These frameworks define their vision for building software correctly. That vision may or may not mesh with yours and it's like explaining to a Mechanical Engineer how a car works. The explanation doesn't get the car designed nor built. Worse, unlike the machinists who actually build the car parts in this simile, the developers don't (and won't) adhere to the Architect's standards. That means that the $150,000 per year you spent on hiring a Technical Architect was completely wasted.
So if we are going to build this one application that does everything, we need something bigger than a framework or guidelines. Here at Sentia we developed a code generation tool that takes a well designed database and spits out the code that the the Technical Architect would have produced in a perfect world. Then, because there is an aesthetic component of User Interface (UI) design, the developers can generate forms either for the web or the desktop using another tool we developed that is ugly, but modifiable. The developers take these generated forms and make them pretty, according to the business requirements.
This gives us the ability to solve problems, save money and automate processes in a better way than has been possible and in a time frame that is acceptable to your business. Below, we are going to compare and contrast the traditional with this new way of doing things
Security is, of course, the biggest problem. Companies use several ways to secure applications and they are all cumbersome, expensive and difficult to use. Enterprise Service Bus (ESB) and oAuth come to mind. ESB actually brokers requests based on your network login, granting or denying access to applications. oAuth uses a central repository (think Facebook or Google) to manage your username and password and grant access to applications based on that externally defined data-store. All that is great, but that just authenticates the user. That doesn't tell the installed, third party application what the user is allowed to see or do in the application. The only other way to manage security is to have dozens or hundreds of passwords, one for each application which is a security and administrative nightmare. You know that someone is going to write down a password on a sticky and attach it to his or her monitor.
If your business has dozens or hundreds of installed applications, you have dozens or hundreds of expansive employees sitting around reading from a spreadsheet and entering the data it contains into the installed application. Think about your accounting team. They get dozens of spreadsheets everyday and have to manually enter them into your accounting system. Yes, we know that you are smarter than that. you hired Accenture or Deloiite or Capgemini to come in and integrate your systems. So you spent millions on the original software packages, then spent millions more integrating them and still don't have all the data you need. What happens when someone convinces you to switch from Open Systems Traverse to Microsoft Dynamics GP? You have to do that work all over again. If you followed our paradigm, you would have only what you needed, not a bunch of features you will never use, and you could modify it at will to fit your ever changing business needs. Since all the data is in one application, you would never have to integrate anything ever again. Even better, when we discover a better way to do things, we can simply regenerate your software to take advantage of any new trends in the industry. We just did this and added dependency injection to our software to automate unit testing.
"But," you say, "we already develop our own software." Well, maybe. You still have to integrate it and i guarantee that nobody is looking at the code line by line to make sure that the developers are sticking to the 'blueprints.' They don't. It is worse than herding cats. Even worse, you still have all the security and integration problems. Even worse than that, You now have a hodgepodge of technologies: open source, Java, Spring, .NET Oracle, SQL Server, MySQL, Python, Perl, Apache, IIS, ad nauseum. You need multiple teams to write the code and them multiple environments to run it. All this is worth a ton of time and money. We use ONE set of technologies, Microsoft, and we generate about 80% of the code and the other 20% is mostly just making it pretty. In fact, almost everything that we write today is hosted in the cloud, so all you need are a bunch of cheap machines/tablets and some kind of internet connection. No server room, no data center, no muss, no fuss.
How does this compare to any of the Object Relational Mappers (ORMs) that are available today? We generate real code that could have been written by a real developer, if s/he never got lazy and always adhered to best practices and your particular Architectural Framework. Your development team can go look at the generated code and have a guide to how to extend it in the case that we need something that wasn't generated. We can't see everything ahead of time. Entity Framework, nHibernate, LINQ to SQL, all of the other ORMs I have ever seen work like black boxes. you get what you get and if you don't like it, tough. You can't modify it and you can't even see the code. Speaking of code, you can trap the Structured Query Language (SQL) used to manipulate the data from your database. These other ORMs generate their SQL on the fly and it is not pretty nor readable. Ours produces Stored Procedures, just like a your Technical Architect designed and just like the other code, it is visible, readable and can be used as a how-to template. That brings up another problem. The other ORMs generate their SQL on the fly and therefore must have access to the table structure in the database. That is a huge security risk. Our tables are locked down so that only the System Administrator and the Stored Procedures can access them, protecting you against a SQL Injection Attack.
With this level of integration you now have the ability to automate processes. We have completely automated a few service businesses and one of our sister companies, Sentia Health is in the process of automating the entire health insurance industry by giving doctors a free Electronic Health Records (EHR) system that will pay them in real time for procedures performed on one of our insureds, with no human intervention. No medical coding, no claim adjudication, no billing, no muss, no fuss. We suspect that this will cut at least 45% of the cost of healthcare without affecting payments to practitioners or practices at all. Maybe you should contact us before you go the way of BCBS, Aetna, or United Health.
Today we've shown a better way to run your business. We've shown the opportunity to automate many aspects of your business, avoid the security nightmare of spreadsheets and hundreds of expensive applications, avoid the pitfall of multiple development teams, recoup the cost of your servers, data centers and most of your infrastructure. If you don't, someone in your industry will either do things this way, or call us to do it for them. They will put you out of business. Maybe you should put them out of business first.
The replacement is to have one application custom designed for your business that automates as much as possible of what you do, reports on it automatically, has one repository for security and doesn't require integration because it is already integrated.
Architectural Frameworks are all the rage. If you go to Dice.com you will find that ~90% of the Technical Architect jobs require either TOGAF or EA. These frameworks define their vision for building software correctly. That vision may or may not mesh with yours and it's like explaining to a Mechanical Engineer how a car works. The explanation doesn't get the car designed nor built. Worse, unlike the machinists who actually build the car parts in this simile, the developers don't (and won't) adhere to the Architect's standards. That means that the $150,000 per year you spent on hiring a Technical Architect was completely wasted.
So if we are going to build this one application that does everything, we need something bigger than a framework or guidelines. Here at Sentia we developed a code generation tool that takes a well designed database and spits out the code that the the Technical Architect would have produced in a perfect world. Then, because there is an aesthetic component of User Interface (UI) design, the developers can generate forms either for the web or the desktop using another tool we developed that is ugly, but modifiable. The developers take these generated forms and make them pretty, according to the business requirements.
This gives us the ability to solve problems, save money and automate processes in a better way than has been possible and in a time frame that is acceptable to your business. Below, we are going to compare and contrast the traditional with this new way of doing things
Security is, of course, the biggest problem. Companies use several ways to secure applications and they are all cumbersome, expensive and difficult to use. Enterprise Service Bus (ESB) and oAuth come to mind. ESB actually brokers requests based on your network login, granting or denying access to applications. oAuth uses a central repository (think Facebook or Google) to manage your username and password and grant access to applications based on that externally defined data-store. All that is great, but that just authenticates the user. That doesn't tell the installed, third party application what the user is allowed to see or do in the application. The only other way to manage security is to have dozens or hundreds of passwords, one for each application which is a security and administrative nightmare. You know that someone is going to write down a password on a sticky and attach it to his or her monitor.
If your business has dozens or hundreds of installed applications, you have dozens or hundreds of expansive employees sitting around reading from a spreadsheet and entering the data it contains into the installed application. Think about your accounting team. They get dozens of spreadsheets everyday and have to manually enter them into your accounting system. Yes, we know that you are smarter than that. you hired Accenture or Deloiite or Capgemini to come in and integrate your systems. So you spent millions on the original software packages, then spent millions more integrating them and still don't have all the data you need. What happens when someone convinces you to switch from Open Systems Traverse to Microsoft Dynamics GP? You have to do that work all over again. If you followed our paradigm, you would have only what you needed, not a bunch of features you will never use, and you could modify it at will to fit your ever changing business needs. Since all the data is in one application, you would never have to integrate anything ever again. Even better, when we discover a better way to do things, we can simply regenerate your software to take advantage of any new trends in the industry. We just did this and added dependency injection to our software to automate unit testing.
"But," you say, "we already develop our own software." Well, maybe. You still have to integrate it and i guarantee that nobody is looking at the code line by line to make sure that the developers are sticking to the 'blueprints.' They don't. It is worse than herding cats. Even worse, you still have all the security and integration problems. Even worse than that, You now have a hodgepodge of technologies: open source, Java, Spring, .NET Oracle, SQL Server, MySQL, Python, Perl, Apache, IIS, ad nauseum. You need multiple teams to write the code and them multiple environments to run it. All this is worth a ton of time and money. We use ONE set of technologies, Microsoft, and we generate about 80% of the code and the other 20% is mostly just making it pretty. In fact, almost everything that we write today is hosted in the cloud, so all you need are a bunch of cheap machines/tablets and some kind of internet connection. No server room, no data center, no muss, no fuss.
How does this compare to any of the Object Relational Mappers (ORMs) that are available today? We generate real code that could have been written by a real developer, if s/he never got lazy and always adhered to best practices and your particular Architectural Framework. Your development team can go look at the generated code and have a guide to how to extend it in the case that we need something that wasn't generated. We can't see everything ahead of time. Entity Framework, nHibernate, LINQ to SQL, all of the other ORMs I have ever seen work like black boxes. you get what you get and if you don't like it, tough. You can't modify it and you can't even see the code. Speaking of code, you can trap the Structured Query Language (SQL) used to manipulate the data from your database. These other ORMs generate their SQL on the fly and it is not pretty nor readable. Ours produces Stored Procedures, just like a your Technical Architect designed and just like the other code, it is visible, readable and can be used as a how-to template. That brings up another problem. The other ORMs generate their SQL on the fly and therefore must have access to the table structure in the database. That is a huge security risk. Our tables are locked down so that only the System Administrator and the Stored Procedures can access them, protecting you against a SQL Injection Attack.
With this level of integration you now have the ability to automate processes. We have completely automated a few service businesses and one of our sister companies, Sentia Health is in the process of automating the entire health insurance industry by giving doctors a free Electronic Health Records (EHR) system that will pay them in real time for procedures performed on one of our insureds, with no human intervention. No medical coding, no claim adjudication, no billing, no muss, no fuss. We suspect that this will cut at least 45% of the cost of healthcare without affecting payments to practitioners or practices at all. Maybe you should contact us before you go the way of BCBS, Aetna, or United Health.
Today we've shown a better way to run your business. We've shown the opportunity to automate many aspects of your business, avoid the security nightmare of spreadsheets and hundreds of expensive applications, avoid the pitfall of multiple development teams, recoup the cost of your servers, data centers and most of your infrastructure. If you don't, someone in your industry will either do things this way, or call us to do it for them. They will put you out of business. Maybe you should put them out of business first.
Wednesday, October 19, 2016
Every Company is a Software Company
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.
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 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.
Subscribe to:
Posts (Atom)