Service Orientated Architecture – A Balance of Form and Function
The concept of form following function was at the heart of modernist Bauhaus architecture in the early 20th century and, according to Wikipedia, extols the principle that…
“…the shape of a building or object should be primarily based upon its intended function or purpose.”
The phrase ‘form ever follows function’ was actually coined as long ago as 1896 by American architect Louis Sullivan, although the concept stretches back all the way to the Roman architect Marcus Vitruvius Pollio who asserted in the 1st century BC that structures should exhibit the qualities of being “solid, useful and beautiful”.
In contrast to the modernist architecture of buildings, architecture of enterprise software is frequently guided more by engineering constraints than the needs of a business. Functional requirements are gathered but are often implemented in ways which are more optimal for engineering than for the business processes they are meant to support. The result is that business processes must be made to fit with the form of the software, rather than the software fitting the function of the business. The software becomes like a strait jacket on the business which prevents it from adapting or being able to react to external conditions.
However, innovations in enterprise architecture are freeing software to mould itself to the business processes in ways not possible a few years ago. A system built using a modern Service Orientated Architecture (SOA) is comprised of discrete, loosely coupled modules that can communicate with each other without human intervention.
The Open Groups definition of SOA is:
Service-Oriented Architecture (SOA) is an architectural style that supports service-orientation.
Service-orientation is a way of thinking in terms of services and service-based development and the outcomes of services.
They go on to say that the SOA Architectural style
“…is based on the design of the services – which mirror real-world business activities – comprising the enterprise (or inter-enterprise) business processes”
By modularising the code, providing standardised interfaces (API’s) and adopting standard communication protocols, such as web service calls using SOAP, it’s possible for features and functions to be re-combined in endless ways to support a variety of different applications. SOA also provides a way to organically grow functionality in an iterative way. By adopting an agile software development methodology developers can design, built and test modules that support small units of business process a piece at a time. Since the modules are self-contained they can be re-used and re-combined with other modules to reduce development effort. Maintenance costs are also reduced since single modules can be swapped in and out with a minimum of disruption.
By adopting a modular service orientated architecture software developers can now at last follow the principles first laid down by Vitruvius and create solutions that fit business processes beautifully.
Mark Jenkins has worked in the IT industry for over 15 years as a BI and Analytics consultant, and more recently as ROC Product Manager for Subex Ltd. He has designed and deployed solutions for global companies in many sectors including Insurance, utilities and telecommunications. Mark holds a BSc Hons in Computer Science from Manchester University (UK).
Request a demo