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.
Subscribe to:
Posts (Atom)