Some people struggle to distinguish an ‘abstract model’ from a ‘concrete architecture’ and this confusion leads them to dismiss the OASIS Reference Model as “ivory tower” stuff. But there is a lot of value to be gained from understanding it.
In order to demonstrate the usefulness of the OASIS Reference Model for SOA, I’ll use the example of aeronautical engineering.Most aviation projects are now multi-national, multi-organisation endeavours. For example, the latest headline grabbing aircraft, the A380, was built by Airbus which is a consortium of many organisations from various parts of the globe including UK, Germany, France, Russia, Spain and the United States. The people working on the project all speak different languages, have different cultural perspectives and attended different universities. Granted, the project had well publicised problems but at the end of the day the plane was built and successfully commercialised. It’s also noteworthy that not a single person on the project had any experience in building an ‘A380′.So how was it possible to bring together so many different people from so many different backgrounds and successfully complete the project? Simple, aeronautical engineering has a large body of knowledge which includes:
- Clearly understood semantics
- well honed theory
- 105 years of practice (since the Wright brothers’ flight in 1903).
It doesn’t matter what type of aircraft you’re building (A380 or space shuttle). It doesn’t matter what language you speak. It doesn’t matter where you studied. Everyone in the project was on the same page.
So what has all this got to do with SOA and enterprise architecture? Well, we don’t have a century of practical experience to fall back on but the OASIS Reference Model can help us with the other two things: semantics and theory.
A380 project brought together experts in a wide range of areas such avionics, fuselage, cargo loading systems, cabin design and propulsion (to name a few). Everyone was working in isolation (so a large extent) but everyone knew they were part of a bigger picture. The engineers designing the engines knew they had to fit in with the weight restrictions of the wing designers. And the wing designers needed to be mindful of the fact that the wings had to have engines attached. This two-way communication was made possible because everyone was speaking the same language (common semantics).
Enterprise architecture (including SOA) also requires experts in a range of disciplines to work together. The OASIS Reference Model provides a common language to make communication between these experts more effective.
No one on the A380 project had ever built such an aircraft. But the aircraft was designed with reference to commonly understood principles (e.g. drag, lift, thrust and weight) and then the design was validated through the use of scaled down models.
When we’re designing an architecture, the design will always be unique to a given organisation: the A380 designers could download completed designs for the new aircraft and enterprise architects can’t simply download a ready made ‘one size fits all’ architecture. The aircraft engineers validated their designs with models and enterprise architects should also validate their designs and the OASIS Reference Model is as good a place to start as any.
In terms of ‘practical experience’ no one could be 100% sure the A380 would actually fly when it rolled down the runway on its first test flight. Similarly enterprise architects can never be 100% sure that their architecture will ‘fly’ – but all you can do is apply as much rigour as you can in the design process – and then hope you’ve done enough. .