Management wants an API in purchased software

My company wants to purchase new software for our General Ledger. We want to be able to interface it with various other sytems, all purchased. Nothing is custom built. The software our Accountants like does not have any APIs. However it does allow for imports and exports through various file formats.

The imports (which are most import to us) can be triggered by an import file being placed in a folder. A “steering committee” that is involved in this purchasing decision is made up of people who are not either IT people or programmers. They’re lawyers, a chief executives, a compliance officer and a few others in similar roles. They are fixated on this software having an API, or APIs, I don’t which is more proper.

It seems to me that with the import and export functionality we can do what we need to do. Since we don’t write our own software we couldn’t code to an API. But, I don’t have enough experience to really know what an API might offer that the software in question couldn’t deliver. I chair the steering committee and would like us not to get side tracked by something that I suspect is irrelevant. Can anyone help me to understand what I might be missing, or rather how an API would be advantageous?

API = Standardisation (to a much larger extent than text files)

Having spent a couple of years developing an application that a particular client wanted to interact with MYOB I would seriously recommend a GL with API.

Text file import/ export is an horrendous way to run a company.

(IF) you ever need any customisation of the product/module the first thing any developer is going to do is build some kind of API if you dont already have one. Then 6 months later, she is unfortunately killed in a car accident… and you need some more customisation. So the next developer looks at the scratch of an API started by the first and then modifies/appends to that for the purpose at hand… and so on.. and before long you have a frankenstein on your hands…. because as you say you dont develop in house and whose to say any of these developers are experts in the GL module anyway. So they start creating their own API’s according to what they think is the GL module, not neccessarily what it actually is.

Whereas a product with a prebuilt API is straight form the horses mouth. The people who built the GL module are saying this is how you should interact with our product programmatically. Then you can go out and get a developer who actually already knows the API…. from that last job they did. i.e. they dont have to learn your company’s frankenstein first.

Also with a pre built API, add on modules/upgrades etc from 3rd party vendors become more feasible. Again because the GL’s API is standardised and known outside of your company and therefore represents a market opportunity to hungry developers.

Security: With an API you can more securely communicate with your GL. It’s much harder to hack a systems process memory to mess with GL API based imports/exports, than it is to open and modify a bunch of text files sitting in some folder on the file system.

Your argument seems to be we dont need programmatic access to the product and we never will, well good luck with that. 😉

If you’ve recently under taken a full strategic review of how IT is used in your company and can honestly say they you will never need to modify either how you get data into your GL and how you shape data coming out of your GL then go ahead and by pass the requirement for a new GL module to have an API.

That said the future is the great unknown. I personally would NEVER recommend a GL module without an API…. simply because I know whats out there…. and no accounting package that I’d be looking at for our customers (SME’s) going forward is without an API…. especially given the uptake on cloud computing.

Trained Software Engineer in a debate/discussion/argument with Lawyers, Accountants and CEO’s – you will lose, no doubt about it! The only way out for you is to have appropriate levels of CYA documentation….

Seriously – you cannot use facts and numbers against this emotional attachment to an idea/ideal. If they have read an magazine saying “It must have an API”, then they will say “We need an API”, and will not be happy without one. They will have absolutely no idea what one is – this is your biggest asset, use it.

What I would do (before / apart from giving up and writing a stack of CYA emails), is discuss the file import/export as an API, and always use the word “API” when discussing it. This will move the focus onto functional requirements and how it can achieve what needs to be done, and away from the “I must have an API” dance.

Filed under: softwareengineering - @ 20:23

Thẻ: api, management

Thiết kế website giá rẻ

Danh mục

Management wants an API in purchased software