Addressing SOA Adoption Challenges

In my previous blog, I used a multi-chasm adoption curve to show the common challenges companies are having adopting SOA. For this blog I thought I would highlight the disciplines and focus areas to address each chasm and its associated challenges. As always with generic models there are exceptions but the following image highlights key focus areas. View larger image

 SOA Adoption Curve - Requirements

During a presentation in BEAWorld 2005, while speaking about SOA Governance, I coined  the term “Right-Click” architecture to highlight that integrated development environments had matured to a level whereby creating web services from existing components was virtual effortless. But this convenience factor allowed Technology Enthusiasts to develop and deploy large amount of web services and declare that they were executing SOA. For these Technology Enthusiasts to cross the "SOA vs. WS Chasm" they must understand the difference between a Service Oriented Architecture and a Web Services Architecture. SOA Education is key to not only developers but all the way to the company's senior management. Management and architects must understand that SOA is not purely a technology play but encompasses aspects such as IT/EA strategy and governance . Until both understand this then the majority of the benefits that SOA offers will not be realized.

Early Adopters have to cross the "Enterprise & Governance Chasm" to address the risks of deploying SOA across multiple lines of business. There are just as many risks as there are benefits to SOA and unless a company has an appropriate risk plan then a company will struggle to see the benefits they saw when SOA was within one line of business. Maybe in future blogs I will document the major risks that I have come across but I'm sure you have heard or seen "Service Sprawl". Service sprawl is when 100’s of services have been deployed and there are no consumers of these services or there are dozens of services with virtually identical functionality. These visionaries must understand that technology is an enabler and not the final solution. I have seen many companies buy or build a service registry to address the Service Sprawl issue only to end up with a catalog of services that are still not being consumed. Early adopters require a number of enterprise SOA disciplines to address or alleviate these risks:

  • SOA Governance Strategy - To address enterprise SOA risks otherwise early adopters may end up with multiple silo-ed SOA solutions.
  • Enterprise Service Engineering Framework - To provide an engineering methodology that is applied to building SOA assets through the implementation of projects. This allows organizations to build business value at the same time as adopting SOA
  • Enterprise Modeling for Service Architectures - To provide a a modeling framework that provides a repeatable and pragmatic approach to facilitate downstream service engineering, such as planning, analysis, and designing of services. It should complement both enterprise service engineering frameworks and traditional architecture/modeling frameworks to provide a simplified view into an increasingly complex SOA environment and assists in the transition from the current environment to the planned future vision
  • SOA Instrumentation - To focus on the post deployment aspects of SOA including collecting, aggregating, collating, and presenting key performance indicators to improve engineering, operational, and the business aspects of SOA.

Pragmatists are risk averse and thus tend to purchase their products from known SOA focused vendors with a reputation of providing quality, stable and mature products. These vendors should have a SOA methodology that allows them to appreciate that an SOA initiative does not have to be a high-risk proposition and that SOA can be delivered in an evolutionary manner via an incremental and measurable approach.  To cross the "Best Practices & Patterns Chasm", pragmatists need to learn best practices and patterns from the early adopters and to have detailed case studies and references from companies within their own industry. BEA has always been an innovator and therefore has attracted a large majority of the early adopters in the telecommunications and financial markets, which leads to BEA having a large number of case studies and references which the early majority require. A sample of these case studies can be found here If you can make it I would recommend going to the BEA World conference this year which starts next week in San Francisco then onto Barcelona and finally Shanghai. At the conference you will see many customer case studies, best practices and patterns.

The Late Majority represents the second half of the mainstream market and is known to be very conservative. These conservatives tend to hold off any technical major decisions and tend to be followers. Therefore for the late majority to cross the "Business Case Chasm", they will wait until SOA hits the bottom of the hype curve and up towards the slope of enlightenment.  The two key areas to assist with crossing this chasm is Education and SOA Business case development.

  • Education is key to the conservatives, especially around SOA Costs & Benefits and the differences between SOA and traditional costs and benefits. i.e. SOA ROI should not be measured in one project, but over a series of projects, requiring organizations to have line of sight for both future services and project portfolios.  To understand how early adopters executed SOA financial justification,  where they see the costs and benefits and the most significant roadblocks, there is a concise independent research study of SOA decision makers that will give you valuable input into your SOA justification process.
  • Conservatives need to a business case that is specific to their organization rather then taking a boiler-plate example and plugging in numbers. Companies should focus both  on the savings through reuse of services and the business agility that SOA can give the business. For example, getting a product to market 3 months earlier is worth what to an organization? For a better understanding of the key metrics for determining the ROI of SOA through Reuse there is a white paper that can be downloaded here

Skeptics need to cross the "Hype vs. Reality Chasm". Again Education is key to the Skeptics in detailing the differences between component reuse and service reuse but also to understand that SOA is not just a technology play but requires additional IT disciplines to be successful such as Governance, Portfolio Management and Agile Methodologies. Some laggards will wait until SOA hits its adoption peak and then try and play catch-up with their competitors. This could be a very expensive and disruptive proposition as SOA requires a culture change which in-turn requires time to feed in some learning experiences. As time is of the essence for laggards this imposes more pressure on the laggards as they try to speed the culture changing process through. So the laggards actually have a higher chance of failure. Some people have stated that SOA is in the “Trough of Disillusionment”, I do not see this as a negative but as a positive, as the focus will now move away from the marketing aspects and onto the real delivery of SOA. SOA will shortly move towards the “Slope of Enlightenment”, which signals that the late majority and skeptics will be ready to start seriously implementing SOA. This will bring the late majority/skeptics into the SOA mainstream and makes me believe that the next 12-24 months we will see a significant jump in SOA deployments across all major industries.

“How do you see yourself? Innovator, Early Adopter, Early Majority, Late Majority, Laggard”

Reviewing the following questions should give you an indication:-

  • “Is your industry known for innovation?”
  • “What does your company try to achieve?”
  • “Do you require extensive business cases with detailed ROI?”
  • “Does your company have a history of innovation?”
  • “Do you fully understand the Organization & Governance aspects of SOA?”
  • “Do you realize that SOA is not a pure technology play?“


Post a Comment:
  • HTML Syntax: NOT allowed

Enterprise Architecture Musings


« July 2016