Immediately after the conference last month, I got caught up in vacation and then working with a couple of new clients.  I’m back in the saddle now, and wanted to share some of my experiences.

The SOAWorld conference was very well attended, including the co-located events: Virtualization World and Data Services World.  I was a bit suprised to see that so many of the presenters were vendors rather than customers or practioners.  If this had been my first SOA conference, this would be a red flag for me that SOA is still just a lot of hype.  As it was, I just found it rather odd and a little more of an empty experience than I have come to expect.  Otherwise, the conference was great and it was quite encouraging to see so much energy around things like SOA and Virtualization in spite of the state of the economy.  This gives me great confidence and reinforces a belief that I have held for some time now, which is that SOA and Virtualization make good economic sense.

My portions of the conference went fairly well.  On Monday, June 23rd, I delivered: “A Composable Service is a Good Service”.  The room was packed and that presentation was extremely well received.  The audience was very engaging, shared some of their own war stories and asked for insight on particular service design dilemas that they have been dealing with.  On Tuesday, SYS-CON staff contacted me and asked if I would be willing to step in for a speaker that would not be able to attend.  I accepted, and delivered: “A Little SOA Goes a Long Way” (my SOAWorld presentation from last November).  I also had the pleasure to participate in two expert panels, one of which was held in the Reuters studio in Time Square.  When one or more of those videos become available, I’ll be sure to provide a link.

Presentation deck downloads: “A Composable Service is a Good Service” (PDF)  and “A Little SOA Goes a Long Way” (PDF)

One final comment about the conference is that there was quite a bit of buzz about virtualization as well as “cloud computing”.  I’ve paid a little bit of attention to the virtualization movement, but thus far I have completly ignored cloud computing.  None of my clients are talking about it, and it may all be vaporware (let the cloud-related puns ensue), but it has sparked my curiosity all the same.

Up until now, there has been such a rush to roll out initial SOA services and supporting infrastructure, that little attention has been given to what good service design truly entails.  This is a natural evolution that must occur with any technology or methodology.  Throughout this summer, I plan on releasing several posts regarding proper service design.

Initially, I would like to focus on the subject of ‘composability’.  Composable services have several important qualities:

• composable services stictly adhere to their service interface, Service Level Agreements(SLAs), and supporting metadata
• service operations always leave enterprise data in a valid business state
• service operations can be called indepently, in parallel, or as a part of a larger service orchestration
• service operations can be called within or without a transaction context

When you boil it down to the essentials, composable services clearly define what they do and they do exactly what they have defined.  Consumers of composable services are then at liberty to determine how they want to use that service’s operations, rather than the service having certain built-in assumptions regarding how the service will be used or what the larger business context ought to be.

To learn more about the merits and details of composable services, I recommend the following resources:

• “Composable Services” (MSDN Library)
• “Service Composability” (SOAprinciples.com)
• “A Composable Service is a Good Service” (Presentation at SOAWorld 2008 next week)

There’s another, less tangible benefit of composable services — they are lower stress.  The frustration and stress associated with consuming a service that later fails due to some unknown buisiness logic violation is supremely frustrating.  Consuming services that are not composable is stressful, because they cannot be depended upon to work in whatever context you choose.  Likewise, publishing non-composable services for consumption is stressful because the service provider is constantly in fear that someone will ‘misuse’ a service.  This is no way to run an enterprise or encourage the adoption of service orientation. 

I’ll explore all of these topics next week in my presentation at SOAWorld on composable services.  I’ll post the completed presentation as well as perspectives from the audience next week.  Have a great weekend and I’ll see you in New York!

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.

Over the last couple of months, I’ve been focusing quite a bit on helping people think about how much SOA they really need to address their business objectives. It turns out that you can, in fact, have too much of a good thing.

In November, I spoke at SOAWorld in San Francisco: “A Little SOA Goes A Long Way”. Then in December, I was interviewed by Jason Bloomberg and David Linthicum of ZapThink fame: “How Much SOA Do You Need?”. The presentation is available as a video webcast and the interview is available as an audio podcast.

“A Little SOA Goes A Long Way” (video webcast)

“How Much SOA Do You Need?” (audio podcast)

Additionally, my upcoming book (Wiley Press, Spring 2008) devotes an entire chapter to the subject of right-sizing SOA.

Have any experiences to share regarding how much SOA is just right and/or too much? Feel free to comment and discuss!

The first day of SOA World 2007 - West went very well. Miko Matsumura with Software AG / webMethods kicked things off with the keynote - Time Oriented Architecture: Evolution by Design? And he had some really entertaining 3-D animation and virtual simulations in his presentation. It was pretty cool. The next presentation in the main room was by Theo Beack from BEA - Virtualized SOA: Adaptive Infrastructure for Demanding Applications.

I delivered the third presentation of the day in the main room - A Little SOA Goes A Long Way, discussing the importance of identifying which aspects of your enterprise are ripe for service orientation and which areas are better left alone. The outline for that presentation is as follows:

• Introduction
• Why SOA initiatives fail
• What my kids taught me about SOA
• Adopting SOA selectively
• Bowling for governance
• Review

This presentation seemed to be well-received and I was particularly pleased with the broad acceptance of the Selective SOA Methodology that I presented. This methodology serves as the cornerstone for much of the SOA Adoption and SOA Governance mentoring that Web Age Solutions provides to clients. If you’d like a copy of the presentation, you can download it here — A Little SOA Goes A Long Way (PDF).

After a trip to the Expo Floor and some snacks, we were back in the main room to hear from Mike Pellegrini from Active Endpoints presenting - Your SOA Needs BPEL For Orchestration. He had some great content, but one nugget really stood out to me early in the presentation. Mike was describing services and processes as two kinds of abstractions that are important in SOA. After discussing them separately, he offered the following synthesis: “Services don’t change often, but they are orchestrated and re-orchestrated fairly often to build/modify business processes.” I like that. I would qualify it to say that services SHOULDN’T change often. In other words, I believe that this is indicative of an enterprise that has reached a considerable degree of maturity in their service orientation. Nonetheless, I thought it was a really solid characterization of services and processes.

Following Mike’s presentation, the speaker that was slated to speak in the main room could not be located. After hunting for about ten minutes, SYS-CON got desperate and accepted my offer to deliver another presentation that I had on my laptop. So I hopped up on stage, grabbed a mic, and fired up my laptop with the same presentation that I had delivered at SOAWorld in June early this year in New York - Service Oriented Patterns and Anti-Patterns. Fortunately, I had delivered that presentation about a month ago for a users group in Dallas, so I wasn’t completely unfamiliar with the material. I was a little rushed for time due to the late start, but overall that presentation went rather well.

After a lunch break, Ian Thain of Sybase presented - Model-driven SOA. His presentation included some interesting demonstrations of model-driven SOA using Sybase tools. Next was another Expo Floor break and snacks, followed by the SOA Power Panel.

I had the pleasure of participating on the SOA Power Panel along with Miko Matsumura (Software AG / webMethods), Kevin Hakman (TIBCO), and Sandy Zylka (NextAxiom). Jeremy Geelan moderated and we had some great discussion around SOA, convergence with other trends, economic impacts, and more. The panel session was recorded and I will post a link to it once it is made available.

I don’t know what happened for the rest of the day as I was occupied by various discussions in the late afternoon and then in a bit of sight-seeing in the evening (Coit Tower, Treasure Island, Lombard Street, and more).

I’ve been traveling and teaching a lot since the SOAWorld conference. This past week, a couple of my students challenged me on some statements that I made during the course regarding the notion that Microsoft has arrived a bit late to the SOA table. I find this particularly interesting considering the fact they Microsoft was so instrumental in the early Web services innovations around SOAP, WSDL, etc., but it seems that they have gotten distracted with lawsuits, Office, and Vista, and taken a while to come along with a comprehensive SOA story and supporting infrastructure.

After some interesting and sometimes heated discussions, these students points me toward some resources that shed some interesting light on what Microsoft has been working on. I must admit that I had lost track of .NET 3.0 and the evolution of Indigo into the Windows Communication Foundation (WCF). The work that Microsoft has done in this arena is quite impressive and, in true Redmond fashion, elegantly simple. Additionally, one of the students turned me on to Juval Lowy, who has been recognized by Microsoft as a Software Legend and a Regional Director for Silicon Valley. Juval is the brains behind IDesign, a great resource for .NET 3.0, and provides master-level workshops on .NET 3.0 and especially the WCF. The guy is brilliant, has a fascinating perspective on SOA, and a rather compelling and authoritative delivery style. To get a taste you can check out one of his MSDN Webcasts: Applying Service-Orientation to Your Development Process.

On a parallel thread, I ran across an interesting article from Redmond Magazine: “Microsoft Does Have a SOA Strategy“. Dana Gardner, who is quoted in the article, blogs on this subject and describes the strategy as ’service-enabled’ and ’sorta-SOA’. Another analyst quoted in the Redmond article describes Microsoft’s strategy around SOA as ’standards-based at the edge’. The article also identifies that Microsoft is focusing more upon empowering individuals and small teams rather than ’selling a big, fat SOA stack’. This is certainly consistent with their strategy in other areas of the enterprise. The reality of, course, is that Redmond will not sit idle while the IBMs, Oracle’s, and SAPs of the world carve up the enterprise marketplace. More infrastructure components are coming from Microsoft in the next iteration of Biztalk and the full realization of .NET 3.0, especially the Workflow Foundation (WF) piece.

One final thread regarding Microsoft’s SOA strategy is an apparent attempt to take the ‘ESB leadership’ that the big Java vendors have managed to secure in the industry and turn it around as a liability. Rather than trying to compete against these established ESB vendors directly, Microsoft is attempting to paint the notion of an ‘enterprise’ bus as short-sighted and internally-focused strategy. The next generation, according to Redmond, is the Internet Service Bus (ISB) which turns the attention outward to the extended-enterprise, consisting of partners, clients, and the information superhighway at large. Whereas traditional ESB solutions focus within the enterprise. The ISB turns the attention to interaction between enterprises. I’m not sure how much of that is real and how much is fluffy rhetoric, but it is an intriguing perspective.

I delivered my presentation today at SOA World — Service Oriented Patterns and Anti-patterns. The talk covered business interaction models, technology patterns and anti-patterns, and human patterns and anti-patterns. We were stuck in Sutton Suite, which is on the second floor and rather off the beaten path. I thought that the location might deter attendance, but to my surprise, the session was packed. Every seat was taken, the back of the room was full, and the audience spilled over into the hallway. The session seemed to be well received and we had some discussion around the topics as well. I hope that more work is done around the subject of patterns for service orientation. I definitely think that the OASIS Reference Model is a good start. I may take an opportunity to post my thoughts on that another time.

For those of you that were able to find the room and attend the talk, thank you so much for providing me with an opportunity to speak with you. I enjoyed it and I hope that you got something out of the session.

If you would like to browse through my presentation from this afternoon, you can download it here: Service Oriented Patterns and Anti-patterns (PDF)

It’s been over a month since I’ve posted anything. For the past several weeks I’ve been heavily engaged with clients and several public speaking engagements related to Service Oriented Architecture (SOA), Business Process Management (BPM) and Enterprise Architecture (EA). A resounding theme as of late has been the importance of aligning the business and technology teams along shared enterprise goals. Although architecture and service design patterns are important, more and more enterprises are interested in the cross-functional synergy that SOA enables. In order to truly deliver upon the promise of agility that service orientation offers, it is critical that business and technology personnel work together.

So what exactly does this enterprise alignment look like?

• Cross-functional, enterprise teams must champion the adoption of SOA. Change agents and visionary champions need to understand and clearly communicate the SOA strategy to all levels of the organization. Technology-minded individuals and business-minded individuals need to be involved. This should also be a diverse, enterprise-wide initiative that has input from all lines of business. Some groups choose to establish or leverage an existing Center of Excellence, Competency Center, or similar objective group. Regardless of how formal or informal the team may be, the keys to success are passion, communication, and diversity.
• The Information Technology group must be treated as a strategic partner, not a cost of doing business. IT provides far more value than simply keeping an organization’s servers up and running. They are a key enabler of information and automated systems that allow humans to focus more on analytics and less on low-level details.
• Organizational transparency must be prioritized. The visibility of IT’s business value and internal capabilities must be raised to the business community (minus the technical jargon and useless acronyms). The business capabilities that IT has today and can reasonably make available in the future need to be clearly communicated to the business teams. Visibility is a two-way street though. The business teams need to clearly convey business drivers and relevant metrics so that the technology teams understand where the organization is headed.
• A process-centric approach to business. Business Analysts and Business Engineering teams are gaining increasing credibility within the modern enterprise. In order to truly bridge the gab between business and technology, it is essential for a common frame of reference to exist. Business process models offer a visual mechanism for both business and technology personnel to discuss, explore, and solve business problems without getting caught up in the details. Afterward, each team is then able to translate this into their world. The technology teams, in particular, have a lot of options available to them thanks to standards like Business Process Execution Language (BPEL) and Business Process Modeling Notation (BPMN). On the business-side of things, it is important that business processes become a pervasive element within the enterprise. Business processes should drive budget allocation, project management frameworks, and even human resource strategies.

Service Oriented Architecture has really grown to become an umbrella that encompasses an entire range of enterprise initiatives (service architecture, BPM, EA, governance, etc.). Rather than getting caught up in the technical ‘architecture’ aspect of SOA, I prefer to talk with clients in terms of business and technology alignment along service-oriented business processes. Service orientation is really a people problem more so than it is a technology problem.

As I explore this alignment concept further with clients, I will post some more on this subject. I might even distill my experiences into a white paper later this year. I’ve got a pretty full schedule this summer. If nothing else, I’ll be back in late June / early July to comment on SOAWorld 2007 in NYC.

I got my acceptance e-mail from SYS-CON for the SOAWorld 2007 event in New York City. I’ll be presenting “Service-Oriented Patterns and Anti-Patterns.”