SOA Transformation and IT Culture Shock

(Service Oriented Architecture)

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

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.

There are several ways to bridge the culture gap to SOA. First, IT can start to design and build services, governance processes, organizational skills and service's infrastructure in a bottom-up style. A bottom-up approach examines discrete applications and creates services specific to the application. The advantage of this approach is that IT can build their internal support mechanisms for SOA without exposing weaknesses to the business. The disadvantage is that SOA will not be focused on improving business processes and adding business value. The bottom-up approach is however often pragmatic when the learning curve to SOA is high.

A top-down approach builds a services catalog based on projects in the IT portfolio and strategic business drivers. Funded projects in the IT portfolio should be examined to determine if SOA will reduce costs and create business value. A SOA roadmap and services catalog is build based on core business processes, process effectiveness and business value. The roadmap is business driven, so the architecture is defined to support the business objectives.

When approaching SOA in a top-down manner with the goal of enterprise transformation, one must consider the current culture of the IT environment. The primary question is how collaboratively does IT work with the business to build systems? If the answer is not very, then a bottom-up approach is less risky.

IT can also start SOA in more of a Business Process Management (BPM) style. This can be accomplished by exposing the business to process modeling without an emphasis on services or enterprise-wide SOA transformation. For example, I recently worked with a client to understand and optimize their order to cash process. This involved traditional as-is/to-be process modeling with the intent on process optimization. As a result of this project several services where identified though process decomposition. We are now creating these services in more of a bottom-up approach without a great deal of visibility to the business at this stage.

Moving to a top-down, business driven approach quickly ensures that SOA generates value early in the rollout. Providing business value early creates momentum and further investments. However, exposing SOA to the business too quickly can result in early failures and disenchantment with the technology and IT's ability to deliver on the SOA promise. The initial approach should be based on the current IT culture and skills. Skills can be built using a bottom-up approach and collaboration between IT and the business can be improved through BPM techniques.

About the Author

During his more than 20 years of experience in Information Technology, Eric Roch has worked in roles such as executive level management, technical architect, and software development in top tier technology organizations including TIBCO Software (Director of Professional Services) and Deloitte Consulting. Recently, Eric served as CTO of a pure-play SOA consultancy and is currently Chief Technologist and National Practice Director for Business Integration at Perficient Inc. (NASDAQ: PRFT). In his role with Perficient, Eric develops strategic plans for business integration and SOA for Fortune 500 companies. He is also responsible for the commercialization of Perficient's methodology and software for SOA services delivery. As an IT industry speaker and author, Eric has been invited to speak at numerous industry events and written for leading industry publications. Eric earned his Bachelor of Science in Computer Systems from City University of Bellevue, Washington, and Master of Science in Management of Technology from the University of Maryland.

More by Eric Roch

About Perficient

Perficient is a leading information technology consulting firm serving clients throughout the United States. We are experts in designing, building and delivering business-driven technology solutions. We help our clients gain competitive advantage by using Internet-based technologies to make their businesses more responsive to market opportunities and threats, strengthen relationships with customers, suppliers and partners, improve productivity and reduce information technology costs.