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.
[tags]enterprise, spreadsheets, excel, SOA[/tags]
3 replies on “The other kind of SOA”
Interesting post. I’ve stumbled across Access databases, spreadsheets and many other workarounds. There are also, as you suggest VB applications often interfacing at GUI level. The key theme is that the workaround grows and becomes mission critical and then one day it falls over and there is nobody there to support it.
Quite a number of vendors have spotted that some control is required here (a quick Google search will provide you with a comprehensive list). Whether you call it SOA, legacy conversion, screen aggregation, desktop integration or business process automation, the key is to find the balance between giving the business users control and flexibility whilst leaving the IT guys with some chance of supporting the solution.
Agreed. The ideal solution is to get the process for ‘official’ IT solutions lean/agile enough that it’s as easy to get a supported solution in place as it is to create a local workaround.
Interestingly, once we’d built a relationship with the business users on my last project (mainly by demonstrating that we really could respond quickly to their requirements, and deliver business value every couple of weeks), they actually asked us to replace the functionality of a couple of their local tools.
I like agility and this is what I have found most businesses want/need these days. If internal IT departments can provide that as well as the strategic developments then business users will be happy.
I think also that business users sometimes feel let down by IT departments who are often in different buildings, on different pay scales and sometimes (lets be fair) are not the best at selling themselves. IT people who make the effort (like you did) to get to know their business users and listen to them will do wonders for their organisation. After all its much better to take a tiny step in the right direction by fixing a small problem, than take a giant leap in the wrong direction by installing a major system that doesn’t meet the business needs.
Keep up the good work! I’ve subscribed to your blog…