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.

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!

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.

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.

SOA ROI is a hotly debated topic, with some claiming that an ROI cannot be determined:

“Can You Assign an ROI to SOA? Not so much.” (Ann All)
“ROI doesn’t apply to SOA” (Joe McKendrick)

That last posted generated some discussion which led Joe to post a follow-up entry: “SOA is not above ROI scrutiny, but…” I was a bit disappointed with his first post, but I agree with several of the thoughts that Joe expresses in this latest entry. Determining an ROI for an individual SOA initiative or even an entire SOA strategy is difficult, but it cannot be above scrutiny.

A few weeks back, a client requested a detailed analysis of ROI calculation models for SOA. After putting together the tailored analysis for the client, I decided to leverage the research that I did into SOA ROI calculation and pull together a white paper on the subject: “SOA ROI, Deconstructed”. I hope that the community finds it to be valuable.

As SOA increases in maturity and we understand it better, inevitably we develop standards and common design strategies. One such design strategy that I am closing monitoring is the evolution of the Enterprise Service Bus (ESB). In particular, I am interested in the potential development of a standardized SOA middleware framework framework that can be implemented by multiple vendors to supporting portable process definition, component/service assembly, mediation logic, messaging, and a data service layer.

OSOA seems to be making some considerable headway on Service Component Architecture (SCA) and Service Data Objects (SDO). OASIS has certainly cornered the business process / service orchestration side of things with the Business Process Execution Language [which evidentally now is shunning the all upper-case (BPEL) acronym in favor of the much stranger looking (BPel) case]. This still leaves me wanting to see some standardization in mediation logic and messaging. I hope that Chappell and friends will pick up the ball with Synapse and run with it, but it doesn’t appear to be moving especially fast right now. Until then, or until another initiative comes along, I guess I’ll just have to settle for vendor lock-in on the messaging / mediation middle-tier.