The Human Side of SOA
The way that we have built applications and their architectures have evolved greatly over the last 30 years of computing; shifting back and forth from proprietary character mode terminals with centralized processing to client-server applications with distributed processing back to centralized hosting of applications, but this time with open, standards-based web-delivered front ends. Each of these trends have included a variety of methods to connect disparate systems - many proprietary, some without any reusable characteristics, and all typically requiring the developers, operators and maintainers to learn a new set of skills and the organization to put new processes in place. These upheavals invariably create friction and pain for the individuals and the organization 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 constitute the next, possibly the last, major generation of application deployment architecture. SOA changes the way applications are designed, developed, deployed and maintained. Application architectures that were once "built to last" are now explicitly being "built to change".
So, why SOA? SOA gives developers and business users the ability to combine services from new and existing systems into new applications that address business needs. Organizations can realize a greater return on assets for the mission critical systems that they have invested in over the years, as well creating better applications for their end users.
An analogy from everyday life might help to clear things up. People who live in developed countries have contact on a daily basis with reliable, ubiquitous systems of almost unimaginable complexity, and have come to rely upon them absolutely - we’re talking about utilities like power, heat, light, the telephone system, the water supply, the gas supply, cable TV, and so on. Each of those utilities enables the ability to connect virtually any device or gadget or artifact to them so long as it has the right plug or connector on it. We can change from a push-button telephone to a cordless device, or add an answering machine to our phone line, for example, without any assistance, involvement, or intervention from the phone company. With SOA, our business applications can begin to approach that same level of simplicity and, well, utility.
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 functionality, and the IT organization would build or buy, and then install, configure and maintain that application. This continued across multiple applications and multiple departments, and each time the data and business logic were only available to that application and user community; HR might use an application from PeopleSoft, sales and marketing might use a CRM system from Siebel, and the customer support group might use their own custom application.
As mentioned above, traditional application development comprised two groups - application developers or IT, and business users. The application developers either implemented applications, or wrote code to match the requirements defined by the business users, likely including the development of interfaces to other systems. The application developer would be required to know how both the source and destination system worked, as well as how the business process worked. In most cases, that integration was a specific piece of code for that integration and was rarely reusable. Furthermore, key aspects of the business process were now enshrined in application code, hidden from view, and often difficult, perhaps even impossible to change.
Once the application was delivered, any subsequent changes to the business process would require the involvement of IT, and incur costs and delays that were often prohibitive. The advantages conferred upon a business by the adoption of information technology had become instead a chokepoint, a potential roadblock to innovation.
Effectively, both the business users and application developers had to wear hats that were not core to their primary job functions - IT specialists found themselves inextricably bound up in the implementation and modification of business processes, and business users had to gain an appreciation of the complexity of marrying different technologies to one another. 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 if there is a problem with an existing application. Interaction occurs primarily when the stakes are high, and therefore often occurs in an emotionally-loaded environment.
In the world of SOA each of these groups find their responsibilities and roles clarified while reducing the complexity of application integration and development. Application developers leverage the principles of SOA to develop and deploy application functionality as services, and the organization’s disparate, disconnected systems become an agile platform for developing and deploying new applications. By breaking down the delivery of application functionality into discrete chunks, or services, the two camps can instead lower the pressure, lower the stakes, and more effectively collaborate in an interactive manner.
The traditional roles and responsibilities of user and developer communities will change, but will also become clearer, with each group moving closer to their core competencies. In addition, a different set of project metrics will be needed for measuring the success or failure of an application development or integration project - away from the narrow, functionally or departmentally-oriented view of simply meeting the immediate requirements and towards a shared-services view that is more in line with a process-oriented view of the organization. Finally throughout the entire process, the organization as a whole needs to invest in SOA, to support the changes necessary to ensure success and to mitigate the conflicts that might occur between organizations. With these ideas in mind, the foundations of SOA can be built to provide an infrastructure for success.
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.
With all of the discussion of how SOA projects will be implemented and how it will change the organization, it is also important to take a look at how the success of a project is measured. Traditional applications are judged on a number of criteria, the most important being time to deliver and cost of delivery. With SOA, these metrics must shift to include more than just the (functionally-oriented) project, but to the (process-oriented) IT utility as a whole.
Every new development project must now be viewed as an integration project. Every new application must answer the question "how does this impact the business?" and must involve the SOA Competency Center to ensure it meshes with the strategic direction of the company, and that it conforms to the organization’s technical blueprints for SOA.
In the past, the development of applications was focused around the function of the application and it used technology to provide that. The business then worked with the application and adapted to that function. Now, with the advent of SOA, the approach of process-driven integration is possible.
Projects must be approached with an eye to the future and more importantly the reuse of the services created by that application. This requires that applications are focused on adding value to a company, not just to the siloed application that is being created. This requires the company, as well as the project to be aligned to corporate directions.
The move to an integrated services environment is a journey, and like any worthwhile journey, is not completed in a day, and is not without costs. The journey to an integrated services environment rewards bold strokes, requires executive commitment, and demands concerted effort in pursuit of a vision. Ultimately however the success or failure of the transition rides on the people who undertake the journey, and it is the human side of SOA that will make or break your project.