August 12, 2014 at 8:08 pm
Comments posted to this topic are about the item One System to Rule Them All
August 13, 2014 at 2:52 am
I am an advocate for the "specific system for a specific function" school of thought as opposed to "we will buy in a very expensive ERP system and customize our whole company around it". The latter tends to force a company to change its business processes to be closer in line with what the ERP can handle rather than find a system that is a close match to requirements. Also they both end up in an imperfect situation.
What I really prefer is customisable COTS systems that are best of breed and have an open API to the data because it is assumed that the data is the purchasing business' (as opposed to the supplier's or their system's). This leads to a system that is easily replaceable because it is isolatable but not necessarily worth replacing because it does, or at least it should do, a reasonable job. This also allows for bespoke development of systems to integrate with an enterprises' business systems ecosystem where there is no COTS software applicable.
I guess this boils down to "although I love coding, I must only code what I have to". Reuse, support, maintainability, etc. are the cornerstones of my opinion.
This follows on from how I develop systems; I reuse off the shelf components as I wouldn't dream of implementing a RDBMS, for example.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 13, 2014 at 4:06 am
Gary Varga (8/13/2014)
..... opposed to "we will buy in a very expensive ERP system and customize our whole company around it". The latter tends to force a company to change its business processes.....
Yep, come across those situations before. Seen it in large multinationals and also in a smaller sub 1000 person company.
I tend to be wary of "solutions" that become too difficult to move away from. If they offer proper exports and proper interfaces then it tends to be be because they are sure of what they do and have a good product.
August 13, 2014 at 4:42 am
Yet Another DBA (8/13/2014)
...I tend to be wary of "solutions" that become too difficult to move away from. If they offer proper exports and proper interfaces then it tends to be be because they are sure of what they do and have a good product.
Totally agree. Also you mention size of company. That matters a lot too.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 13, 2014 at 6:01 am
Having participated in the design and development of enterprise level integrations at several large organizations, I need to say the development team frequently has little to no input on decisions made to purchase large ERP applications. Someone gets to the CIO or CTO and sells the features of the ERP, whether it is Solomon, Great Plains or JD Edwards. Development teams then have to design the integration so existing systems will interact with it.
Since we will never change the behavior of CTOs or CIOs, it behooves us to get to know the intricacies of a Software Architecture Blueprint. See [url= http://it.toolbox.com/blogs/enterprise-solutions/system-blueprint-template-ndash-part-1-introduction-39619%5D http://it.toolbox.com/blogs/enterprise-solutions/system-blueprint-template-ndash-part-1-introduction-39619%5B/url%5D.
Using documentation as described in the link above allows you to see the big picture of the integration and brings into focus what is needed to succeed in the integration process.
August 13, 2014 at 6:09 am
I don't care for the "very expensive ERP" option either. I got to work with one for a period of several years and found it tedious and difficult. Let's face it...it didn't want to be customized at all. It was slow and inefficient and completely incapable of ALTERing anything. Every change involved a complete rebuild of the table, so it didn't keep any indexes we created on anything. The foreign keys were maintained by the application and not the database, which helped bloat the application. I'm thankful I don't have to work with it any more.
August 13, 2014 at 6:16 am
Steve wrote in the editorial:
"On one hand I think that's a better way to build large systems, mainly from the standpoint of size, scale, complexity, and likelihood of completion. However I also realize this means that all companies need to account for some level of software development, either in-house or on a contract basis."
I'm that in-house programmer for my division. I write utilities that save us and our clients time. I also build custom ETL programs that make client "data" work. Yeah! Even though we are slowly switching to SSIS for some of the complex jobs, many times a small script in PowerShell or Python is the answer for the job.
August 13, 2014 at 6:20 am
chrisn-585491 (8/13/2014)
I'm that in-house programmer for my division. I write utilities that save us and our clients time. I also build custom ETL programs that make client "data" work. Yeah! Even though we are slowly switching to SSIS for some of the complex jobs, many times a small script in PowerShell or Python is the answer for the job.
I think that's called picking the right tool for the job, which is something I'm a big proponent of as a whole.
August 13, 2014 at 6:25 am
Ed Wagner (8/13/2014)
chrisn-585491 (8/13/2014)
I'm that in-house programmer for my division. I write utilities that save us and our clients time. I also build custom ETL programs that make client "data" work. Yeah! Even though we are slowly switching to SSIS for some of the complex jobs, many times a small script in PowerShell or Python is the answer for the job.I think that's called picking the right tool for the job, which is something I'm a big proponent of as a whole.
I think you will find much support for that thinking.
As an aside, I initially scan read your response and thought (totally incorrectly) that you you were being a tad aggressive. If you cannot see it then you are a far purer soul than I am. If you can then you might chuckle :Whistling:
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
August 13, 2014 at 6:34 am
I guess it all depends on who is making the decision. And what they fear.
More technology focused companies see technology as a competitive advantage, and seek out the best solution. Others see technology just as another expensive administrative bit of overhead. Until, of course a competitor gets ahead. And some exec's like the idea of having a single company to call when it breaks. Personally, I think technology focused companies will succeed.
The more you are prepared, the less you need it.
August 13, 2014 at 6:38 am
I think that's called picking the right tool for the job, which is something I'm a big proponent of as a whole.
I believe that's what the editorial was espousing. Magic bullets aren't. One size doesn't fit all. Yada, yada, yada...
Example: Many experienced folks find that SSRS isn't what they need even though it comes along with the rest of the SS tools. So they use Tableau. I may end up using ReportLab or D3.js for some clients.
We don't use much of SSIS at remote clients because it's yet another system that is to complex for them to manage. Instead they get custom executable and scheduling.
August 13, 2014 at 6:55 am
Andrew..Peterson (8/13/2014). And some exec's like the idea of having a single company to call when it breaks.
It is never the exec that makes the call or deals with the fallout. Effective single source is a fantasy that execs are prone to believe.
The Air Force, Navy, any large company wants the single off-the shelf product that will meet all their specific needs - at off-the-shelf prices. No surprise, it suddenly needs add-ons to meet their specific needs that cause complexity and cost overruns. As one poster said, openess and offering proper imports and exports go a long way towards reducing cost.
August 13, 2014 at 7:03 am
When I worked at Intel In the mid-90's, we were growing so fast that a universal system couldn't handle the needs of the local groups fast enough. So, we had a lot of "smokestacks", home-grown applications and databases to solve the local need.
That, of course lead to problems with different piles of data being shared and analyzed. Our team was tasked with coming up with shared data models, and translations to them. The hope was to foster the shared usage of data from many different sources. The message was, "roll your own, but use our data definitions".
Unfortunately we saw limited results due to incomplete buy-in of the business units. Then they brought in dozens of SAP "consultants" (many newly minted college grads who had never seen a real world mess), and things got REALLY interesting.
[font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
Connect to me on LinkedIn
August 13, 2014 at 7:52 am
I'm not a firm believer of one system to rule them all. But, I can see the attraction from a business standpoint.
If there was a single piece of software or solution that handled all my needs, then yes, it's the best option. Having used Outlook for some time, I would really hate having to use 2 separate programs for my email and calendar or better yet, a 3 program for task management if I actually used Outlooks tasks. I instead, would love to have all those features in one solution that's accessible together.
That means I only need to likely hire one person at the very least versus 2 hires to support both solutions.
When you get into solutions that are a rainbow of different technologies and solutions integrated into a unified solution, then you have what many of you guys run into today. Businesses requiring those one hire to rule them all. The one guy who not only is a DBA, but also a back-end developer and front-end developer who speaks 5 different languages.
August 13, 2014 at 8:05 am
I work as a DBA/support/setup/and too many things to mention for a 3rd party software vendor. We've witnessed a number of our clients leave in search of that "magic bullet" software bundle that does everything and does them all well "out of the box". And many, though not all, come back to us complaining that the software did do a lot, but lacked in many areas.
In response, we've tried to stay focused on a specific goal and be the best we can be in that area. Certainly it costs us some sales, but we feel in the end it's worth the sacrifice for our current and future clients. Time will tell if we've made the right choice.
Viewing 15 posts - 1 through 15 (of 24 total)
You must be logged in to reply to this topic. Login to reply