I’ve just published a SOA book through Wiley Press and it is now available on Amazon (hence the catchy title for this post).  Woo-hoo!

The book was a ton of hardwork, but I am quite pleased with the result.  The aim was to address what I considered to be a significant gap in the marketplace — a pragamatic book on SOA that is more business oriented and less technology focused.  So I signed up Bibhas Bhattacharya as my co-author and set out to write such a book. There are vast amounts of resources available for techies that are interested in SOA.  There are even a fair number of resources available for managers.  If, however, you are a business leader, executive, or are actively trying to get the buy-in of one, where do you turn?  What resource is there to help you grapple with important questions like:

• What is SOA really about from a business standpoint?
• When is SOA applicable and when is it not?
• How should an organization go about adopting service orientation?

There are a couple of excerpts available for you to preview the content:

• Excerpt of Chapter 1 “SOA Primer”
• Excerpt of Chapter 3 “SOA Value Proposition”

When you get the opportunity to read through some or all of the book, I would really appreciate your feedback on the content.  I hope that many will find it to be a useful resource to facilitate pragmatic SOA adoption.

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.

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.

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!

Last month, Aberdeen Group released a report detailing the findings from analyzing the service orientation results over a period of eighteen months for approximately 400 companies. The analysis revealed a ‘deep division’ between enterprises that simply deploy ‘a bunch of Web services’ and those that take a more strategic and comprehensive approach to service orientation. A lot of great analysis of these findings has emerged within the blogosphere:

• Survey: Done right, SOA pays by Joe McKendrick
• SOA Beginning to Pay Off by David Linthicum
• Survey points to SOA pay off by Tom Jowitt

I’ll let you dig through the report as well as the above posts for more details, but I would like to highlight one interesting aspect of the report. Aberdeen identifies three classifications of SOA maturity that categorize the survey respondents:

1. Best-in-Class (top 20% of aggregate performance scorers) - Characterized by organizations that prioritize investments in education/training, architecture, SOA middleware and infrastructure, and processes aimed at measuring and tweaking performance
2. Average (middle 50% of aggregate performance scorers) - Characterized by organizations that have made minor investments in SOA middleware and infrastructure, very little in education/training, and have virtually ignored organizational performance measurement metrics for refining the enterprise
3. Laggards (bottom 30% of aggregate performance scorers) - Characterized by organizations that have made little to no investment in SOA tools or training/education, tend to deploy Just a Bunch of Web Services (JBOWS), and virtually ignore the importance of governance

Beyond just identifying and labeling these groups, the report provides some compelling metrics around how these three categories drastically impact the ROI realized from service orientation. For example, every one of the Best-in-class organizations saw a reduction in application development costs, compared with only 59% of Average organizations. Those companies identified as Laggards, however, actually saw an increase in application development costs. Similar trends were identified regarding maintenance costs and impacts to user satisfaction.

So the question remains – Are you a SOA Laggard?