In 2016, we can see the future spread out before us like a sumptuous buffet. The possibilities are endless. We are moving toward that perfect Gene Roddenberry spot in time where we are freed from the drudgery of bolting things together, filling out spreadsheets or even punching a time clock. People will be freed to think and innovate and really come up with exciting and innovative solutions instead of bolting bumpers on Chevys or producing TPS reports.
How is this possible, you ask? Automation. The above-mentioned Chevy isn't bolted together by people anymore, it's produced by robots. Why should Bill Lumbergh be coming by Peter's office saying "We have a problem with the cover sheet on the TPS report" when he should be clicking a button to produce it, the way that Impala is built?
The next logical question is "Why isn't everything being automated?" The answer is complicated. First, the people that can replace entire systems aren't in leadership roles. In society today, either you do stuff, or you manage people who do stuff, but not both. These managers don't have the knowledge sufficient to look at the big picture and produce that one piece of software that does everything. Those days are coming to an end.
Let's take a little example. Our sister company Sentia Health, took a look at the process of health insurance and what precisely could not be done by a machine. You can't replace a doctor with a computer. You can't dig the memory of what the doctor did to any given patient out of his head (there is a visual) and record it for him or her. What you can do is to take that documentation, pull out the procedures and pay for them. That is basically all the insurance company does. The difference is that the traditional insurance company has a cast of thousands with medical coders, adjudicators, and big building and HR departments and generally wastes about 1/3 of your heard earned healthcare dollars. Sentia Health takes those same records with no human intervention and pays for medical treatments in near real time for a small monthly fee of $10 per month. This is about 1/10th of what the average insurance consumer pays his or her insurance company for the same service. That isn't the first, nor even the second industry we have completely automated.
Whether you like it or not, your company or the company you work for is a software company. Either you will get on board with the new way of doing business, or you will be run over by someone who has. David Kirkpatrick of Forbes agrees saying "those who fail to adapt with be obsolete." Joel Basgall says in Entrepreneur Magazine "You Need to Become a Software Company... or Die." That is pretty harsh, and absolutely true.
We've given you quotes from the best minds in the business and an example of something We've actually done. Heck, we have even automated the production of the software we are discussing here so you don't have to pay a fortune to have your business automated. If you've been following along, you've heard that message before. You have the ammunition you need to put your competitors out of business. It's your job to pull the trigger and make the changes. One of those competitors is taking aim at you right now.
Wednesday, October 19, 2016
Wednesday, October 12, 2016
Architecture Frameworks, Handy as a Pocket on a Shirt or As Welcome as a Fly in a Biscuit?
A few years ago, I was talking with a colleague at Duke Energy in Charlotte, NC about what he does on a daily basis as a software architect. He gives me the usual answer about meetings and donuts and drawing boxes. Then, he starts talking about Enterprise Architecture (EA) and how great it is and how I should learn it until basically I asked him for his driver's license to make sure his name wasn't Oral. (Yes, I know he's dead. Too soon? Oral, not the Architect)
I did a little research into what was going on with the various frameworks (EA, DODAF, FEAF, MODAF, TOGAF, Zachman). What I found was, at a high level, they are only good for documentation. EA and TOGAF actually give you some large boxes on where to put your code, but Zachman, DODAF, FEAF and MODAF just show you how to organize your thoughts and plan for the movement and integration of data.
So you framework people are telling me that I need help conceptualizing the solution, not actually designing and building it? No wonder nobody seems to be able to get things done. As a kid, I thought we'd be in the Star Trek Universe by now, where people were freed from the drudgery of work and making a living because the computers were doing all the heavy lifting, freeing us to think and innovate, to solve really interesting problems instead of producing widgets or TPS reports with or without the correct cover sheet. Instead, we have spreadsheets and email and business as usual, the same as it was in 1843, except that Bob Cratchit doesn't have ink stains on his fingers and he can email his spreadsheets to old Ebeneezer instead of hoofing them over. Sometimes they do still hoof them over. We call that SneakerNet. NikeNet if it's a really good network.
So today, I came across Paul Preiss' article "Why Frameworks Are Killing Architecture" and I thought, 'finally,someone who gets it. Paul does get it, kind of. Here are his five reasons he states NOT to use an Architectural Framework:
Build a database that contains all the entities, their attributes and relationships. Design and build a piece of software that looks at this database and builds a middle tier to support Create, Read, Update, Delete and Search (CRUDS (CRUD + Search)) and looking at related data in this database. If we have a database table of students and a database table of classes we need to generate the code to get a list of classes for each student and a list of students given a ClassID automatically. We don't want our developers to write that mundane stuff. Read all about developers a little below. Design and build a tool to generate a User Interface (UI) based on the generated middle tier.
So here is the thing about developers. They are worse than cats and getting them to all run the same direction at the same time and at the same speed is quite a bit more challenging. They are always (collectively) the smartest guy in the room. ...even when they aren't. It is a reputation they earned and are used to so they do what they like usually, and if you don't like it, what they built is better than what you asked for anyway. ...except when it isn't. I gave a group of junior developers a completed database middle tier and part of a user interface (as an example of what I wanted) to complete. After several weeks I demanded to see what they were doing (they didn't want to show unfinished work) and was shocked to find they had not followed instructions but had written an entirely new middle tier and added several tables. needless to say, these developers are no longer drawing paychecks. Just as bad is the fact that nobody, ever wrote an application according to best practices 100% through and through. Worse is when the technology changes or you have to add or update features, you get a new set of developers that don't know and don't care what the former developers did, and will tell you that it's wrong in any case, that the whole thing needs to be scrapped and started from scratch. The only way to adhere to best practices at all times is to generate the code. You have to do it for the developers and let them unleash their creativity on the User Interface. If you have a brain in your head, you simply give them a picture of the UI and tell them to write the HTML, JavaScript and jQuery to get it done.
I did a little research into what was going on with the various frameworks (EA, DODAF, FEAF, MODAF, TOGAF, Zachman). What I found was, at a high level, they are only good for documentation. EA and TOGAF actually give you some large boxes on where to put your code, but Zachman, DODAF, FEAF and MODAF just show you how to organize your thoughts and plan for the movement and integration of data.
So you framework people are telling me that I need help conceptualizing the solution, not actually designing and building it? No wonder nobody seems to be able to get things done. As a kid, I thought we'd be in the Star Trek Universe by now, where people were freed from the drudgery of work and making a living because the computers were doing all the heavy lifting, freeing us to think and innovate, to solve really interesting problems instead of producing widgets or TPS reports with or without the correct cover sheet. Instead, we have spreadsheets and email and business as usual, the same as it was in 1843, except that Bob Cratchit doesn't have ink stains on his fingers and he can email his spreadsheets to old Ebeneezer instead of hoofing them over. Sometimes they do still hoof them over. We call that SneakerNet. NikeNet if it's a really good network.
So today, I came across Paul Preiss' article "Why Frameworks Are Killing Architecture" and I thought, 'finally,someone who gets it. Paul does get it, kind of. Here are his five reasons he states NOT to use an Architectural Framework:
- Frameworks get in the way of innovation
- Frameworks put the focus on deliverable instead of outcome
- Frameworks create poorly skilled architects
- Frameworks make hiring architects more difficult
- Frameworks allow architects to keep 'killing patients'
I've linked to the article so you can research that last one yourself. He then goes on to explain why you should simply change your approach to AFs:
- Move to only working with individuals who a have achieved an experience based certification in architecture
- Optionally pay for the personal development roadmap of your current people, not your future staff
- Measure your architects based on business outcomes
- Start measuring outcomes related to design decisions and share results
Well, you had me at the first five. "Measure architects based on outcomes" is a great thing to do, but the people cutting the checks can't see or understand the design decisions and the reasons that they are made, so that kills the only one that really made any sense, number 4, pay for performance. Which brings me to the conclusion: Either you can write the code, or you can't. If you can't write the code, AFs are a really good way for you to get away with drawing boxes, attending meetings, eating donuts all day and getting nothing accomplished while drawing a paycheck.
If you've been following along, you know that only once have we pointed out a problem without offering a solution. Here is what we replace these Architectural Frameworks with:
- Identify the entities in the Enterprise, like employees, structures, capital assets, processes and everything else
- Identify the attributes of the entities, last name, date of purchase, hours run and everything else
- Identify the relationships between these entities, basically either one to one or one to many.
- Identify the desired outputs such as production reports, P&L, purchases, sales and even tax returns. We will no longer be producing TPS reports, with or without the correct cover sheet.
Build a database that contains all the entities, their attributes and relationships. Design and build a piece of software that looks at this database and builds a middle tier to support Create, Read, Update, Delete and Search (CRUDS (CRUD + Search)) and looking at related data in this database. If we have a database table of students and a database table of classes we need to generate the code to get a list of classes for each student and a list of students given a ClassID automatically. We don't want our developers to write that mundane stuff. Read all about developers a little below. Design and build a tool to generate a User Interface (UI) based on the generated middle tier.
So here is the thing about developers. They are worse than cats and getting them to all run the same direction at the same time and at the same speed is quite a bit more challenging. They are always (collectively) the smartest guy in the room. ...even when they aren't. It is a reputation they earned and are used to so they do what they like usually, and if you don't like it, what they built is better than what you asked for anyway. ...except when it isn't. I gave a group of junior developers a completed database middle tier and part of a user interface (as an example of what I wanted) to complete. After several weeks I demanded to see what they were doing (they didn't want to show unfinished work) and was shocked to find they had not followed instructions but had written an entirely new middle tier and added several tables. needless to say, these developers are no longer drawing paychecks. Just as bad is the fact that nobody, ever wrote an application according to best practices 100% through and through. Worse is when the technology changes or you have to add or update features, you get a new set of developers that don't know and don't care what the former developers did, and will tell you that it's wrong in any case, that the whole thing needs to be scrapped and started from scratch. The only way to adhere to best practices at all times is to generate the code. You have to do it for the developers and let them unleash their creativity on the User Interface. If you have a brain in your head, you simply give them a picture of the UI and tell them to write the HTML, JavaScript and jQuery to get it done.
There are tons of tools out there to generate the middle tier, and I dislike them all. (N)Hibernate and Entity Framework immediately come to mind but I don't like them because they create big, mysterious 'black boxes' that work black magic and might end up in possession of your soul at the end of the contract. You can't see what SQL is getting generated and what it is doing to your database. If you have performance problems, and you will, there is literally no way to solve them. Further, it is a security nightmare since the tables are opened up to the generated SQL they produce. This also opens the tables to hackers and what are called SQL Injection Attacks. We built a tool that uses Stored Procedures exclusively and locks down the tables to anyone who doesn't wear the System Administrator's underwear. Or shave his ugly mug in the morning. That's not mean, I'm the System Administrator. Mostly.
We have a tool to consume our generated middle tier on the desktop and Microsoft was generous enough to build a tool that creates MVC web forms based on the generated Model (middle tier) from above. Given a good database design, we can generate about 80% of a new application. The other 20% is making it pretty and adding visual gewgaws like datepickers and modal dialogs for additional input or information. That part of the development can be handled by a junior developer.
This does a couple of things for us. We have the ability now to generate ONE piece of software to run the enterprise. Think of the traveling salesman problem. As the number of stops increases, the time to come up with the best route increases. As the number of stops approaches infinity, the time to calculate a solution also approaches infinity. Until you generate the solution. That makes the ONE piece of software conceivable and even buildable. Further, since the framework is followed to the letter, this obviates the need for Zachman, DODAF, FEAF and MODAF becuase they are about figuring out where the data sits and integrating it. If we generate the code, we already have a framework that we might describe with the other two, EA and TOGAF, and since everything is done the same way, every time, we need minimal documentation which is really what they are meant to produce. Additionally, if we find later that we made a mistake, or we found a better way to do things, we change the structure of the database or we simply need a new version, we simply reconfigure the code generator and regenerate the middle tier.
Here at Sentia Systems We are moving away from an object oriented (OO) middle tier where adding a member to a collection adds it to the database, to a hybrid OO/Dependency Injection (DI) middle tier where if we want to use DI, we can but otherwise the default OO solution continues to work. When we pull that trigger, we'll regenerate the middle tier and nobody will ever know that they have a completely redesigned and rebuilt middle tier (about 65-70% of the application), it will just continue to work, just with the new DI capabilities.
So yes, Frameworks ARE killing Architecture. If you are a junior guy, you are probably going to use Access or loop through records in Java or make whatever other mistakes junior developers make, but you don't need a framework for that. If you are a senior guy, you don't need the frameworks getting in the way of doing the real heavy lifting of design and development and so some MBA feels better about hiring you to do something he doesn't understand. If you are about producing documentation, reams of paper, to tell you what was done and how it was done, nobody needs you. That stuff isn't even read most of the time, and doing things the exact same way, every time eliminates the need for that anyway.
The conclusion is that frameworks don't add value and they don't write software. They are a solution looking for a problem.
The conclusion is that frameworks don't add value and they don't write software. They are a solution looking for a problem.
Wednesday, October 5, 2016
Today, Mayo Posts "How to Fend Off Phishing Attacks." What About Data Security?
My buddy Bill Siwicki of http://healthcareitnews.com (well, I know him because I've been reading his posts forever. Maybe he will return the favor) posts a softball from the Mayo Clinic titled "Gone phishin': Mayo Clinic shares tips for fending off attacks" detailing how they keep hackers from quite literally hacking users of Health IT software or phishing.
Yes, it's about training and repetition and giving positive feedback when an employee identifies and reports a (fake) phishing attack. We can't help you with that. We are socially awkward geeks, so take Dr. Mark Parkulo's advice on the social side of security. Conspicuous by its absence is what Mayo thinks about security on the data itself. I think that phishing is about a tenth as prevalent as direct attacks because hacking software is what hackers do. Phishing requires the hacker to step outside the shadowy computer world that has definite rules into the social world of people where you have to convince them to do something you want them to do.
So why did Dr. Parkulo and Mayo decide to ignore 90% of cyber security? My guess is that they don't know much about it. Most practices don't. On Dec. 28, 2015, on the same site http://healthcareitnews.com, Bernie Monegain posted a list of the "10 most recent HIPAA breaches" that ALL happened in the first part of December. Even worse, at the bottom of the article there is a slideshow detailing all the big data breaches for 2015 and after that a list of all 1683 known HIPAA data breaches for 2015 according to U.S. Department of Health and Human Services
Office for Civil Rights (OCR).
Clearly Doctors focus on the human side, as they should. I keep crowing about security here, and have stated numerous times that nobody is getting into my database that doesn't shave my face in the morning (barbers don't generally shave me in the morning). I assumed this would taunt hackers into finding some kind of hole they could exploit, but as I suspected, they can't. Our sister company Sentia Health has securely published medical records to the internet in our Software as a Service (SaaS) Electronic Medical Records System (EMR) since 2009 and have never had a breach. Our database uses its very structure to limit the records an authorized user can see to only the ones belonging to patients who call their location primary. There are universal searches as practitioners may need to see records outside of their particular practice but that's only for practitioners with the oddball patient needing attention.
Each time a practitioner (or a patient) logs in he or she is issued a globally unique identifier (GUID) that is unique in the universe and identifies the confluence of that user and that user's session. When the user logs out or gets timed out, that GUID is deleted. The GUID must be supplied for every call to the database and the user is authenticated each time. Even if the User ID and Password were somehow stolen and used to hack into the database, the hacker could only see the names of stored procedures, not even the table names, and wouldn't be able to execute those procedures and/or get any data. I'm tempted to publish the User ID and Password here and let them try. They still won't get anywhere.
As for why Mayo and Dr. Parkulo didn't mention the other 90% of security, it's probably because they have had a couple of data breaches in recent memory as reported by the OCR. Go to the link above (or here), click "Show Advanced Options" and type "Mayo" into "CE / BA Name Search" text box. You'll see what I mean.
I'm positive that if I tried to "doctor" that there would be great gnashing of teeth in the land and I would probably end up in prison. So Doctors, leave the software to us programmers.
Yes, it's about training and repetition and giving positive feedback when an employee identifies and reports a (fake) phishing attack. We can't help you with that. We are socially awkward geeks, so take Dr. Mark Parkulo's advice on the social side of security. Conspicuous by its absence is what Mayo thinks about security on the data itself. I think that phishing is about a tenth as prevalent as direct attacks because hacking software is what hackers do. Phishing requires the hacker to step outside the shadowy computer world that has definite rules into the social world of people where you have to convince them to do something you want them to do.
So why did Dr. Parkulo and Mayo decide to ignore 90% of cyber security? My guess is that they don't know much about it. Most practices don't. On Dec. 28, 2015, on the same site http://healthcareitnews.com, Bernie Monegain posted a list of the "10 most recent HIPAA breaches" that ALL happened in the first part of December. Even worse, at the bottom of the article there is a slideshow detailing all the big data breaches for 2015 and after that a list of all 1683 known HIPAA data breaches for 2015 according to U.S. Department of Health and Human Services
Office for Civil Rights (OCR).
Clearly Doctors focus on the human side, as they should. I keep crowing about security here, and have stated numerous times that nobody is getting into my database that doesn't shave my face in the morning (barbers don't generally shave me in the morning). I assumed this would taunt hackers into finding some kind of hole they could exploit, but as I suspected, they can't. Our sister company Sentia Health has securely published medical records to the internet in our Software as a Service (SaaS) Electronic Medical Records System (EMR) since 2009 and have never had a breach. Our database uses its very structure to limit the records an authorized user can see to only the ones belonging to patients who call their location primary. There are universal searches as practitioners may need to see records outside of their particular practice but that's only for practitioners with the oddball patient needing attention.
Each time a practitioner (or a patient) logs in he or she is issued a globally unique identifier (GUID) that is unique in the universe and identifies the confluence of that user and that user's session. When the user logs out or gets timed out, that GUID is deleted. The GUID must be supplied for every call to the database and the user is authenticated each time. Even if the User ID and Password were somehow stolen and used to hack into the database, the hacker could only see the names of stored procedures, not even the table names, and wouldn't be able to execute those procedures and/or get any data. I'm tempted to publish the User ID and Password here and let them try. They still won't get anywhere.
As for why Mayo and Dr. Parkulo didn't mention the other 90% of security, it's probably because they have had a couple of data breaches in recent memory as reported by the OCR. Go to the link above (or here), click "Show Advanced Options" and type "Mayo" into "CE / BA Name Search" text box. You'll see what I mean.
I'm positive that if I tried to "doctor" that there would be great gnashing of teeth in the land and I would probably end up in prison. So Doctors, leave the software to us programmers.
Subscribe to:
Posts (Atom)