SOA in the Real World 

SOA Transformation and IT Culture Shock

By Eric Roch, National Practice Director, Perficient , 06/26/2006

Print this article Email this article Talk Back! Write to Editor

For most IT organizations, SOA is a culture shift from a technology-driven application development style (focused on features and functions) to a business-driven style (focused on business processes and underlying services). One of the major factors in early SOA success is the speed at which a company can shift to a SOA development style, which is correlated to current IT skills and development processes in place.

For IT organizations still building applications using a waterfall methodology with procedural languages, an SOA approach will be a culture shock. The waterfall approach involves users in the requirements phase and then again during user acceptance testing. There is typically a user and designer disconnect between the requirements phase and user acceptance – often leading to a big surprise at the end. Rapid application development techniques help by involving users with design through the use of prototypes. Prototypes, however, are typically a requirements deliverable for the user interface and do not give much visibility or flexibility to the underlying business process.

An Object-oriented analysis and design (OOA/OOD) style is more consistent with SOA in that OOA/OOD has specific deliverables that can be applied to interface design, separation of concerns, and collaboration. Object-oriented systems are similar to SOA in that they have well defined and encapsulated interfaces. Also, UML diagrams most often used for OOA/OOD can be applied to SOA design. However, OOA/OOD is primarily focused on class design using a class hierarchy that supports inheritance. SOA is a loosely coupled model with higher level abstractions – at a business-service level versus a class level. SOA is actually more like component-based development (CBD). The CBD and SOA similarities include reuse through assembling components, interface definitions and loose coupling.

The path to SOA depends on your starting point in terms of skills and development approach. But, since the design goal for SOA is business service reuse and business process agility, it is obvious that the business users need to be more involved than in past development approaches. While use cases and activity diagrams can be explained to users, it is difficult to train users to use such tools to model business processes themselves or at times to even effectively collaborate with IT to model processes. Also, UML does not provide a means to analyze, simulate and optimize business processes. SOA will add little or no value if the underlying business processes are not improved.

1

• Next