In-source, out-source,
up-source, down-source,
crowd-source, cloud-source,
source, source, source.
At your work and on the street,
how many different sources you meet!

(Inspiration borrowed from multiple readings of Dr Seuss’s The Foot Book to my toddler).

It seems everyone these days is looking for a new ’source’ for making their business, civic organization, or personal life more efficient and/or more manageable.  I see two primary motivations for this trend:

• There is a seductive and ever-strengthening pull to join “The Cult of the New”
• There are genuine market pressures as well as social and economic dynamics that are solved by optimizing resource utilization

At this point, I am tempted to just end the discussion here and farm (code for ’source’) the rest of this post out to the blogosphere and let all of you solve it (I’m a fan of irony).  But I think I’ll go ahead and expend a few more brain cells and actually try and make a coherent argument of my own first.

The Cult of the New

If a technology, methodology, or other ‘-ology’ has two or more of the following criteria: shiny, has acronyms associated with it, has a magazine with the name in the title, has a conference dedicated to it, etc., then it is ripe for hype and for drawing people toward it out of the sheer momentum that it is THE thing to do!

The momentum around ’sourcing’ and in particular, cloud-sourcing certainly falls victim to this in many respects.  It is important to realize that the problems we have today as well as the solutions to those problems largely remain the same.  It’s not to say that there is nothing truly innovative, but it is to say that often times we repackage or even just rediscover a way of solving a problem and it is simply called something different or is applied at a different level of abstraction than it was when it was originally introduced 20 or 30 years ago.

There are genuine opportunities around sourcing / farming / distributing work across various resources.  But there are also real-world risks associated with doing so.  I’ll be exploring both of these themes in a webinar tomorrow afternoon. (Wednesday - July 22nd starting at 12PM EDT) - “Risks and Opportunities with Cloud Computing” I hope you are able to join in.

Resource Optimization

I certainly don’t want to give anyone the impression that sourcing needs out or offering capabilities in a flexible, distributed, even utility service fashion is necessarily a bunch of noise.  I do believe that there are genuine market pressures and economic realities that drive organizations of all shapes and sizes toward some sort of creative sourcing model.  Bruce Barnes supplied an excellent analysis of this in a CIO Update article earlier this month - “Smart Sourcing: The New Normal”. Bruce focuses upon effective vendor / partner management in this new world of smart-sourcing and he outlines 6 steps of managing this effectively.

In addition to effective vendor management, there are some essential steps that must be taken internally within the organization in order to truly manage resources and the sourcing of work effectively.  It all begins by taking several giant steps back and evaluating your business drivers to ensure that you are pointed in the correct direction to begin with.  From there, you must embark upon a process of discovery around internal needs and capabilities, external resources, provider service levels,  resource utilization metrics, and comprehensive enterprise portfolio management.

If adopting a cloud computing or similar multi-sourcing model of problem-solving is something you are considering, you may want to take a look at a post of mine from earlier this year (Adopting Your Very Own Cloud) where I explore pragmatic steps for evaluating and potentially adopting such an approach.

You and your team have had your heart set on achieving scalability, availability, reliability, and economical efficiency for some time now.  Over the years, you’ve tried everything you can think of to achieve these goals.

A Journey of False Starts

This is not the first time you’ve had your heart set on revolutionizing your information systems:

• One year, you rolled out a big Enterprise Application Integration (EAI) initiative, but it was too brittle and carried high maintenance costs.
• For a while you experimented with Web Services, but found that while they were easy to work with, they were largely insufficient to meet your broader needs due to a lack of architectural design guidelines.
• Out-sourcing, in-sourcing, up-sourcing, down-sourcing, and cross-sourcing just seemed to shuffle the work around and tended to result in the blame-game.
• You’ve bought every pill and tonic you could find (ESBs, network appliances, UDDI registries, load balancers, etc.), each with varying degrees of success.
• One crazy weekend you deployed a full-scale dynamic rules engine to fully automate decision logic, but this carried hidden costs and fell short of your expectations.
• Then you stumbled across this witch doctor who could abstract data, memory, processing power, and bandwidth through some wizardy known as ‘virtualization’.  While initially very promising, the startup costs and expertise required were obstacles that you simply could not overcome.

On the verge of losing all hope, you hear that this virtualization thingy might not have to be so expensive after all thanks to Cloud Computing.  Could it be?  Could you actually achieve your dreams of scalability, availability, and reliability, without giving your CFO a heart attack??  Could you actually adopt a Cloud of your very own?

Adopting Your Very Own Cloud

Adoption can be a scary process.  In your fear of doing something wrong, you may be tempted to buy a big, expensive consulting package and just have someone else handle everything.  You don’t need to do that.  Simply find a subject matter expert to serve as a mentor that can guide you through the process of pragmatically evaluating and possibly even adopting Cloud.  Along the way, make sure that this mentor is educating you and your team so that you are able to function effectively once this person has left the building.

Ten Steps to Successful Cloud Adoption

1. Identify your business drivers — What are you actually trying to accomplish from a business perspective? What are your enterprise initiatives, key objectives, and targets?  Look for growth drivers as well as risk mitigation drivers.
2. Get educated — What business opportunities does Cloud Computing present?  What are the advantages, disadvantages, and key factors that Cloud brings to the table? What cost models, value models, solution architecture, and infrastructure design changes are required in order to take advantage of Cloud Computing?  What impacts does cloud have at the enterprise, division, and individual project basis?  Throughout the adoption process, your mentor should provide education around Cloud, but at this stage you need focused attention upon the subject.
3. Articulate a value proposition — How do you see Cloud Computing supporting one or more of the drivers identified in the first step?  There are a variety of reasons that an organization might choose to adopt Cloud (reduce maintenance costs, scale support costs during peak system usage, support after-hours service requests, business continuity, operational risks, reduce capital expenditures, accelerate growth into new markets, improve business agility, and etc.).  Identify and clearly articulate the Cloud value proposition(s) for your enterprise that are applicable given your business drivers.
4. Define one or more scenarios — With an understanding of the value propositions that you are targeting, it is now time to get specific and define scenarios or use cases for applying Cloud Computing to address one or more of the business drivers previously identified.  These scenarios will serve as candidates for the initial Cloud adoption effort that your team will embark upon later in this process.
5. Produce a roadmap – Using an “as-is” and “to-be” modeling technique, identify the gaps that exist between the current state of your enterprise and the desired future state for capitalizing upon Cloud.  Next, define a roadmap that shows how to move toward that cloud-enabled future state.  It is critical that this roadmap include objective and measurable milestones for your organization to work toward.
6. Gain stakeholder buy-in — Throughout the adoption process, you will need to gain buy-in from various groups regarding this initiative.  It is particularly important to do-so after defining the roadmap and prior to actually moving forward with it.  From this point on your team will be drawing upon enterprise resources to establish governance, infrastructure, project personnel, and then deploying real solutions into production.  It is crucial that all impacted parties are on-board and ready to go.
7. Establish governance — Oh great!  Here we go again!  Why does everyone insist that we need to govern our business initiatives?  The answer is simple - people screw things up. Governance ensures that we are all playing from the same playbook (vocabulary, portfolio, models, architecture, standards, metrics, etc.) and that the enterprise’s target objectives and risk factors are duly consider and investments are protected.  Governance should be lean, focused, and ever-present.
8. Invest in infrastructure — Depending upon your adoption strategy, this may be very significant (server farm, policy manager and enforcement mechanism, load balancer, ESB, cloud gateway, etc.) if you are going to develop your own internal cloud or relatively simple (content-based routing proxy and possibly a service registry) if you intend to leverage an external cloud vendor.
9. Cloud pilot — The metaphor of a test pilot has been used consistently used for years to describe initial work done in a new area.  The fact that we’re now piloting through clouds opens up a whole new set of possible puns to play around with.  Setting those aside, the importance of proving out a single, definable test case that can prove out tangible value for your enterprise is essential.  As with other pilot initiatives, it is important that you carefully select from a candidate set of possible projects.  You need something big enough to count, but small enough to be successful. Your cloud mentor should assist in this process.
10. Enterprise roll-out — Provided that the pilot was successful, it is now time to move foward with the roadmap and look for additional opportunities to apply cloud solutions.  This may involve moving existing solutions to the cloud, consuming cloud services, or delivering brand new capabilities that have never existed.  Continue to expand the use of cloud within the enterprise so long as your solutions adhere to the governance guidelines that have been established, and they are consistent with your overall business drivers for the enterprise.

Cloud computing holds tremendous potential for both small and large organizations.  Adopting your very own cloud solution may seem daunting, but the maturing of service oriented patterns, practices, methodologies, and tools has brought cloud well within reach.  With proper guidance, your organization can evaluate the potential for cloud and pragmatically adopt it without breaking the bank.

Communities the world round celebrated Chinese New Year yesterday.  2009 is the year of the Ox, and with it comes new insight and possibilities into what the year holds for our world.  According to Chinese tradition, the year of the Ox represents “prosperity through fortitude”.  The Ox symbolizes that success will come to those that buckle down, dig in, and persevere through hardships.  In contrast, 2008 was the year of the Rat. The Rat symbolizes pioneering, cunning, ambition, and even a sense of entitlement.  There is a time and a place for everything, and the time for the rat and the need for the ox has certainly come.  Given the economic climate and the state of companies, governments, and organizations of all shapes and sizes, this is an apt and timely metaphor.

2008 was an exciting time for exploration and pioneering possibilities.  SOA adoption was in full swing, the virtualization discussion morphed into Cloud computing and took a prominent degree of mindshare in the process, and the Web 2.0 momentum transformed into an emphasis around enterprise mashups.  2009 presents a very different reality.  The time for pioneering and cunning must give way to the much more pragmatic and focused intensity symbolized by the ox.  It is time to buckle down, dig in, and solve real-world problems with SOA and its related initiatives.

Ox-inspired Tips for Success with SOA in 2009

• If you don’t have a real business case, you have NO business pursuing SOA.  Moreover, the business case should lead you to select SOA rather than selecting a business case to justify your decision to adopt SOA.
• Invest in SOA selectively this year.  Education and re-skilling will yield results almost immediately.  Governance investments will also bear fruit fairly quickly.  Investments in tools and infrastructure should be closely scrutinzed.  Over-hauling your high priority, mission-critical systems might be too risky (and expensive) at this point.  Developing an Enterprise Architecture (EA) framework and moving your enterprise to a canoncial data model might be best to put on the back burner for now.
• Cloud computing offers some really compelling possibilities, but the increased buzz around Cloud is hardly enough to warrant special attention.  There have been no revolutionary standards, tools, or platforms made available that have recently changed the game.  If you weren’t looking into virtualization, grid, or SOA before this year, it probably doesn’t make a lot of sense to launch out into Cloud right now.
• Develop fewer services that each provide clear and measurable value to the enterprise rather than developing a broad array of services in hopes of providing a catalyst for progress and innovation.
• Architectural layers and governance oversight must be value-added.  There are no bonus points for adding a service layer or additional governance requirement in the absence of a tangible value (this holds true for all project aspects, but architecture and governance are common culprits for excess).
• Develop services that meet their service interfaces.  Nothing more, nothing less.  This is always good advice, but the Ox reminds us how critical it is to avoid scope creep in the form of gold plating.

Opportunities exist for service orientation and the array of related initiatives (SOA, SaaS, Cloud, Mashups, etc.) in 2009.  The key is to ensure that real business value is driving your initial and continued adoption efforts, that you invest in education, and continue to prioritize governance to keep everyone focused on the goal.

The current economic climate and corresponding budgetary pressures are a sober reminder that the extravagence and excess over the past couple of years cannot continue indefinitely.  As companies announce layoffs and organizations around the globe rein in spending, it can be discouraging.  There is, however, a silver lining.  The Ox does not symbolize survival through fortitude, but rather prosperity through fortitude.  Invest cautiously, move forward with service orientation pragmatically, and you can certainly come out ahead in 2009.

The future is bright.

Be the change.

On a South Carolina campaign stop in January 2000, George Bush asked the immortal question: “Is our children learning?” Then again seven years later, Bush told a group of New York school children: “Childrens do learn.” YouTube video of both statements is available here. So I ask the question: Is our SOA learning?

As I think back on the SOA engagements that I have been involved in throughout 2008, the importance of education and skills development becomes crystal clear. I’ve blogged on the subject of SOA education many times. Of course others within the industry have also seen these challenges:

• Sober SOA (Chuck Allen)
• Re-think your SOA training strategy (Ronald Schmeltzer)
• IBM survey reveals SOA skills gap (Lorraine Lawson)
• Which will kill SOA fastest: no money or no skills? (Joe McKendrick)

At first glance, SOA education seems to be a fairly straightforward affair:

1. Get a couple of smart IT folks and have them do some research and self-education
2. Select an ESB vendor after detailed analysis and proof-of-concept work
3. Buy a block of training from your vendor
4. Implement SOA and rake in the ROI

The reality of the matter is a bit more complicated than this, however. SOA education must emphasize alignment with business drivers, effective governance, comprehensive solution methodology, and the development of new technologies and solution patterns. Vendor-specific training, while helpful, should come much later in the process, after there is a clear vision regarding service orientation and one or more vendor solutions are selected in alignment with that enterprise vision.

Complete SOA education

Rather than an ad-hoc training approach or one in which personnel are simply expected to “pick it up”, SOA education must be approached from a wholistic perspective. Complete SOA education involves three key elements: methodology, governance, and technical skills, all of which must be properly aligned with the organization’s business drivers and hence the ultimate motivation for enterprise SOA adoption.

In my next several posts, I will explore each of these three aspects of SOA education in more detail. Until then, feel free to get a high-level understanding of these concepts via a whitepaper I recently wrote with two of my colleages at Web Age — “SOA Training ROI”.

UPDATE: Joe McKendrick noticed the post and wrote about it here. In addition to having a great sense of humor, he also pointed out that Gartner had noted the lack of SOA skills and expertise in a report as recently as November.

Primitive man and woman were forced to adapt to their environment to survive. Animal hides for clothes, crude weapons and tools made out of stone or bone, and roots or berries for food (perhaps sabertooth steak or terradactyl ribs if company is coming over). Eventually, some nearby tribe discovers fire, but reports of fire-related injuries and property destruction lead our cave dwellers to avoid this new magic. These primitive humans are doing fine with their current capabilities and they are able to meet their basic needs without dabbling with such things. Over time the nearby tribe’s use of fire expands and one very enterprising woman invents pit fired pottery. The more primitive people have heard and seen the potential of this new breakthrough and are interested in using it. Alas, the obstacles to adopting this innovation are not trivial. They must learn how to create fire, handle fire cautiously, locate and stockpile flint and tender, develop fireproof tools, create fire pits, learn to craft with clay and finally develop a process to fire the clay pots successfully. Lack of education, skills, infrastructure, resources, and processes hinder their ability to progress. Perhaps the greatest barrier for these primitive people is fear of the unknown and risk of failure. Thousands of years later, we are faced with the same technology adoption challenges — education, skills, infrastructure, resources, processes, and fear.

Modernizing legacy information systems is not unlike the modernization efforts that have occurred for thousands of years. In fact, legacy or heritage systems are often referred to as ‘dinosaurs’. Correspondingly, the same types of obstacles must be overcome:

• Education — There is a mindset shift that must take place to understand the service oriented way of thinking. At first glance, services are just fancy objects. The reality is that service orientation requires a much broader, end-to-end view of the enterprise, complete with process-centric alignment, layered architecture, contracted interfaces, standards-based connectivity, and full life cycle governance. I have blogged about the alignment of service orientation and the unique qualities of SOA before. Also, David Ing has some interesting thoughts on service orientation.
• Skills — A well documented skills gap exists around service orientation. Joe McKendrick sites it as one of the two things killing SOA in 2008 and the guys over at ZapThink have been alerting the industry to the dangerous SOA skills gap for quite some time. Why is this? Service orientation skills cannot be acquired by attending a conference or reading a book (although I do have a book that I HIGHLY recommend). Academic learning as well as hands-on mentoring is required. Moreover, there are nuances to effective service orientation, service design, process alignment, and enterprise governance that require time and experience to develop. There are new technologies, design patterns, techniques, and methodologies that must be introduced and ultimately absorbed. This will require instructor-led training, research, hands-on mentoring, and practical experience to develop proficiency in these areas.
• Infrastructure — Contrary to popular belief, a service oriented infrastructure cannot be achieved by purchasing an Enterprise Service Bus (ESB) from a vendor and adding water. There are, in fact, a variety of infrastructure elements (service registry/repository, governance suite, business process engine, policy manager, policy enforcer, and etc.). There is a great little SOA infrastructure white paper that a consortium of vendors put together a while back. Additionally, be sure to avoid the trap of assuming that you need to have your SOA infrastructure fully mature on day one. Eric Newcomer has a great post from a couple years back regarding an incremental adoption of SOA infrastructure.
• Resources – There are several ways to slice the resource issue. For effective adoption of SOA, you will need a pool of human resources (with appropriate education and skills), technical resources (infrastructure, knowledge management and collaboration tools, as well as design and development tools), and you will need expert resources (developed in-house, or brought in from an outside source initially).
• Processes — All the education, skills, infrastructure, and resources in the world won’t amount to a hill of Java beans without effective processes for governing the adoption of service orientation. You will need processes for service selection, service design, quality assurance and testing, policy enforcement, and runtime service management. Effective governance can make or break your adoption of SOA. I have blogged on the importance of service oriented governance numerous times.
• Fear – People fear change. Service orientation appears threatening to many people at first due to the changes required in adopting it. New patterns of thinking are required around how to solve customer problems. Skills must be adapted, other skills developed from scratch. New infrastructure and resource pools must be created and processes must be adapted and new processes created. These changes can be intimidating. A considerable degree of people change management must be accepted as a part of a successful transition toward service orientation.

Service orientation adoption is challenging in its own right. It becomes increasingly challenging when you factor in the dinosaurs that must be modernized as a part of the adoption process. Immediately, questions begin to arise:

• What systems and/or business processes should be modernized?
• Should we migrate, expose, or leverage our existing legacy assets?
• Should adoption occur within a particular line of business or across the whole of the enterprise?
• How will modernization impact existing teams and project roles?

These questions and many more must be explored as part of the adoption of service orientation. I explored several of these topics in a recent public webinar - Enterprise Modernization and SOA Concepts (pdf).

Another resource you might consider is a new course that Web Age has been offering since April of this year. It is a two-day workshop that explores the modernization of legacy applications, SOA concepts, modernization challenges and risks, and various strategies for modernizing legacy systems. It is aimed at team leads, architects, managers, and legacy application support personnel. For more details, check out the course details - WA1657 Application Modernization and SOA Concepts.

Adopting service orientation and “moving out of the Stone Age” is not a simple task. It requires intentional allocation of time, energy, and resources. It cannot and should not be approached in an ad-hoc fashion. Technology adoption has always been challenging, just like when ancient man and woman adopted fire. When it comes to service orientation, be sure that you work through the necessary steps of adopting education, skills, infrastructure, resources, processes, and addressing the fear factor. Otherwise, you just might get burned.

For those of you out there championing the cause of service orientation, the title of this post may catch you off guard. Likewise, casual observers of the service orientation movement might assume that developing services for reuse is the norm. Believe it or not, my title is not ironic, sensationalized, or tongue-and-cheek. I honestly believe that given the way most enterprises have established SOA, only a fool would build reusable services. Why might you ask? Simple. Rational self-interest.

What does rational decision-making have to do with adopting service orientation and developing services for reuse by others? I’m glad you asked. The simple fact is that the creation of services as reusable rather than one-off solutions is not free. Experts peg the expense of creating reusable solutions anywhere from base cost +30% to base cost +200%. It is significantly more expensive to build for reuse. On the flip side, it is considerable less expensive to reuse an existing service. Experts peg the expense of reusing a solution rather than creating one from scratch to be anywhere from base cost - 80% to base cost - 20%. In short, developing reusable services is very expensive, but once you have reused a service multiple times, a return on your initial investment will emerge. I blogged about this several months ago (SOA ROI, deconstructed) and provided a link to a whitepaper that explores this subject in more detail.

From an enterprise perspective this all seems very logical and the additional investment is easily offset by the value of the reuse over the long term. The problem is that in the short term, rational self-interest will drive individuals to never develop reusable services.

Consider the following scenario:

Bill is a project leader and is creating a service oriented product portal. He realizes that several of the services he needs could be designed in a fashion to foster reuse. As a good citizen of the enterprise, he directs the team to design these services in a more flexible and enterprise-centric fashion. Additional effort is spent during design and potential enterprise customers are interviewed regarding their potential needs. The added cost puts a strain on his budget but is certainly the best answer for the enterprise overall.

Sharon is another project leader in the same division as Bill. She is creating a product reporting application. She discovers that several of her requirements can be met by simply reusing the services created by Bill’s team. Other services that she needs are then developed as unique, one-off services to contain costs. Sharon uses a fraction of her budget to produce this solution, freeing up resources to meet other goals for the year.

At the end of the year, both Bill and Sharon will be judged based upon what they were able to accomplish with their respective budgets. In the absence of some acknowledgment of Bill’s contribution to the pool of available services or similar affirmation of Bill’s decision, then he is in hot water. Sharon looks like a hero and Bill comes off as a fool. Knowing this, Bill will be less likely to develop reusable services in the future (unless he can directly benefit in a very short timeframe).

Adopting service orientation and encouraging reuse is great, but what will compel divisions and individual project teams to actually play ball? In the absence of some sort of incentive structure, charge-back mechanism for using services, or similar recognition for contributions to the greater good, no one will develop reusable services. Rational self-interest will drive each group and each team to develop services that only help themselves and which will, in effect, re-create the same silos that we are trying to supplant.

All of this points to a very real gap that exists within many enterprises that are adopting or at least exploring SOA – lack of business buy-in. Someone within the business needs to recognize the true cost of SOA and put in place some sort of incentive structure to encourage teams to contribute to the greater good of the enterprise. SOA is not a short-term, quick-win approach. It requires strategic planning and long-term investment windows.

So what if you have no business buy-in? Are you sunk? No. You may not be able to get traction around reuse, but you can go for ease of integration, the benefits of standardization vs proprietary solutions, lower maintenance costs due to the loose-coupling that SOA offers, the configurable nature of services and process, and other benefits that do not depend upon long-term reuse time windows.

Adopting service orientation requires a considerable amount of strategic planning and up-front design work. There are a variety of business drivers around SOA and reuse is certainly a popular one. Is it foolish to develop reusable services? It is if you attempt to do so within an organization that is not viewing things strategically or is unaware of the long-term impacts of service orientation. In the absence of business buy-in and strategic incentives, only a fool would build reusable services.

I’ve been on the road a lot lately, working with various clients, writing courseware, writing articles, and basically doing everything EXCEPT for blogging.

Here’s some of what I’ve been up to:

• Article: SOA Governance: Start Small and Build Incrementally (published March 6th by SYS-CON)
  
• Presentation: SOA Adoption Planning (1-hour seminar I delivered in February)
• Presentation: Delivered a virtual presentation for the Dallas SOA Users Group. I had a client engagement in Calgary, so we tried out a virtual delivery and it was quite successful.
  
• Book: Service Oriented Architecture: A Field Guide for Executives (August 2008, Wiley Press)
• Courses: Updates to various courses plus new courses coming soon for Project Managers, Mainframe and Legacy Personnel, and some Best Practices content. For more information, check out Web Age’s SOA curriculum.
• Web-based SOA Training: I’ve been working on a new offering at Web Age in which some of our content is made available as recorded, flash-based audio/visual presentations that can be hosted internally within an organization’s intranet. More details to follow.

I’m going to try and be more diligent about blogging in April. I especially hope to share insights and perspectives that I glean from the IBM SOA IMPACT conference in Vegas. I’ll be attending that conference in early April and conducting a Birds of a Feather session on governance.

A rose by any other name would still smell sweet, just as a strategic corporate initiative is no more or less successful due to its use of certain en-vogue terms such as Enterprise Architecture (EA), Business Process Management (BPM), and Service Oriented Architecture (SOA). I was struck by the realities of the semantic terminology game that we play while attending the Open Group’s 17th Annual Enterprise Architecture Practitioners Conference in San Francisco last week.

There was a general consensus at the conference that there are common themes running throughout enterprises that have various labels attached. Those themes include the following:

• Business and IT need tighter alignment
• Visibility between business and IT should be increased
• Governance is needed at various levels of the organization to reduce risk and protect ROI
• Business processes and technology solutions should be more flexible and better able to adapt to changing demands
• Business processes and technology solutions should be designed intentionally and with sufficient rigor

The labels attached to these trends vary from enterprise to enterprise. Some drive toward one or more of these goals under the EA umbrella, others under the BPM label, and still others are talking about SOA. Some organizations use two or even all three labels. Regardless of the attached label, it is a strategic initiative at the business unit or enterprise level that aims to improve business predictability and squeeze more value out of technology investments. This become readily apparent as the SOA Governance panel (other panelists included Michael Nassar of IBM, Stephen Bennett of BEA, and Mats Gejnevall of Capgemini) that I participated in last Tuesday was quickly challenged by the audience to delineate between governing SOA and governing EA. The line between these disciplines is quickly blurring within many enterprises.

So what’s the take-away for us? We need to look past the labels that are applied and take a more business-focused and goal-oriented approach to education, mentoring, and ultimately solution development. We need to probe more intently with our clients to discover their strategic direction, business drivers, and objectives for one-year, two-year, and five-year timeframes. We may have the perfect service offering for them, but because it is labeled as SOA, BPM, or EA, it may not jive. I have several examples of this:

• Back in November, I wrote about Synovus, a mid-sized bank in the southeastern US, that spoke at SOAWorld in San Francisco. They were a non-traditional case study in that they did not set out to adopt SOA. They just knew that they had various business problems that needed to be solved. They set out to solve those problems and in the process created a SOA. If someone had approached them a year or two ago with an offer to enable their enterprise through SOA, they would have dismissed it because they were not doing ‘SOA’, at least not in name.
• Last year, a US Department of Defense (DOD) agency participated in one of my SOA governance workshops. Several of the students made the observation that although we had originally set out to talk about SOA governance, the vast majority of the concepts, principals and best practices that we discussed were applicable to EA. The mentoring engagement quickly broadened in scope and we began speaking in terms of governing the enterprise and aligning with business strategy. The principals, methodologies, and best practices all flowed very nicely into this broader scope. The ‘SOA’ label that we had begun with was immaterial to the objective — better governance of enterprise assets and business processes.
• Throughout last year Web Age Solutions worked with various clients that wanted to service orient their enterprise assets and orchestrate those assets as a part of executable business processes. Some of them called that SOA, others called that BPM. Some wanted us to describe SOA in the context of BPM and others wanted us to introduce BPM in the context of SOA. At the end of the day, the solution was the same. It was the same standards, same tools, and the training was about 90% the same. The difference was found in the labels attached and the emphasis upon certain key concepts.

It is imperative that we understand our client’s needs, perspectives, and bias with respect to trends and labels. At the end of the day, we are enabling them to solve business problems, not in order to check a box next to an acronym.

“SOA is fine, unless of course you want a system with decent performance.”
“XML is slow and all the added layers that SOA demands will cripple any marginally high-transaction system.”

I’ve heard uneducated statements like these, and many others regarding SOA, XML, and the prospect of service orienting high performance, mission-critical systems. The truth is, that these statements are ill-informed and those that make them rarely have anything beyond vague anecdotes from “some Fortune 500 company a few years ago” to back them up.

Generalizing SOA

First, we’ll start with some broad sweeping generalizations regarding SOA. These have some truth to them and do, in fact, characterize a typical utilization of SOA. In general, SOA is realized as follows:

• Multiple layers of abstraction
• Standard XML message format (typically SOAP)
• Standard Web transport (typically HTTP)
• Non-reliable (no guaranteed delivery by default)
• Oriented more toward reuse and agility rather than performance or scalability

Breaking the perception barrier

There is more than one way to skin a cat and there is more than one way to implement SOA. HTTP is simple and cheap, but not robust or performant. HTTP-based SOA’s are certainly the most common as they are simple to setup, simple to exploit, cheap, and widely available. The problem is that HTTP isn’t reliable, suffers from high latency, has limited bandwidth, and does not offer any sort of message buffering or message durability. High performance SOA solutions must take a different approach. Messaging middleware solutions such as IBM WebSphere MQ, SonicMQ, or TIBCO hold one answer. These platforms are designed with scalability and performance in mind and are increasingly supporting SOA right out of the box.

High Performance SOA

Designing a high performance SOA solution is possible. Gerardo Pardo-Castellote, PhD, recommends the following steps:

• Select a Messaging Fabric/Bus
• Select an appropriate Architecture (hub-spoke, clustered, federated, peer-to-peer)
• Identify Quality of Service requirements (reliability, latency, flow control, lifespan, history, transport priority, etc.)
• Leverage Performance Technologies (multicast, message batching, asynchronous writes, compression, etc.)
• Select and monitor appropriate Metrics (throughput, latency, scalability, etc.)

Still skeptical? Consider the following examples:

• Network Management example
• Data Sharing example
• Data Fusion example
• Emergency Response example

As with so many things, there just is no simple answer. The only absolute is that there are no absolutes. SOA is a style of enterprise architecture for which the focus tends to be more upon flexibility and reuse. However, to the extent that solution performance is a priority, the architecture can be tweaked accordingly.

For further reading on this topic, I suggest the following:

• High Performance SOA (Jason Bloomberg)
• High Performance SOA - A Contradiction in Terms? (Patrick Leonard)
• Implementing a High Performance SOA (gridwisetech.com)
• High Performance SOA with Software Pipelines (Cory Isaacson)

I spent much of the second day talking with attendees, speakers, and SYS-CON staff about SOA, virtualization, and the conference in general. Overall, there was a general sentiment that the conference was a success and had some valuable content. One presentation from the day that really stood out was a case study from the banking industry — Delivering Big Bank Solutions with Community Banking Intimacy. The bank is Synovus, a regional bank in the southeastern part of the US with about 33 billion in assets spread across multiple lines of business (banking, financial management, brokerage, insurance, and more).

In a thick southern, ‘good ole boy’ style delivery, the speakers from Synovus described their approach as ‘Blue Collar SOA’, explaining: “…it may not be perty, but it works and we get a lot of value out of it.” The Synovus representatives went on to explain that while they did not set out to deploy a SOA solution, their business requirements and technology objectives led them in that direction. They went on to describe several keys to successful SOA adoption, including the following:

• Define and document a set of guiding principles
• Define and document a reference architecture that is consistent with those principles
• Identify standards, technologies, and products that can enable that architecture and communicate and manage this through governance
• Identify a business visible pilot project to convert the strategy and reference architecture into a real implementation
• Define and enforce the implementation strategy through governance processes
• Employ governance toolsets to validate services against guiding principles as well as policies and SLAs

The results of their SOA adoption as well as the importance of service orchestration is outlined in a white paper from Active Endpoints (their service orchestration partner).

The presenters concluded by identifying a huge list of lessons learned. Three things really stood out to me on that list:

1. Identify and document standards and best practices and enforce them through your governance processes
2. SOA changes your team dynamics — you will need more documenters than developers
3. Education is key because SOA is hard

That third one was especially of interest to me given Web Age’s focus upon SOA education. In the Q&A portion I asked for the folks from Synovus to elaborate on the education topic. They were eager to explain that they had discovered a huge gap between legacy skill sets and what it takes to be successful with SOA. They had to figure out how to translate those skills, bring people up to speed on new methodologies and terminologies and get people to think differently about how to solve problems. Synovus also discovered that considerable education and mentoring was necessary to help the leadership that direct their lines of business to “think outside their silo”. Amen!

At Web Age we have seen the same sorts of challenges and often discover that teaching the technologies is fairly simple. Teaching the methodologies is more difficult. Teaching the new mindset (e.g. ‘thinking outside the silo’) and providing business users with new tools and techniques for solving problems is even more difficult. So what is the most challenging? Getting organizations to actually change once they are educated. The technology side of SOA is relatively easy. The human side is where things get tricky.

Overall, the conference was a great experience. If you get a chance to catch the East coast or West coast shows next year, definitely go. I hope to see you there!