by Dave Duggal
While it’s no longer trendy to talk about Service Oriented Architecture (SOA) due to limited initial results, it is implicitly the architectural-style of our age.
Our applications and processes increasingly depend on distributed and diverse systems, databases, and devices. Modern Enterprise, Cloud, Web, Mobile and Internet-of-Things app development all take advantage of re-usable functionality exposed as services (and, more generally, APIs). The ability to incorporate capabilities and information from multiple sources and deliver to a wide range of target devices and systems both enriches our applications and makes them more flexible, which is attractive to both the business and IT. Though SOA maybe deep in the trough of disillusionment, it was a step in right direction of software modularization.
The problem with Service Orientation v1 is that it’s altogether too service-centric! That might sound paradoxical at first, but consider that the whole point of software development is ultimately to deliver applications that provide valuable behavior to the business. However, SOA assumes that developers at the applications layer handle the complexity of making and maintaining connections; services are manually selected and integrated. As a result, applications built of services maybe composites, but they remain collections of tightly-coupled objects, not unlike their monolithic forefathers. After much effort, the reality is that every app and process remains a silo.
Service catalogs strive to make management easier, but how do application developers identify the right service at design-time and maintain connectivity as it changes or substitute it with a more appropriate service? There’s no dynamic discovery and change at service or application level requires manual intervention.
Moreover, at run-time applications can’t dynamically configure services to optimize for a business context. This limits the utility of a generic service with a ‘coarse-grained’ interface and leads to demand for specialized services with ‘fine-grained’ interfaces, however it undermines SOA’s original re-use promise and leads to a service explosion, increasing catalog maintenance costs.
These issues are compounded by the challenge of governing services. While Services expose functionality through their interfaces, governance, the management of non-functional concerns, is another item ‘not included’. Security, business compliance, version control, lifecycle management, etc. are all managed separately, per siloed application. IT organizations generally have Enterprise-wide standard operating procedures (SOPs) for governance, but they are implemented manually and therefore, almost always, inconsistently.
The promise of Service Orientation, increased IT productivity and business agility, can never be delivered by the development of service catalogs alone, it was premised on assumptions of dynamic service discovery, provisioning, and configuration that haven’t been delivered. Service Oriented thinking has to evolve beyond a focus on service design and management, to deliver automated service interoperability at the application layer. It’s time to take the next logical step to Semantic SOA.
Instead of continuing to hardwire our business logic and services together at design-time, Semantic SOA lets business logic dictate the binding of the right app, data, process, network and UI resources at run-time to optimize Functional and Non-Functional Concerns for a specific business context.
Importantly, Semantic SOA doesn’t change what you are integrating; it changes how you are integrating them. In Semantic SOA, interfaces are expressed in ontologies, which provide a common data model for humans and machines to interpret their meaning. By making data a first-class citizen of a SOA, we can finally move from one-off syntactic integration to automated interoperability.
In Semantic SOA, services are no longer rigid procedures that impose a certain set of transformations on supplied data. Instead, the business context drives specific processing variations controlled by policies. The formerly rigid service implementations become dynamically mediated services – a process – executed by autonomous agents to render an optimized service.
This is an important leap as it lifts SOA from an architectural style for simply exchanging functionality between distributed systems to a distributed information system architecture that supports ‘smart’ data-driven policy-controlled applications.
Semantic SOA abstracts connection and transformation details, so application designers can focus on what they want, without worrying how it’s implemented. Likewise, programmers can focus on coding new value-added services and connections without worrying about domain logic. The approach unleashes development productivity, while enabling the business to rapidly experiment and continuously innovate at low-cost.
Semantic SOA isn’t disruptive, its additive. Semantic SOA provides a fabric above existing service catalogs, API registries, legacy apps, central systems, databases and devices. The initial scope of Semantic SOA can be narrowly focused to enhance a few tactical applications, and then expanded overtime, building on success to achieve broader strategic goals.
While the ideas around Semantic SOA have been around for a long time, early implementations were limited in capability and failed to be performant, scalable, and governable. The cost of flexibility was simply too high, and inertia of conventional methods engendered a natural resistance. However, the tide is turning.
Global competition is increasing and innovation cycles are accelerating. Business agility is now a sought after competitive advantage. The Digital Enterprise needs to be responsive and adaptive; it’s under pressure to efficiently personalize interactions to deliver differentiated services at scale.
At the same time, advances in Compute, Storage and Networking make new implementations possible. It’s time to revisit the application layer – Semantic SOA makes sense!