This is Part 2 of 4 posts in response to a question from a former cohort, Chris, from the old days at a giant semiconductor company:

“Any thoughts on communicating just exactly what SOA is to mixed audience of technical and non-technical folks, and how it will help them?”

In the first post, SOA: What’s in it for me? Part 1 of 4: The Business, Bill discusses how to deal with business folks when it comes to SOA, which boils down to:

“Never sell SOA to the business outside the context of a business problem that needs solving.”

Of course Bill provides many other tasty nuggets so if you missed his post, I recommend heading over there first. In this post, I will be talking about SOA from the developer’s perspective.

We developers, absolutely love to solve problems using our own code. Many business folks, including my wife, think we can be extremely challenging to work with…and I will be the first to admit that they are correct, we often are difficult. After all, we live and breathe code, believing we can create anything and everything under the sun…yes, we developers have created the blue pill (think Matrix, not Bob Dole). Unfortunately this behavior can lead to close-mindedness. We often resist change; especially when it means writing less code and using someone else’s solution (code, tool, etc.). Don’t get me wrong, when we discover some sexy, new way way to solve our daily coding woes we are all over it! In other words, developers embrace new ideas so long as the ideas come from within. So what does this have to do with SOA?

SOA Means A Mindset Change for Developers

My partner-in-crime, Bill Draven, loves to use analogies so let me use one here to demonstrate my point. Let’s say I wanted to build a new house. If I wanted to build on a mountain-side, in the middle of no where, I would have a lot of responsibilities in addition to building a house. I would need to worry about all the infrastructure: roads, water, electricity, etc. This would obviously cost a lot of money and require a lot of additional planning consuming valuable time. This represents a completely custom solution where the developer is completely responsible for building the solution and potentially the supporting infrastructure. It should be obvious, like our analogy, this would require significant time, energy and money.

Going back to my analogy…another option I have, would be to build a custom house on a lot in a planned community. In this scenario, I could leverage existing infrastructure such as city roads, water, electricity and gas and simply concentrate on house and landscaping designs. This not only saves me time and money, but also puts my mind at ease on potential future maintenance issues with the core infrastructure. Say, if at 3:00 AM, bad weather brings down a power line, I don’t have to worry about fixing it myself or covering the cost for someone else to fix it. This analogy scenario represents a developer leveraging services (whether insider their organization or outside, aka software as a service or SaaS) to build their solution. Another way to look at this is, core features (with electricity to a lot or logging for a application) should be considered commodities. Most seasoned developers should not be excited about implementing (either by custom building or reusing their own) a logging solution. Most want to tackle new problems. To state this yet another way: most developers don’t want to deal with the science (repeatable problem patterns like security, logging, caching, etc.), rather the art (business/solution specific problems).

Once again, going back to my analogy…the final option I have would be to simply buy a cookie cutter house. In this scenario almost everything is done and decided for me, all I need to do is make some minor decisions like: what color carpet and paint, what type of appliances, and what kind of wood cabinets do I want. Out of the three scenarios discussed, this is almost always the cheapest, easiest, and fastest option. Can you guess how this relates to the developer? Yep, this analogy scenario represents a developer using an off-the-shelf product (whether commercial or open source). Most of the core features will exist, but a few configuration tweaks and possibly some additional modules/plugins can be created to build a solution.

I am certainly not naive (at least when it comes to architecture and development), there are certainly pros and cons to each of these scenarios, both as a home builder and a developer. Requirements and reason for building a solution in the first place will dictate which option is best for any given situation. However, these nuggets should be comprehended:

1. A developer should strive to spend most of his/her efforts on art not science.
2. Do not think of applications/solutions as 1 technology or 1 executable, rather a part of a distributed system and/or share services.
3. In grander terms: Do not develop solutions in isolation. There are always opportunities for reuse.

SO-A What?

Going back to my analogy, let’s say I’m building a custom home and decide that the standard door height of 6′8″ is not big enough for me, so I put in custom 7′ doors. This of course will make me very happy in the short-term, however, when it comes time to replace those doors I cannot simply go down to the local Home Depot and get a new door. I will have to go through the hassle of finding a place that can build me the custom doors which means extra money and time. Same goes for custom solutions created by developers.

Of course I am not implying that custom code is unnecessary and all developers better find new careers. Rather, the goal should be to leverage standards when possible and let requirements and existing options dictate when custom code is necessary. This is exactly where SOA comes into play. The whole notion around SOA is to leverage and implement industry standard, interoperable, reusable services (and this is not just limited to web services, other messaging patterns, like pub-sub, are included as well). Building a solution should be as easy as going to Home Depot and/or Lowes and/or Sears, picking out paint, doors, cabinets, appliances, etc. (again the science) which are standardized to work together. To make the house meet your personal tastes, pick out some custom artwork or take your own photos and hang on the walls. Likewise, the developer pieces together some reusable services (both infrastructure and code-based) and only develops custom code when necessary to achieve competitive advantage.

True, this change in mindset does not always come easy for developers. If you do come across a developer arguing that their completely custom solution is better, than ask them this:

“Do you think you can do a better job than Google (or some other leading SaaS provider) at their price point?”

To Chris’ comment: “developers rule the world, everyone is just domino effect”, the business (profit-centers) rule the world (and often carries the checkbook), so we developers need to support them in the most efficient, cheapest, and sound manner. This can no longer be achieved in isolation, the business needs change much too rapidly. Instead, the mindset must be to look after the greater good; identifying ways to build and reuse services for the enterprise whilst covertly skimming a fraction of a penny off each transaction into our off-shore accounts.

 Print This Post

Tags: Enterprise Architecture, Service Oriented Architecture, Software as a Service

This entry was posted on Thursday, August 20th, 2009 at 8:00 am and is filed under Architecture. You can follow any comments to this entry through the RSS 2.0 feed. You can leave a comment, or trackback from your own site.