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.
No comments:
Post a Comment