August 13, 2014 at 8:40 am
Using the MS SQL Server, MS Office, and MS VisualStudio stack, you can build practically any IT solution, and it integrates well. Often times the tools will integrate, but the missing link is the limited skillset of the developers themseleves.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 13, 2014 at 8:40 am
Funny thing is for some view points MS SQL Server is a "rule them all" system.
(and let's not forgot that good tools integrated to it like red gate) 😀
The fact is a monolithic system ill not adehere to all different business rules from all different companies even if we are considering a small market subset.
That companies are different, work in a different way, got different process, mothods, budgets, etc
Even considering a single company the scenario changes when the company evolves year after year.
In that way I agree with the customized solution tailored for that company (in that point in time).
Off course there are good generic solutions for good generic problems.
And yes sometimes no ones wants the burden to build and maintain a dashboard application with good reasons
August 13, 2014 at 8:47 am
I think a lot of focus has been placed on the software/solution/product/magic bullet here and not enough on the teams architecting requirements and architecting a solution. I find a lot of clients want the "off the shelf system that meets all my current requirements exactly as I see them" and in a lot of cases that means something that does what they had made their previous systems do. This leads to a lot of complexity and no one on the customer's side wants to take a step back and ask if those requirements truly are necessary.
Then if they are necessary do they need to be met exactly the way originally defined - I've had to build the "easy" button that does 4 things at once because it was too difficult for them to make someone push 4 buttons. If the client could tolerate their users using their brains and doing a small bit of work (or maybe following a process) than the system could be less complicated, require less development and be easier to maintain. Basically clients that can tolerate small tweaks to requirements or processes so as to make the actual solution less technically complicated or simpler get better results.
However as this was for large bureaucratic organization I would suspect (based on my experiences) that there were a lot of requirements that got very detailed, very complicated, just so people could cover their ***, but bloated the complexity. If those dictating the requirements can't see they're shooting themselves in the foot like that, and their consultants don't help them to pull back...well they were probably going to go over budget or have problems even before things got started.
August 13, 2014 at 8:48 am
I'm not saying that the Microsoft development stack should be used for building the Air Force's mission critical systems (ie: deployed in the field in Iraq). A strong an compelling argument for open source development tools can be made in this situation, even if the tools require additional man hours and skillsets to integrate.
However, if what they're looking for is an application and database to crunch accounting numbers and a BI solution to display pretty charts and reports for Congress, then nothing beats Microsoft.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
August 13, 2014 at 8:57 am
Love how this is blamed on the Air Force instead of Oracle. We did a Y2K project with Oracle for a small company relative to this project,
and had the identical experience. I then spent 3 years working for a 3rd party provider that made their living providing reporting solutions to Oracle customers that couldn't get their reporting needs met 'out-of-the-box', as they were told. I went to work for them off of my own experience with Oracle. The most oversold, over-represented software out there. The money that has rolled into their coffers for no value delivered, it boggles the mind.
August 13, 2014 at 9:05 am
jrlandeen (8/13/2014)
Then if they are necessary do they need to be met exactly the way originally defined - I've had to build the "easy" button that does 4 things at once because it was too difficult for them to make someone push 4 buttons.
OMG!! You've done work for some of our clients too haven't you! LOL :laugh:
August 13, 2014 at 9:37 am
The "easy" button idea of making it easier for our users to not do their jobs frustrates me to no end. I usually have to do this because users want to be lazy, but usually this is where we need the users the most. Computers are NOT good at making complex decisions, that's what humans are for...deciding whether the order "looks" right or is setup properly can require a lot of complicated decision logic and knowledge that a human has readily available.
Computers ARE good at executing simple, easily defined, repetitive tasks. So when a user wants a complicated task automated to an "easy" button it means they're going to spend lots of time (i.e. money) getting that developed....and then they don't have to do anything anymore (i.e. they're now a surplus employee). Unfortunately then the fallout is it's now a complicated process and maintaining it is more money/time...which leads to the uncomfortable discussion of why does the upgrade/maintenance support cost so much? Answer: because you made us build the complicated "easy" button we advised you against.
August 13, 2014 at 9:40 am
Steve Jones asks:
Are we better off choosing specialized systems and planning on development efforts to integrate information together?
Yes. This is now the situation in my development shop, which supports a business with annual revenues of about a quarter billion dollars.
Once upon a time, though, IT shops had many designers and developers who wrote large bespoke systems. The systems usually worked well, in part because they reflected the specific needs of the business at hand. But they were expensive to develop, and sometimes challenging to maintain as developers came and went.
The pendulum swung to reducing the cost of maintaining a stable of applications designers and developers, and instead buying large commercial software offerings. Unfortunately, these purchased systems were often too inflexible to configure to specific business needs, and costly for the vendor to modify.
The latest trend - and I think it's a good one - is for small, specialised commercial systems to allow in-house IT staff a degree of configuration and integration (usually via web services). Designers and developers have returned - in smaller numbers than in days of yore - and their task has changed, from creating systems out of whole cloth, to identifying and integrating these smaller systems to suit specific business needs. Some bespoke development is needed on occasion as well, but not on the former scale.
It's somewhat analogous to finding and fitting together puzzle pieces. Sometimes we have to make a missing piece; sometimes we have to change the shape of an existing piece enough to fit the others.
August 13, 2014 at 9:53 am
I definitely think selecting the right tool for the right job is a good idea and a "solution" made up of smaller, more specialized tools that are integrated together is an excellent way of doing that. However I find that not all executives and decision makers (or IT leaders in some cases) get that.
August 18, 2014 at 11:29 am
I've worked with small to medium sized 3rd party apps in a variety of industries and although they're all easy to access their data (common RDBMS products) and/or export it to another system, they do a poor job of providing any type of customizable import or API. This is find for reporting, but you end up with redundant data entry in multiple system with the risk of poor data integrity. It's difficult to make those features available and for vendors who offer multiple "modules" they may prefer you stick with their entire system instead getting your functionality elsewhere.
Viewing 10 posts - 16 through 24 (of 24 total)
You must be logged in to reply to this topic. Login to reply