OPINION
Building a Better SOA Architect

Bringing services-oriented architectures (SOAs) to life is a lot like delivering a baby -- it requires a copious nurturing, understanding, labor and ultimately ... pushing. So far, the job openings for SOA midwives outstrip the available pool of talent.

These are great jobs: transforming companies and industries, working at the highest levels of business and technology, having a huge impact on productivity and competition. Great title on the resume, too. Given the demand, the pay ought to be very good, even if the hours and stress are long and high, respectfully.

Yet almost everyone I speak to worries that talent may be the largest inhibitor to the advancement of SOAs in enterprises. As IBM (NYSE: IBM) executives described at the recent IBM Innovate event, a lot of "T" people are needed, whereby the horizontal bar represents wide business knowledge about the industry and niche that the SOA supports, along with a deep vertical bar representing technical acumen and implementation achievement. IBM is taking steps to help foster the emergence of more SOA "T" people, and they are hiring them all over the world as fast as they can.

City Planning

The Open Group has also stepped up to the plate on the issue with a certification program, community development initiatives and portals, as well as outreach to academia to begin to fashion better course work for curricula that support architects on the SOA plane. They like to use the analogy of a city planner approach to IT architecture -- not just focusing on the buildings but all the support and holistic interactions to make the whole thing work.

In our latest BriefingsDirect SOA Insights Edition IT analysts roundtable discussion on the role and definitions of SOA architects, we're joined by Steve Nunn, vice president and COO of The Open Group, as well as John Bell, an enterprise architect at Marriott International.

Our analyst panel consists of noted IT industry analysts Jim Kobielus, principal analyst at Current Analysis, and Neil Macehiter, research director at Macehiter Ward-Dutton. I was the host and moderator.

In addition to digging into what will make for a good SOA architect, we also examine the move of the Service Component Architecture (SCA) and Service Data Objects (SDO) specifications to OASIS, as well the role of Microsoft (Nasdaq: MSFT) in the federation of services that SOAs demand.

Listen to the discussion (51:02 minutes).

Here are some excerpts:

On SOA Architects

Steve Nunn: What we're hearing is there aren't enough enterprise architects to start with. So, I think it's a given, therefore, that the SOA specialists are in short supply too. We're hearing from our members that if they spot a good enterprise architect or somebody they think has potential for that, then they try and grab them. They're pretty few and far between right now in terms of folks with experience.

The Open Group and its members have been working in the architecture space for over a decade now, primarily developing something called The Open Group Architecture Framework (TOGAF), but, as you've mentioned, we're running certification programs in two specific areas. One is in relation to TOGAF, but perhaps more relevant to this discussion is our IT Architect Certification (ITAC) program.

... The IT Architect Certification Program ... is a broad skills- and experience-based program. It's aimed at creating a vendor-neutral program by which individuals can be certified. It provides them with a transferable qualification in the industry, and it enables employers to know that if they prefer recruiting certified individuals, they would be getting somebody who has been through an accreditation process.

... There's a peer review by a panel of three certified architects themselves who would probe a little on the resume, ask questions of the candidate, and conclude whether or not that individual meets the conformance requirements. ... We have just a shade under 2,000 individuals from all sorts of companies and all over the world who are certified under this program.

Dana Gardner: An SOA architect needs to like a city planner, looking at all the resources and infrastructure and how the entire community comes together, managing constituencies and political relationships, whereas an IT architect might have a smaller role.

John Bell: When they're looking at the entire city, they're looking at how the various neighborhoods, how the various business zones, etc., fit into that city. The SOA architect, from my point of view, is really more interested in, "Hey, how does that underlying infrastructure allow different neighborhoods to communicate with each other and exchange messages? How are health services delivered across neighborhoods?"

So, it's more interested in, "OK, I've got a firehouse. Can the fire truck get to the house before it burns down?" The vision of the SOA architect is more associated with the communications pieces within the community.

... The enterprise architect has a much broader spectrum and scope that they have to deal with than your SOA architect has to deal with. Putting it into that city paradigm, you kind of limit it as to how to describe some of the roles. I try to clarify that by saying it's not just how they communicate, it's things like, "Hey, where's the fire station? Do you have a fire station? Where's your police station? Where are your schools? Where are all those pieces that are providing services to that community and are they adequate for providing the services to their community?" That's a subset of what a city planner has to do but it's still an important city-planning kind of function.

My view is that the enterprise architect is at the top of the hierarchy, and at some place, working with the enterprise architect is an SOA architect, and their focus is on, "What are the services that are being delivered, how am I delivering them? What's the infrastructure I am using to deliver it? Do I need -- using that town model -- a police station? Do I need a fire station? Do I need a school? Do I need a museum? And, if I do, how do I get that service out to the community or to the entire city, not just an individual neighborhood?"

So, from my perspective, using a city planner paradigm, the role of the SOA architect, is identifying what are the services that need to be available to the city and how to deliver those services out to the city.

On SCA/SDO to OASIS

Jim Kobielus: It's clear that the SOA paradigm requires ever more high-level abstractions to enable easy development of very complex, orchestrated, end-to-end services. The SCA and SDO specifications -- the initiative has been being going on for a couple of years -- have come a long way, and they've got pretty significant support throughout the industry. Microsoft is one of the few important holdouts. It's not only the high-level abstraction for developing competence services, but also, especially, in my area, the SDO, the high-level abstraction for working with heterogeneous data. I see the SDO, in itself, becoming potentially the standard industry framework for what's called the semantic layer for any data integration.

So, I'm very keen on the potential for SDO, for example, within the business intelligence space, the data warehousing, and the enterprise, information, integration space. The fact that now OASIS will be taking over ongoing development of SDO, puts it on a very important fast track.

Gardner: The politics here struck me as a little bit interesting. Ed Cobb of BEA (Nasdaq: BEAS), who was on the call describing the movement of these specifications to OASIS, said that he hopes that this does for SOA what J2EE did for n-tier in distributed computing, which is to create a climate of growth with application server vendors coming together and ISVs building applications that take advantage of these. That sort of exploded during the mid- and late-1990s into what is now a predominant architecture for enterprise applications, as well as large Web commerce and online commerce types of applications.

Neil Macehiter: ... the creation of SCA and SDO was motivated by the frustration with the J2EE process. Enterprise Java Beans (EJBs) and things like that never really took off. Some of the lightweight programming frameworks, Spring and Hibernate, were just taking great chunks out of J2EE in terms of deployment.

Then there was a significant amount of discontent among the Java community around the support for Web services, which is clearly one of the key enablers of SOA. Those three things, plus what Microsoft was doing with the Windows Communication Foundation (WCF), and the work they've been doing around it, caused the big J2EE players to think, "Well, actually we need to do something different." That was the motivation.

On Microsoft and SOA

... Microsoft has collaborated with the likes of IBM, BEA and others, its historical competitors, up to a certain level up the stack. But the level at which SCA and SDO are operating is at the level where Microsoft has a massive investment, and a significant proportion of its business has been driven out of this at the programming model level.

So, I think it would take a lot for Microsoft to move to support SCA and SDO within the composition framework that they have, which is fundamentally around Visual Studio. Whether we are talking about BizTalk or Sharepoint or Office, it's all around that programming model, which is tied into WCF and Windows Workflow Foundation. So, I just think the battle line is drawn at that level.

Gardner: What we are facing is perhaps an important decision within enterprises and service providers, Software as a Service (SaaS) providers, and ISVs as to which role you perceive for .NET playing in Microsoft's tools and process runtimes. Are they a subset of SOA, or are they in fact the master -- and the rest of the SOA componentry is the slave?

Kobielus: I wouldn't use the hub vs. spoke analogy here. They've become more comfortable with the notion that they're just one node in a vast mesh on the Internet in terms of Web services and SOA. So I don't see Microsoft in face-off mode in the SOA world, or where SCA or SDO are concerned. A couple of years ago it might have been different, but it has changed.

Bell: Microsoft tends to build those kinds of capabilities in as part of the operating system, other vendors tend to create them as standalone products and infrastructure pieces. If you are a small company, having it built into the operating system is a value to you, but in large, heterogeneous environments that can be costly to you. So, that's always been used by Microsoft. If you look at CORBA versus COM and DCOM, it's the same story.

Click here for more podcasts.