SOA still evolving, but questions remain
- 29 March, 2007 15:02
As the rapid adoption of service-oriented architecture continues within the corporate environment, companies are realizing that implementation is not instantaneous but evolutionary. To accommodate this process, a simplified SOA reference architecture has evolved that seems to embrace all corporate industry and vendor variants. Fundamental to this reference model are the logical partitioning and separation of all corporate/IT functionality into a set of common services, logically interconnected for shared use by a common enterprise service bus (ESB).
At the top of the reference architecture are the crown jewels of the corporation: corporate business services. Underpinning the reference architecture is the physical world's delivery vehicle interface: infrastructure services. The architecture's three support pillars are services for development, management and security. Logically partitioned business process services, information services, collaboration services, business partner services, business application services and asset access services form its core. The base for the architecture is the physical infrastructure of clients, servers, storage and networks.
The tuning of the reference architecture from its origins is the result of a shift in corporate priorities. Based on corporate CEO comments in 2006, cost reduction is the pervasive issue, but three additional priorities have surfaced: expansion, enhancement and extension of the ability to collaborate internally and externally; creative innovation of business models and processes; and business optimization leveraging new and existing information.
CIOs in 2006 also added two IT priorities to their list: any-to-any connectivity and resource/asset reuse. These five priorities have become the focal points for SOA implementation.
From the concept of a single SOA reference model, specific subarchitectures, such as service-oriented management and information architectures, have evolved. In reality, an SOA subarchitecture is required for each kind of enabling service. The most complex of these is for infrastructure services -- a separate subarchitecture is required for each of the four forms of physical infrastructure. Cisco had it right, but only as far as the name -- service-oriented network architecture (SONA). By not originally linking SONA directly onto the SOA reference architecture and identifying it as an open, evolutionary subarchitecture, Cisco and the network industry went out of sync with their IT counterparts and corporate customers.
The evolution of the ESB also is a work in progress. The ESB, being logical in implementation, may be common (shared) or composed of separate buses for each services type -- a management bus for management services, a process bus for all process services and so on. As more corporate SOA implementations occur, the need for physical as well as logical separation of buses may arise.
While the influence and adoption of SOA is unquestioned within the corporate realm, numerous architectural questions remain unanswered. Should virtualization be a common services type similar to access? Can management and security services be combined into a single set of management services, such as in IBM's SOA reference architecture, or do they need to be distinct and separate? Are governance and compliance services part of management services, or are they separate SOA core services? Will reuse of business, as well as application, components ever become reality?
How does telemetry information, such as RFID and other forms of sensors, fit within access and security services in an SOA? Is a separate and distinct event bus required as part of the ESB subarchitecture? Although voice is being incorporated within SOA, where and how does video fit into the architecture? Web 2.0 standards and technology have become part of SOA; will Web 3.0 also be embraced? Last but definitely not least, will Cisco or another vendor create a SONA that embraces all of the SOA services requirements in such a manner that it can be established as a viable networking subarchitecture? Stay tuned.