days
-6
-3
hours
-1
-9
minutes
-3
-5
seconds
-3
-6
search

The Human Side of SOA

Paul p Henaghan

Application architectures have evolved greatly over the last 30 years of computing. They’ve shifted back and forth from proprietary character-mode terminals with centralised processing to client-server applications with distributed processing. Then, they shifted to the centralised hosting of applications but this time with open standards-based, web-delivered front-ends. Each of these trends included a variety of methods to connect disparate systems—many proprietary, some without any re-usable characteristics and all typically requiring the developers, operators and maintainers to learn a new set of skills and the organisation to put new processes in place. These upheavals invariably created friction and frustration for the individuals and the organisation involved.

Enter the Service-Oriented Architecture (SOA). Not owned by any one vendor or organization, it is logically and physically a loosely connected set of principles and technologies that collectively constitutes the next, possibly the last, major generation of application deployment architecture. The ‘human side’ of SOA ensures that planning, politics and personnel issues do not derail otherwise carefully designed SOA technology initiatives. SOA changes the way applications are designed, developed, deployed and maintained. Application architectures that were once “built to last” are now explicitly “built to change.”

A SOA offers true technical benefits. Yet a successful transition to SOA requires not just technical change—but organizational change as well. If managed properly, this organizational change can further foster the growth, adoption and success of an SOA initiative. However, if not managed properly, it can cause disruption and organizational conflict.

Greatly generalized, there are two groups involved in any application: the business users and the IT group. In a traditional application- development environment, interaction between these groups is limited to the times when there is either a new application to be developed or a problem with an existing application. Interaction occurs primarily when the stakes are high and, therefore, often in an emotionally loaded environment. By breaking down the delivery of application functionality into discrete chunks or services, the two camps can lower the pressure, lower the stakes and collaborate more effectively.

The consequences of changing the level of granularity at which IT and business users interact is both subtle and profound. By concentrating on (relatively) simple business functions, IT can concentrate on automating tasks that remain relatively stable year-to-year. In a world of globalised businesses, the biggest source of competitive advantage is found in business process innovation. Consequently, the parts of a business that change most rapidly and completely are the highest-level, most strategic business processes. In the traditional model, these business processes are implicitly captured in people’s heads or in hundreds of lines of monolithic application code. In the business world enabled by SOA, these business processes are instead moved into explicit, model driven Business Process Management (BPM) tools under the control of business analysts, where they can be changed and reconfigured at the click of a mouse.

If BPM is the way to enable business agility, SOA is the way to provide the IT agility that goes along with it. So, beyond the changes that occur in the way development teams and business users interact, SOA and BPM have the potential to change the way the entire organization operates. For this reason, the success of any SOA journey must be aligned to the corporate goals and vision and requires commitment and buy-in from the highest levels in the organization. Truly, the impact of SOA is both subtle and profound.

All organizations have both short term and long-term goals. For most businesses, IT is no longer viewed as a strategic differentiator or even as a strategic enabler. It has become “part of the scenery” at best and, at worst, a hindrance. The powerful combination of SOA and BPM has the potential to return IT to its former position as an agent for strategic advantage. The optimal value of SOA then is to support initiatives that are aligned with corporate strategy, especially those that focus on a move to exploit BPM.

Evolving From Technology to Business

All organizations have both short term and long-term goals. For most businesses, IT is no longer viewed as a strategic differentiator or even as a strategic enabler. It has become “part of the scenery” at best and, at worst, a hindrance. The powerful combination of SOA and BPM has the potential to return IT to its former position as an agent for strategic advantage. The optimal value of SOA then is to support initiatives that are aligned with corporate strategy, especially those that focus on a move to exploit BPM.

To this end, many organizations are following the advice of industry analysts to create an SOA Competency Center that acts as a shared services group to oversee the transition to an Integrated Services Environment (ISE).

The SOA Competency Center ensures that an organization not only adopts the principles of SOA but also makes sure that it is adopted correctly and with the least disruption to the IT organization while supporting business users. This team must  comprise  members across the organization, from both IT and business.

Traditionally, application deployments were stove-piped or functionally oriented in design. A department had a business need for an application with a specific set of functionalities, and the IT organization would build or buy the application, and then install, configure and maintain it. This process continued across multiple applications and departments. Each time the data and business logic were only available to that application and user community. For example, the human resources department might use an HR vendor application, the sales and marketing department might use a CRM vendor system and the customer support group might use its own custom application.

The move to an ISE is, at least in part, an evolution from a technology focus to a business focus, from a functional or departmental orientation to a process-orientation. Integration moves away from the technology focus of subroutines, methods and components to business components that are focused on the discreet and granular events that are part of the business process. By moving to ever higher levels of abstraction, IT’s deliverables achieve closer alignment with the artifacts of business modeling and begin to close the gulf of understanding between these two organisations that, in truth, rely on each other for their continued existence.

The essence of the ISE and its primary consequence is increased business agility which, like virtue, can be said to be its own reward. Projects must now be approached with an eye to the future and, more importantly, the re-use of the services created by that application. The company, as well as the project, needs to be aligned to corporate directions.

The move to an ISE is a journey and, like any worthwhile journey, is not completed in a day and is not without costs. The journey to an ISE rewards bold strokes, requires executive commitment and demands concerted effort in pursuit of a vision. Ultimately, however, the success or failure of the transition depends on the people who undertake the journey, and it is the human side of SOA that will make or break the project

Author
Paul p Henaghan
Senior Vice President