Most large organisations have been using SOA for years, and they’ve been doing it despite their IT strategy, not because of it. No, not Service-Oriented Architecture, but Spreadsheet-Oriented Architecture.
What generally happens is that the systems provided by IT don’t do everything the people in the business functions need, or they don’t fit in with working practices, or they don’t talk to each other. People end up extracting information from various official systems (often by writing screen-scraping applications in VB or similar), importing it into spreadsheets, performing whatever calculations are necessary, and sometimes feeding the results back into the same or other systems.
In some ways, this is a good thing (The Simplest Thing That Could Possibly Work), but it does have its problems:
- Uncontrolled spreadsheets risk basing decisions on out-of-date or inconsistent data, particularly if they are e-mailed around.
- The fact that key functionality has to be implemented by the users indicates a poor understanding by IT of their real needs.
- If there are many users, it’s likely that there will be multiple different local solutions to the same problem, meaning duplication of effort and potential confusion.
So what can we do about it?
Understand the business and your application’s users
Historically, IT departments have been very good at creating (or buying and configuring) systems that didn’t really do what the people using them every day needed. Hopefully now that agile development is starting to finally catch on in large companies, this will change.
The key isn’t just asking what users want though – it’s identifying what they need. This means understanding their business and operations, and suggesting ways that automation can make those operations easier, rather than just re-implementing old working practices in software.
Make better use of ‘local tools’ developers
Many business units end up with their own ‘ghost’ IT departments, consisting of people who write all sorts of little (and sometimes not so little) automation tools to make their and their colleagues’ lives easier. It’s worth finding these people and working with them, for example by providing APIs to reduce the amount of screen-scraping.
Better still, get them involved in creating the systems themselves. On a recent project, we implemented the core, and a team drawn from the operations side wrote the workflow that did the real work. There’s no way we could have automated the processes involved without their deep knowledge of the domain.
Support import/export and interoperability
If you decide that the hidden spreadsheet layer is unavoidable, why not at least make it a little less painful? It’s trivial to generate CSV files, and tools like HSSF allow generation and even reading of Excel workbooks.