First: there doesn’t yet appear to be a considerable number of completed SOA projects in Australia – there are some well-advanced plans, quite a few smaller, proof-of-concept projects (like ours), and a few web-service-only projects.
There is also an interesting difference of opinion when it comes to justifying SOA to the board/business: some of the presenters had big, top-down plans for implementing SOA, and spoke of the business case; others took the view that SOA was a deployment option for business-sponsored projects, so there was no need to make a business case for it specifically.
My view is that, particularly in the early part of your SOA journey, applying SOA principles to approved projects may well add some cost and complexity. This extra time and expense will hopefully pay you back handsomely later – but that will be on other projects, not the one that has to be paid for now – so there’s some need for a business case to justify the incremental costs incurred (particularly if the sponsor of this project is paying for something that other business units will benefit from – potentially a ticklish political problem!).
There is also the necessity for some longer-term, strategic thinking around any architectural approach – and this is where some planning is useful, especially if this is your organisation’s first attempt at it. The danger of a top-down-only approach is that you spend a lot of time, effort and money and end up with a beautiful document and no service-enabled business capabilities; the bottom-up approach leaves you with too many services and no re-use, governance or agility. This is where a proof-of-concept project is useful – to test your capabilities, deliver some value with relatively little risk, and give you a practical skills/knowledge foundation from which to develop a longer-term framework.
As for my own presentation: I seem to consistently get the slot immediately before an afternoon break – which is great because I deliberately aim to run slightly under-time. That way either everybody gets an early minute for a coffee, or the reason we don’t is because there is a lively Q’n’A going on. This time I took only about half my allotted period – this left time for me to ask some questions about hurdles to SOA adoption in Australia.
Well – we ended up being ten minutes late for afternoon tea, such was the discussion that ensued (almost an “unconference“, an idea I suggested for next year).
Main points made:
- enterprise architects in general are hard to find
- enterprise architects with some specific SOA skills/knowledge are rarer
- someone with all that AND knowledge of the business is almost mythical in rarity – the skills shortage was identified as a potential threat to adoption of SOA
There was also discussion around the difficulty of getting the business to see the benefit of a longer-term, cross-project view of architecture and re-usable services when planning and funding is on a project basis – this is where successful PoC’s can demonstrate value. The importance of governance was stressed a number of times, but a potential issue with inappropriately-applied governance stifling agility (one of the key potential benefits of SOA) was also identified.
As an aside, there was an interesting contrast between Qantas and its low-cost subsidiary JetStar, both of whom had representatives presenting. Jetstar was given a virtually clean slate for their IT, and given the low-cost objectives decided to outsource as much of their IT as possible – using SaaS applications wherever possible, decentralising responsibility for hardware, using thin clients, etc … essentially reducing IT to a per-unit cost with minimum capital expenditure (data storage being the major exception, although if regulatory issues could be overcome, the Amazon S3 model would become attractive).
Qantas of course has more history/legacy/baggage, so doesn’t have the same ‘clean slate’ to work with. They are also a full-service airline, so the commodity IT approach doesn’t work so well. This was an organisation that appears to have taken the top-down approach to its SOA planning, starting with a fully-fledged architectural plan, implementation of SOA artefacts such as an enterprise service bus, business process management etc. – but not a great deal of delivered business capability yet.
These comments are not meant to be a judgement of either approach – there is nothing to say that both won’t be successful in their respective environments … it was just amusing to see such a difference in style between related companies.
There’s definitely more than one way to skin this cat ….
Disclosure: As a speaker, IQPC comped the attendance; travel and accommodation was paid by my employer.