So now I'm creating line of business applications, how do I do this exactly?
April 12, 2009 10:36 AM Subscribe
Help a non-developer get up to speed on creating internal business applications, forms and reports, that interface with an existing small to mid sized business ERP system. I got it sort of working with BizTalk and Sharepoint. I have no formal training, what's the right way to do things? Should I program the logic in the application, the database or some sort of middleware program?
I realize there's not a magic answer to all this, I'm looking for some general guidance. I was previously a business analyst, and often contracted out the heavy technical work, but I had a good understanding of the basics of model view controller, some ideas of object oriented programming and how client-server interactions work.
Whole divisions were cut, so a couple months ago I was handed a laptop with Visual Studio and told we needed to automate some laid off positions. Our "ERP" software runs on a not-SQL database and is very ugly and doesn't do a lot of things. My idea was to create the forms in Infopath in a Sharepoint environment, have them input it into a separate SQL database, and wherever possible inject data via Biztalk to the not-SQL database. So if I wanted to capture in a form, "X, Y, Z" have a work flow for approval in Sharepoint, capture the data and if our current non-SQL database is only setup to accept "Z," inject "Z" into it and keep the rest in the SQL database.
So in theory, I thought, this should work. I actually wrote a few simple test workflows that do what I describe, and everything seems to function, surprisingly, as I would expect it. I mainly use the nice Visual Studio GUI when I can, and plug in code for some advanced workflow things by doing a sort of hen-peck with Google: find an example, adapt it, rinse and repeat.
I feel I'm making good progress, having only an Excel and Visual Basic background in actual programming. I have a gnawing fear that this is absolutely the wrong way to do things, that I'm not normalizing data correctly, my code is a mess, etc. But it does work and I don't expect it to be scalable, the usage is internal and fairly light, but the program does have a fair amount of logic behind it. The company previously had been doing everything by hand, routing approvals and such on paper, which is what these applications try to capture.
Is this the normal way for businesses systems to develop? I always imagined it being very formal and well thought out. Again, as a business analyst I know the processes and what goes in and what comes out, so I'm "just" converting that to code, but I feel way over my head and way over my pay grade.
Are there textbooks I should absolutely be reading? What is what I'm doing called? If the company goes belly up in a year, and I've been working on this, what do I put on a resume? I assume that this a good skill to have and I'm not just wasting my time? I actually find this really fun and challenging, if not feeling completely lost. Oh and this is something that is well compensated, like when things pick up, right? Right?
I realize there's not a magic answer to all this, I'm looking for some general guidance. I was previously a business analyst, and often contracted out the heavy technical work, but I had a good understanding of the basics of model view controller, some ideas of object oriented programming and how client-server interactions work.
Whole divisions were cut, so a couple months ago I was handed a laptop with Visual Studio and told we needed to automate some laid off positions. Our "ERP" software runs on a not-SQL database and is very ugly and doesn't do a lot of things. My idea was to create the forms in Infopath in a Sharepoint environment, have them input it into a separate SQL database, and wherever possible inject data via Biztalk to the not-SQL database. So if I wanted to capture in a form, "X, Y, Z" have a work flow for approval in Sharepoint, capture the data and if our current non-SQL database is only setup to accept "Z," inject "Z" into it and keep the rest in the SQL database.
So in theory, I thought, this should work. I actually wrote a few simple test workflows that do what I describe, and everything seems to function, surprisingly, as I would expect it. I mainly use the nice Visual Studio GUI when I can, and plug in code for some advanced workflow things by doing a sort of hen-peck with Google: find an example, adapt it, rinse and repeat.
I feel I'm making good progress, having only an Excel and Visual Basic background in actual programming. I have a gnawing fear that this is absolutely the wrong way to do things, that I'm not normalizing data correctly, my code is a mess, etc. But it does work and I don't expect it to be scalable, the usage is internal and fairly light, but the program does have a fair amount of logic behind it. The company previously had been doing everything by hand, routing approvals and such on paper, which is what these applications try to capture.
Is this the normal way for businesses systems to develop? I always imagined it being very formal and well thought out. Again, as a business analyst I know the processes and what goes in and what comes out, so I'm "just" converting that to code, but I feel way over my head and way over my pay grade.
Are there textbooks I should absolutely be reading? What is what I'm doing called? If the company goes belly up in a year, and I've been working on this, what do I put on a resume? I assume that this a good skill to have and I'm not just wasting my time? I actually find this really fun and challenging, if not feeling completely lost. Oh and this is something that is well compensated, like when things pick up, right? Right?
Should I program the logic in the application, the database or some sort of middleware program?
The logic needs to reside in the database so they can enforce business rules across applications. This way you're not duplicating code across systems (which risks higher maintenance and errors).
and wherever possible inject data via Biztalk to the not-SQL database
Obviously a lot of answers depend on how you're using the data, but I personally would rather migrate data from the non-SQL datastore to the "real" database than the other way around (unless you have to for some reason). There are a ton of advantages to keeping your data in a standard, queryable system rather than keeping it in the legacy code.
I have a gnawing fear that this is absolutely the wrong way to do things, that I'm not normalizing data correctly, my code is a mess, etc.
No way of knowing that without seeing the schema. Just keep your tables clean and single-purposed, don't duplicate data you don't have to, and always, always, always use a non-natural primary key (e.g., SSN is not a good primary key even though they might appear unique… they're only unique if you have one).
What is what I'm doing called? If the company goes belly up in a year, and I've been working on this, what do I put on a resume?
I would call you a Data Architect.
posted by Civil_Disobedient at 11:08 AM on April 12, 2009
The logic needs to reside in the database so they can enforce business rules across applications. This way you're not duplicating code across systems (which risks higher maintenance and errors).
and wherever possible inject data via Biztalk to the not-SQL database
Obviously a lot of answers depend on how you're using the data, but I personally would rather migrate data from the non-SQL datastore to the "real" database than the other way around (unless you have to for some reason). There are a ton of advantages to keeping your data in a standard, queryable system rather than keeping it in the legacy code.
I have a gnawing fear that this is absolutely the wrong way to do things, that I'm not normalizing data correctly, my code is a mess, etc.
No way of knowing that without seeing the schema. Just keep your tables clean and single-purposed, don't duplicate data you don't have to, and always, always, always use a non-natural primary key (e.g., SSN is not a good primary key even though they might appear unique… they're only unique if you have one).
What is what I'm doing called? If the company goes belly up in a year, and I've been working on this, what do I put on a resume?
I would call you a Data Architect.
posted by Civil_Disobedient at 11:08 AM on April 12, 2009
Oh, also…
I assume that this a good skill to have and I'm not just wasting my time?
Yes, it's an extremely good skill to have provided you know what you're doing. You'll know you're doing it right by the amount of times you have to rewrite it to take on some "new feature" the business wants. Well-planned systems (in general) don't require total re-writes. :)
Oh and this is something that is well compensated, like when things pick up, right? Right?
You are essentially creating the systems and structures that the entire company runs off. Any time you have the responsibility and potential of severely screwing up (or helping out) a company's bottom-line, you're generally remunerated for your efforts.
posted by Civil_Disobedient at 11:21 AM on April 12, 2009
I assume that this a good skill to have and I'm not just wasting my time?
Yes, it's an extremely good skill to have provided you know what you're doing. You'll know you're doing it right by the amount of times you have to rewrite it to take on some "new feature" the business wants. Well-planned systems (in general) don't require total re-writes. :)
Oh and this is something that is well compensated, like when things pick up, right? Right?
You are essentially creating the systems and structures that the entire company runs off. Any time you have the responsibility and potential of severely screwing up (or helping out) a company's bottom-line, you're generally remunerated for your efforts.
posted by Civil_Disobedient at 11:21 AM on April 12, 2009
Is this the normal way for businesses systems to develop? I always imagined it being very formal and well thought out.
This is a very common scenario, especially in cases where the business is not able to hire (or retain) staff with the appropriate formal training and experience. On the plus side, it sounds like you are delivering required functionality, which means you haven't let yourself get too paralyzed by what you don't know. Recognize that it's going to take a while for you to pick up programming skills and experience — it's one thing to have a analysts' understanding of MVP or OO design, another to implement a system.
Oh and this is something that is well compensated, like when things pick up, right?
At the very least, the programming experience you gain should make you a better business analyst since you'll get a better understanding of what the technical folks have to do when implementing your specs. If the ERP is in common use, you may be able to get consulting gigs customizing it, and the ability to learn new skills and glue together separate systems (integration, since you're looking for a word) is valuable in its own right.
Besides the manuals specific to coding with SharePoint and Visual Studio, I recommend the book Code Complete. If you haven't already, start using source control, and make sure that you spend the time to program mindfully and document your decisions — the programmer you help with those notes six months from now may well be yourself.
posted by metaquarry at 11:36 AM on April 12, 2009 [1 favorite]
This is a very common scenario, especially in cases where the business is not able to hire (or retain) staff with the appropriate formal training and experience. On the plus side, it sounds like you are delivering required functionality, which means you haven't let yourself get too paralyzed by what you don't know. Recognize that it's going to take a while for you to pick up programming skills and experience — it's one thing to have a analysts' understanding of MVP or OO design, another to implement a system.
Oh and this is something that is well compensated, like when things pick up, right?
At the very least, the programming experience you gain should make you a better business analyst since you'll get a better understanding of what the technical folks have to do when implementing your specs. If the ERP is in common use, you may be able to get consulting gigs customizing it, and the ability to learn new skills and glue together separate systems (integration, since you're looking for a word) is valuable in its own right.
Besides the manuals specific to coding with SharePoint and Visual Studio, I recommend the book Code Complete. If you haven't already, start using source control, and make sure that you spend the time to program mindfully and document your decisions — the programmer you help with those notes six months from now may well be yourself.
posted by metaquarry at 11:36 AM on April 12, 2009 [1 favorite]
Also, is there anybody left at your employer who can give you technical and programming process advice? Even if you're the only one working on this project, it's a good idea to find a mentor.
posted by metaquarry at 11:39 AM on April 12, 2009
posted by metaquarry at 11:39 AM on April 12, 2009
One thing you might want to look at, you can create fairly complex workflows without any coding using Sharepoint Designer. You've already started down the road of using Visual Studio to code your own, but I'd take a look at at this option as it is one less thing to have to maintain.
posted by Eddie Mars at 3:10 PM on April 12, 2009
posted by Eddie Mars at 3:10 PM on April 12, 2009
This thread is closed to new comments.
Sadly, yes. Few businesses have the self-awareness and the internal fortitude to take full responsibility for developing their own business systems correctly, meaning hiring real programmers and architects to develop the internal equivalent of what they'd pay six or seven figures for to an ERP vendor. You're in the worst of all possible worlds, patching together critical systems from twine and duct tape, but you can be comforted that you're not alone.
The best thing you can do is to actually read the documentation on the technologies you're using so that you start to understand what's going on under the hood. For general coding practices, get Code Complete. For database theory, I found O'Reilly's book on T-SQL to be very informative in a practical context.
Overall, you should be investing time in learning what's going on inside what you're doing. Patching together X with Y with Z, all through helpful wizards, is building a house of cards that will likely fail catastrophically one day.
posted by fatbird at 11:08 AM on April 12, 2009