Don’t try to understand SOA; just get it done!

  • Article

Last week I was at US National Architect Forum (https://www.architectforum.net,Vail Cascade resort, Colorado) facilitating roundtable discussions and architect panels. As expected SOA was a topic intensely discussed. The participating architects wanted to understand the other’s perspective of what SOA is and how to reach that utopian state. Even after several customer panel discussions and roundtables, I believe same confusion existed.

 

Majority of the enterprise architects (EA) believe that they had come across a panacea in SOA that can cure all the ills of the enterprise. However, the solution architects (SA) who need to move at the speed of the business believe that SOA is a wonderful concept but will fail because of its ignorance of the organizational dynamics and political control boundaries. Also, SAs think that the EAs are twice or thrice removed from the business and are creating high expectations in a theoretical vacuum.

 

It looks like EA and SA are trying to pull the same wagon at different speeds in different directions. Unless enterprise architects win the support of solution architects, SOA will be another failed experiment. So, in order for enterprise architects to win over solution architects, I feel that they need to do the following:

 

  • In addition to creation of  reams of documents around strategies and governance, they need to allocate time to coach solution architects to think strategic while acting tactical in the context of a solution
  • Instead of heavy handed governance, that will be applied to every application interaction, governance need to be at an optimal level so that, services will be created for right reasons and not for the sake of the so called SOA.
  • Respect the control boundaries (ERP, CRM, eCommerce, Sales, Marketing, etc.) and loosen the governance for intra control boundary services while tightening the governance for application interaction across the control boundaries – example, interaction between eCommerce and ERP or between Sales Tools and CRM.
  • Respect the fundamental architecture tenet – minimize the surface area when interacting with other applications. A solution architect is not going to like to build a service dependency when no SLAs can be guaranteed. So, EA has to ensure that SLA enforcement is a strong part of the SOA strategy and governance.
  • Don’t try to boil the ocean; try small and win the hearts and minds of one control boundary at a time.
  • Respect the economics of reuse. Architecting for widespread reuse requires more rigorous process than targeting the narrower usage scenarios. Organizational changes for charge-back mechanism are one good way of encouraging the development of reusable software. Until such time find other means of motivating the architects - institute awards for best reusable service, or medal for best SOA architect, give publicity in internal communiqués, etc.
  • Create an environment where EA is more of a mentor than a dictator standing in the way of SAs from delivering their solutions.
  • Help SAs understand the EA models and how a particular piece of functionality they are trying to recreate already exists elsewhere (of course brace for the next question from SAs – can the SLA be guaranteed?) and how fast they can deliver the solution by reusing the existing service.
  • Strategize the service discovery infrastructure so that, SAs can themselves understand what is out there.
  • Draw analogies between class library reuse and service reuse. Often solution architects think that their core strength (or the perceived core strength) is ignored when the EA totally focuses on services. To be fair to the SAs, even though the boundaries of reuse are manifested by service facades, it will still be the best of the breed object libraries and frameworks that will power the service implementation.

 

In addition to convincing SAs, convincing the business is another important factor in winning with the SOA strategy. Business often sees SOA as IT trying to clean up its own mess. So, make business understand why investment in reusable services is necessary. Explain them why a service oriented solution takes longer and costs more initially and how this strategy benefits them with the future business agility.

 

As many architects at the NAF were questioning (What is SOA? Or what is a Service?), don’t try to understand what SOA is but just get it done!

 

SOA is no different than the traditional information systems we had put in place with conscientious architectures.  SOA with its standardized contract formats like WS-* only makes life a lot easier. Because of the infinite possibilities SOA presents to us, all the dormant integration problems of the enterprise (inter and intra) hitherto deemed unsolvable now are on our lap. Instead of getting distracted by all these problems, pick a chunk at a time and solve while winning the hearts and minds of the business!

 

Cheers,

hanuk