SOA is next in a line of IT-changing architectures

Long before there was IT, there was Data Processing - a function most firms created to automate high volume tasks, such as creating bills and processing payments. Data Processing was centered around a mainframe that did much of its processing in batch. Then new architectures arrived and were leveraged by new ways of using ‘data processing’ - on-line transaction architectures, followed by client-server, followed by Internet-based architectures. Each of these facilitated new use by the business, making IT ever more pervasive, changing how IT worked with business partners and requiring both new skills and new ways of managing IT. Service-Oriented Architecture (SOA) is the next-wave architecture to drive the evolution of IT.

Service-Oriented Architecture is fundamentally a design philosophy: expose as encapsulated services the business functionality of an application. Use these services whenever that functionality or information is needed. But the optimal impact of SOA is in the opportunity for IT to address the constraints that have hindered its support for business change; increasing flexibility for the business, enabling multi-channel access to business functionality, and positioning for closer coupling between a firm’s business processes and those of its customers and suppliers.

As an architectural model, SOA is inevitable

A recent Forrester Research survey of more than 650 software decision-makers at large North American and European firms asked about their approach to SOA. Twenty-five percent of large global firms have an enterprise strategy for SOA, 16% are using SOA without a defined strategy and 21% will be using SOA within the year. Although 38% of these firms stated that they have no plans at present for pursuing SOA, it is not likely that they will sit out this wave:

• The software suppliers to these firms; major application vendors like SAP and Oracle, as well as many smaller ones, are vigorously incorporating SOA into their product plans - to unify their products under a single architecture and to make it easier for their customers to change their applications and incorporate new offerings.
• Among technologists within these firms, SOA has tremendous mind-share; SOA is one of the top search terms on the Forrester website.

Both large firms - often the bellwethers, the major application vendors and the IT technology leadership within firms - regard SOA as an important shift to be leveraged. The obvious conclusion is that, regardless of a firm’s strategy or level of sophistication, SOA will be part of their IT portfolio.

SOA pervasiveness requires a strategy to manage change

What will pervasive adoption of SOA mean to IT? First, it changes the definition of "an Application". Rather than being a somewhat self-contained combination of business logic, process and data on its own platform with its own user interface, now an application will be an assembly and orchestration of business services, service composition, process engines and user interface modules (see Figure 1). The concept in IT of ‘who owns what’ then changes, impacting funding, change control, operations, portfolio management - the list goes on. There are more components to manage - making common statements like "the application is up" (or "the application is down") meaningless. Business solutions will become composed of services that might be shared across business units, or sourced from partners in a business process.

But none of this will work unless there is an agreed-upon governance model, with standards, policies, funding and associated infrastructure for hosting, monitoring and testing services. And EA is the logical leader to champion the need for governance and relate governance and investment in SOA to the strategic objectives of the firm and the firm’s IT.

What should EA do about SOA?

SOA adoption must be planned if the benefits to IT and the business are to be realized. Without a plan, there will likely be a proliferation of incompatible services, duplication and redundancy rather than sharing common services, and ‘one-off’ technology and infrastructure choices - all the issues with which EA is already familiar.

An SOA strategy and associated architecture can be thought of as a different ‘view’ of the architectures and strategies that EA is already responsible for - and can be addressed in an update to existing deliverables or in a separate set of deliverables (see figure 2). For example:

• The infrastructure architecture for SOA will consist of tool and platform standards, production and test environment specifications, and SOA-specific elements for service registration, security, monitoring, etc.
• The SOA design view will describe architecture patterns, design principles and data standards.
• The SOA portfolio view describes the total view of what services provide what functionality to what business groups or processes.
• The SOA architecture, like Application and Information Architectures, is grounded in the Business Process Architecture which provides the context and relationship between services and the business strategy and operating model.

There is a continuum of activities an EA group can take towards an SOA strategy, ranging from the conceptual "this is what SOA is" to the deliverables that support implementation and production use of SOA services. EA groups should involve other IT and business areas as needed to: (see figure 3)

• Educate on "what SOA is, what benefits are possible, and what impacts are likely".
• Develop a firm’s strategic position: "How and where we will implement SOA, and how we will know how successful we are".
• Define, with appropriate resources, the technical strategies for SOA designs, implementations and operation.
• Develop the SOA portfolio framework, with a ‘To-Be’ state and a ‘Current State’.
• Develop the technology standards and design patterns for SOA services to ensure consistency and an ability to leverage experience.
• Define the semantic (meaning) and syntactical (structure) standards that will provide for consistent usage and meaning. Where possible, external and industry standards should be incorporated.
• Develop and implement review and governance processes and criteria for the SOA aspects of projects.
• If needed, sponsor or champion pilot projects to gain experience, prove benefits and validate standards.
• If needed, sponsor the SOA-enablement infrastructure that facilitates the realization of the core value proposition: re-use and leverage of services across multiple needs.

SOA strategies for Federated IT

Federated IT, with a combination of business unit-based and centralized IT groups using a shared infrastructure, is a common model in large businesses or the government. A persistent question for EA in these organizations is "What is the role of the central EA group when BU IT is where the action is?" This question continues with an SOA strategy, and the answer is, as usual, a shared responsibility (see figure 4). Although a federated IT structure is predicated upon a fair degree of autonomy for the business unit IT, an SOA strategy must assume that services will be ‘interoperable and sharable’ across business units. The role of the center is to put in place the standards and infrastructure to enable this:

• Develop the enterprise-wide strategic position.
• Develop or champion common technology strategies and standards.
• Provide oversight of the Service Portfolio, ensuring that business units contribute to and utilize services from this portfolio.
• Define, or provide the forum to agree upon semantic and syntactical standards.
• Sponsor the SOA-enablement infrastructure for use by business units as the means to promote re-use.

Business Unit IT will, of course, take the leadership in defining and governing its own SOA strategies. Review and governance of SOA initiatives or the SOA aspects of projects becomes shared between the central EA group and the business units.

Recommendations

EA groups must assume that SOA will be part of their firm’s IT environments and therefore must be a part of the architecture. SOA will be brought in either by individual developers and architects ‘doing what they think right’, or by application vendors migrating customers to their next versions. Ultimately, SOA should become simply another attribute of the Enterprise Architecture.

EA groups, at a minimum, should guide a firm’s SOA adoption by:

• Defining and owning the strategic positioning
• Establishing standards to promote a basic level of infrastructure commonality and interoperability
• Provide a forum for other strategic decisions, such as semantic and syntactical standards

EA groups should plan to go beyond this minimum, by championing the key enablers such as:

• SOA portfolio framework and processes
• SOA repositories, registries and testing standards

As SOA becomes pervasive, and IT is transformed by it, EA will play a vital role in helping IT ‘ride the wave’ instead of being swamped by it.