Jason Lenhart

I have been lucky to work with many talented individuals who have taught me so much.  Mark Little is one such person that I had the fortune to work with/for.  I found Mark to always go out of his way to help a developer or someone establishing open source communities (no matter his busy schedule).  It is of no surprise that Red Hat would ask him to take the top development role.  I wish nothing but the best for Mark and I know his experience and approach to developing quality teams and software will shine.  Congratulations Mark!

http://triangle.bizjournals.com/triangle/stories/2009/03/30/daily12.html

http://bobbickel.blogspot.com/2009/03/mark-little-jboss-cto.html

In the last couple of days I was asked to build a presentation regarding lessons learned, observations, and recommendations for the last project I technically directed and managed (doing this with an excellent group of peers I helped to recruit). In general, it got me thinking about SOA and the decisions we were making both successful and lessons learned.

First off, I could not help but think back to the fanfare of the project kick-off (some 3 years ago), the term SOA being utilized in every presentation. Whether these presentations were presented to the greater organization or within technical/non-technical conferences — the term SOA was certainly overloaded in an extreme manner.

As the project progressed, one thing that remained was the fact that technical leadership never lost site of the core principles of SOA - more importantly how it is nothing new or exotic. As a published friend of mine stated:

“Companies have been ‘doing SOA’ for many years, even before the term was coined, using technologies as diverse as CORBA and JMS. Think of it as a pattern, or an architectural approach in the same way as distributed object-oriented systems. It has its place in any good architects toolbelt and we’re finally coming to grips with it as an industry.”

I have a tremendous amount of respect for Mark Little - and have always felt his opinions are “spot-on” (to steal a quote from Ocean’s Thirteen).

So why are we just now seeing large studies that indicate that SOA is not working in most organizations? I mean - it seems so fundamental that Organizations would want to achieve certain key benefits (a sampling of the key benefits I dug up in past presentations, re-termed by me in parenthesis):

• Leverage high levels of interoperability to seize new business opportunities (fancy term for ability to build composite applications)
• Customize/leverage existing assets (not have to start from scratch on every project)
• Be able to leverage a best of breed landscape for software, data, and infrastructure (knowing that changes in the environment have been properly abstracted or loosely coupled such that these changes can occur with little to no impact in the consumers)

So why is it not working — who or what would impede these benefits from happening? Certainly there is a cultural aspect to this question which I am not going to address on this post but I will offer a more fundamental approach to the model or architectural style that SOA promotes, as there seems to be little question that the core ideas behind SOA are the right ones (they have been around for decades) — this approach, I believe to offer large organizations a better chance at success.

I think the issue with SOA is how so many organizations/people have gone about the design and implementation . The architecture community loves to review ‘reference implementations’, so what would a great example of a SOA design and implementation look like? I don’t think you really have to go far to realize it — most folks are using these implementations in their daily lives. Google with all the Web APIs which tap into Maps and Data, or Amazon and their successful Web Services, or how about the new social phenomena of Twitter that is getting 10 times more use through its APIs than its interface. These are all outstanding implementations of SOA. Furthermore, it is even harder to argue their success when you begin to look at all the “software mash-ups” currently out there in the Global SOA.

Getting back to my retrospective - how come we do not see this level of success in the Enterprise? We were seeing success - but shouldn’t the rest of the organization be sharing in it? I guess these are questions I was coming back to in my head as one of the things I would often hear:

“Well if we could start over - and use any technology we wanted - seemingly had an endless budget - we would have that success as well”

I don’t believe that only new implementations (with tons of money) can enjoy the fruits of an SOA implementation done right. There is a sort of implication in that statement that SOA is tied to the technology. I disagree - lets go into deeper detail.

Going back to my ‘reference implementations’ on the web, I am of the belief that organizations are often aligned in a way that is fundamentally unlike the web. IT organizations have long been plagued as a ‘cost center’ rather than a strategic asset. Looking at the above examples it is clear that there is a focus on consumption and openness as key essential characteristics to building an internal partner ecosystem/community. There certainly was not a big-bang approach to their strategy but it fostered a community of growth that is returning higher levels of ROI. The large IT organizations I have consulted/worked within are very effective for their perspective class of business problems (mainly providing a long term safety of corporate domain knowledge and systems) - but when SOA is being seemingly shouted from the mountain tops like a Ricola commercial - by its very hierarchical organizational make-up across various LOBs weighed against varying consumer dynamics, consumption and then taking into account the lack of easy to process data, forest of relational databases, and silos of proprietary applications — openness and consumption take a backseat to bonuses, perceptions, and plain ol’ ‘get it out the door’.

I believe proper design and implementation can allow these sort of internal ecosystems to develop independent of the organizational dynamics. What I have found is that by not always taking the ’standards approach’ has yielded good bit of success. Most notably in the approach and delivery technique to allow openness and consumption - not letting this be forgotten or ignored in favor of:

• Security Department rants, confusing openess consumption as an attack on security

• Groups/individuals spreading FUD about ‘if you are not using WS-* you will be refactoring your whole codebase very soon’ - thus freaking out stakeholders

The concept that has worked best has been best coined by Nick Gall as Web Oriented Architecture (WOA). REST/WOA is placing the focus on the resources and not on the services which is often where we see all the SOA methodologies taking the people who are performing the implementation

By organizations allowing and fostering their organizations to adopt WOA at a grassroots level - the openness and consumption will naturally progress. How can I make such a lofty assumption? - I have both seen first hand and in some cases felt the pain of how this direction was/would-have-been the better decision. This is especially true when you see companies make acquisitions and want to bring their business onto your platform, incrementally. Some observations:

• Instead of a few point services that typically have a context of usage that the LOB could only use due to constraints like WSDL (yes I believe one of the core tenets of loose-coupling in SOA is broken due to WSDL) - enterprise data can be tapped into through REST based resources (just like the web), which will allow any application to consume via HTTP and XML. Note: Even higher levels of access can be achieved via syndication which establishes the openness.

• Open Web APIs - exposing data to customers will often get LOBs out of the presentation domain. Data is king in the enterprise, why must everyone provide a front-end to every piece of data in the name of:

‘I cannot have you just willy-nilly accessing our data’ — so a front-end justifies this?

ACLs can be appied to Web APIs as well. It is important to note that openess is not a code-word for the lack of security - these are orthogonal to the implementation.

Next to an organization’s people, data is the most important asset - it should be managed like a money-manager manages a portfolio. Treating the data as restful resources will inherently offer productivity gains via external frameworks and tools. From a management perspective - I believe that it is easier to conceptualize the make-up much easier therefore people will not get caught up in a federation of relationships. Also, I observed that making the data a resource offers the opportunity to better engage you business with the types of tools they use everyday. Thus offering a medium of collaboration that helps get the business-partners out of the ‘IT is a Cost Center’ mentality. The business folks are writing code every day (whether IT knows it or not they do) — it is untested code and placed into production immediately. A quality example of this is the explosion in use of spreadsheets to perform higher level functions - whole departments will build out templates and email them around, using them to perform activities whereby they do not have to explain to IT (e.g. accounting). My point is that more so than ever before - we in the technology community are blessed (and I use this term loosely) with a business community that is operating a higher level of competence around technology - they can conceptually bridge ideas into the digital domain much more easily. That said, with tools like blogs, wikis, twitter, widgets, etc… this should enable better adoption of WOA because you are driving the consumption of the resources through the mainstream.

Overall my observations - are best summed up in the following:

Like previously stated SOA is an approach that the greater community has come to grips with, conceptually it has been around a long time - but the benefits will take much longer for the enterprise to realize (across the board) as the current enterprise techniques lack in grass-roots support. Some assumptions in the design of services and implementation of standards should not be so basic to the organization. Techniques that have the by-product of openness and consumption; using WOA, are the ones to promote and implement.