Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 123»»»

One System to Rule Them All Expand / Collapse
Author
Message
Posted Tuesday, August 12, 2014 8:08 PM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:56 PM
Points: 31,168, Visits: 15,612
Comments posted to this topic are about the item One System to Rule Them All






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1602541
Posted Wednesday, August 13, 2014 2:52 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:00 AM
Points: 5,576, Visits: 3,427
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!!!
Post #1602622
Posted Wednesday, August 13, 2014 4:06 AM
Valued Member

Valued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued MemberValued Member

Group: General Forum Members
Last Login: Today @ 4:26 AM
Points: 52, Visits: 363
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.

Post #1602632
Posted Wednesday, August 13, 2014 4:42 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:00 AM
Points: 5,576, Visits: 3,427
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!!!
Post #1602644
Posted Wednesday, August 13, 2014 6:01 AM
SSC Rookie

SSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC RookieSSC Rookie

Group: General Forum Members
Last Login: Thursday, October 9, 2014 11:49 AM
Points: 41, Visits: 44
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 http://it.toolbox.com/blogs/enterprise-solutions/system-blueprint-template-ndash-part-1-introduction-39619.

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.
Post #1602684
Posted Wednesday, August 13, 2014 6:09 AM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 5:19 AM
Points: 4,202, Visits: 3,640
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.


Tally Tables - Performance Personified
String Splitting with True Performance
Best practices on how to ask questions
Post #1602691
Posted Wednesday, August 13, 2014 6:16 AM
Say Hey Kid

Say Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey KidSay Hey Kid

Group: General Forum Members
Last Login: Yesterday @ 2:48 PM
Points: 685, Visits: 1,721
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.
Post #1602694
Posted Wednesday, August 13, 2014 6:20 AM
SSCarpal Tunnel

SSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal TunnelSSCarpal Tunnel

Group: General Forum Members
Last Login: Today @ 5:19 AM
Points: 4,202, Visits: 3,640
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.



Tally Tables - Performance Personified
String Splitting with True Performance
Best practices on how to ask questions
Post #1602695
Posted Wednesday, August 13, 2014 6:25 AM


SSCertifiable

SSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiableSSCertifiable

Group: General Forum Members
Last Login: Today @ 5:00 AM
Points: 5,576, Visits: 3,427
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


Gaz

-- Stop your grinnin' and drop your linen...they're everywhere!!!
Post #1602698
Posted Wednesday, August 13, 2014 6:34 AM
SSC-Enthusiastic

SSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-EnthusiasticSSC-Enthusiastic

Group: General Forum Members
Last Login: Tuesday, October 14, 2014 12:56 PM
Points: 193, Visits: 378
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.
Post #1602702
« Prev Topic | Next Topic »

Add to briefcase 123»»»

Permissions Expand / Collapse