This week (Friday, March 23, 2007) involved another SOA interoperability forum representative, Steve Nunn, vice president and COO of The Open Group, and an SOA practitioner, John Bell, an enterprise architect at Marriott International. It also involved regulars Gardner, Kobielus, and Macehiter.
That morning’s primary focus was on the value, scope, and responsibilities of an “SOA architect.” Nunn’s group has taken an industry lead in that endeavor, per what Dana said:
I guess that sets a caveat at the outset. The terminology around what type of architect it might be -- IT architect, enterprise architect, SOA architect -- is still very much settling down as a topic of debate in its own right, but our program that I can talk about is the IT Architect Certification Program, which 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.
Briefly, the process would be that a resume is compiled, which can be quite extensive, up to 52 pages in some cases….
[A]nd then 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 launched this in July 2005, and as of today, 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….
[W]hat we call ITAC, the IT Architect Certification….
It has several levels and covers various disciplines. The SOA-specific part of it is one that we are still working on. We have various horizontal levels under this program. The conformance requirements for meeting those levels have been agreed upon. There’s an entry level and a higher level. We are working on the highest level right now, but what’s also going on is work on the individual aspects of that certification, of which SOA is one. What we’re quite proud of in this program is the conformance requirements for the overall program, and what we're now focusing on are the conformance requirements for the individual disciplines.”
Sounds very interesting. I pressed Nunn for more details (per the concern I expressed in that last blogpost, re my doubts about the industry’s ability to define consensus skills and practices for an “SOA architect”):
“Kobielus: …. You have to be an IT architect to be an SOA architect. It seems to me that an SOA architect, or that discipline, is a subset of the overall enterprise architect. I would like to know precisely what other disciplines or practices that one needs to be certified in to be a SOA architect, versus just an overall enterprise architect, I’m still unclear on that.”
But then Messrs. Gardner and
So, it’s more interested in, "Okay, 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.
Gardner: So, the hierarchy might be that the enterprise architect is in the town planner role, the more holistic, oversight uber-architect role, and then a subset of that is making sure that the communication channels between and among these different facets of resources and functionality are behaving well and conforming to what needs to happen.
Neil M. stepped in with a plumbing metaphor that I suppose can be likened to water mains and the other components of a civic water-management infrastructure—but he ended up seconding my skepticism about the ability to distinguish an SOA architect from an enterprise architect (btw, in this metaphor, is the “enterprise” equivalent to a single propriety in the city, or to a neighborhood, or to a whole city? is “SOA” equivalent to the entire metro area, or the state/province/etc?):
“Macehiter: In that classification of the difference between enterprise architecture and the SOA architect, it sounds to me that the premise is that the SOA architect is focused primarily on the plumbing. From a bottom-up perspective, the challenge that many SOA architects face is more around understanding what the services are that need to be delivered in a business-meaningful way, not just about communication and plumbing. It’s also about understanding the high-level, business-meaningful services.
There is a business strategy, there are business processes and priorities, and there are the services we need at a business level. Then, there's a handoff to what’s currently defined as the SOA architect, who will actually define how those services are deployed in technology terms. So, the distinction is quite blurred. A service-oriented approach is one of the methodologies and the approaches that you can utilize to deliver or to support an enterprise architecture initiative. So, I still find a distinction difficult.”
Here, then, is how I followed Neil, articulating my understanding of the proper distinctions:
“Kobielus: I second what Neil’s saying. I’m uncomfortable with just reducing SOA to the plumbing. In the three-layer stack that I carry in my head, the plumbing level is the enterprise service bus, and then SOA refers to development and reuse practices within the development organization to enable maximum sharing and reuse. Then, there’s the layer above that, which is the applications, services and data -- the business processes.
I’ll put enterprise architecture at that very top layer, concerned with the end-to-end set of resources: app services, data, etc. The SOA architect would be the middle layer of the development and reusing. The layer below that, the enterprise service bus (ESB) or whatever, I call that "IT architect" in the sense that it's the infrastructure architect.”
I suppose, then and here-now, that my three-layer SOA-architecture stack (wait—that’s redundant—the “A” stands for architecture—humor me, please) can be mapped into the urban-planning metaphor (“mapped”!....cartography!....urban street plans etc!...wonderful what you find when you examine the roots of your words) as follows:
- Underground urban infrastructure: water, sewage, electrical, phone, cable, etc.: ESB architect (integration infrastructure, tools, and practices)
- At-ground urban infrastructure: buildings, roads, etc.: SOA architect (development, sharing, and reuse infrastructure, tools, and practices)
- Above-ground urban infrastructure:
architect (applications, processes, data, and governance—usage and control) Enterprise
Nah….doesn’t quite map….some metaphors run aground….my head’s starting to hurt….SOA has a non-metaphorical substrate…I’m coming to that…nuff of this. Anyway, here’s how
I think all of us were relieved when Nunn of The Open Group shifted the discussion away from metaphors and back to what it means to “certify” an “SOA architect.” He seemed to be nudging us away from an orthodox SOA-architecture-by-the-book regime toward a more heterodox SOA-architecture-by-the-seat-of-our-educated-experienced-and-well-compensated-pants approach. Here’s what he said:
“Nunn: Something that we’ve had to address in putting the [SOA architect certification] program together is that there are huge differences. Even taking the frameworks that might be used in implementing an enterprise architecture, there are huge differences among organizations. Some organizations are required to use a certain framework. Our approach is not to specify exactly how enterprise architecture or SOA architecture is done in the certification program, but more about the experience of the individual who's implementing it.
It doesn’t seek to define a particular way of implementing the architecture, but is more about the skills and experience of the individuals who are playing that role inside an organization. They could be part of a team in larger organizations, or could be one person in a much smaller organization who is playing this role. The whole idea of raising the value of the architects of various titles in the organization is what we are seeking to achieve with our efforts in the certification program. It’s about raising the standards of that role, and getting people to understand that it’s a valuable role and, apart from anything else, it should be compensated as such.”
Then Neil M. and Nunn engaged in an interchange that started to hint at the need to create a self-anointing class of SOA architects based on fuzzy club-eligibility criteria—a “special set of individuals” (i.e., what I cynically referred to in the previous posts as “high priests” of SOA). Their exchange:
“Macehiter: It’s about the approach and the experience, rather than framework, and I agree completely with that. Given that the SOA discipline is currently within the IT architect certification, to what extent do you look at the approach and experience in terms of the interface to the business, business understanding, or collaboration with the business? I think that key elements of the SOA architect role are skill and capability, as well as the more IT-oriented skills and capabilities.
Nunn: Well, that's not so different between SOA and enterprise architecture. I’d say exactly the same about the enterprise architect -- that ability to translate the business need into the systems underlying or delivering the needs of the business. It’s something the enterprise architect absolutely needs to have, and that’s why we think there’s a special set of individuals who play this role. So, there isn’t really a difference in that respect between the SOA architect and the enterprise architect.”
A self-sustaining SOA priesthood without a holy scripture—a charter, manifesto, guidelines, certification procedures, established codified body of practice, multidisciplinary degree-granting curriculum in essential/prerequisite fields, etc.—strikes me as a recipe for elitism. That’s why I immediately jumped in with this thought:
“Kobielus: I like what you do. Thinking about the whole notion of certification, there are two ways to go about it. One approach that you can easily take -- and this is the way it’s usually perceived -- is when you are certifying a CPA, you’re certifying somebody as a skilled in an established and knowledgeful body of practice, be it law, medicine, whatever. But when there’s no consensus body of practice that everybody agrees upon -- for example SOA, which is still evolving -- a certification in that regard is more like when somebody is applying to college. You’ve got to send in your transcripts, write essays, and you also might have to go and do an interview in the admissions office. They look you over and say, "Oh, this is a smart person. Yeah."
So, they consider the sum total of everything you’ve done and who you are in certifying that. They say, "Yes, you’re good enough to be admitted into this college," and then proceed from there. That’s sounds like what you’re doing. You’re certifying the competency of a particular individual in this general field called a enterprise architect (EA) or a SOA architecture.
Nunn: That’s right, Jim, and it’s not a bad analogy at all. It's about assessing the individual. It’s a relatively young discipline in its own right. One of the things that we look at in a conformance requirement is the role that those individuals have played in the projects that they have been involved in, and whether they had been in a lead role or support role, or a combination of the two, but it certainly is about the individual, rather than the specific approach that they take or any particular body of knowledge.”
Neil M. then offered a great suggestion for how we might create what I just a moment ago, called a “multidisciplinary degree-granting curriculum in essential/prerequisite fields” for the role of SOA Architect. Neil’s statement:
“Macehiter: Just one other quick comment on this, if I may. The other dimension for this, I think, is rather than thinking about the role, thinking about SOA as an approach. Then, thinking about how that approach applies to different types of architect. What I mean by this is that a lot of the emphasis and focus on SOA today has been around application development and integration, when, in fact, there’s a broader perspective that really extends across more traditional IT architecture and other disciplines, for example, a service-oriented approach to infrastructure architecture and the service-oriented approach to the operations and operational management of IT.
So, there are two dimensions that a body such as The Open Group might want to think about. One is the role of a service-oriented architect, and the second is how service orientation impacts other architecture disciplines and other IT functions or operation capabilities. If we don’t do that, we risk driving SOA into a particular stovepipe focused on application development and integration, and aren't thinking about it more broadly as an approach that it is an enabler of whatever the enterprise architects are driving out.”
In short order, Neil also offered this thought regarding how organizations can recognize, encourage, cultivate, and incentivize potential SOA Architects in their midst:
“Macehiter: This is not new. We’ve been through this with every major technology advance or discipline advance. You used the word "potential" there. I think there are individuals within organizations that have the potential to fulfill that role. Part of the benefit of this certification approach, providing conformance and definitions of what constitutes the role, is that it will help organizations identify the individuals within that company that have that potential, even if they don’t have the 50-page resume that demonstrates that they have been there and done it, because the key element in a service-oriented approach, and an enterprise architect more broadly, is an understanding of the business.
If you’ve got individuals within the organization that understand how the business works, have been around, and know the right individuals to talk to, that that can be of much benefit in terms of enabling effective Enterprise Architecture and Service-Oriented Architecture, as can be going outside, finding someone from a different vertical market or different industry, and bringing them in because they’ve done six SOA projects elsewhere.”
Because of that, when you pull somebody from outside, they may understand the technology, but they have to come up and learn the business, which is harder to train than somebody who has a general technology background, but knows the business pretty well, because he has been working in the business. Marriott happens to be a company that retains employees for years and years on end. So, in our IT department we have people who may already have 5, 10, 15 years of experience working directly in the business. And we can’t afford to lose that.”
Of course, this apparent greybeard criterion doesn’t do much to address the here-and-now surge demand for SOA architects, including the need to recruit fresh-out-of-college blood that can inject the necessary x-factor of creativity, innovation, and energy into SOA. Here’s what I said in that regard:
“Kobielus: This is all very good, but it doesn’t address the need that many companies have which is, "Hey, we need to hire people straight out of college who have some background in architecture, and where are we going to find these people and how are they going to get certified?"
Everything I'm hearing says that, an EA or a SOA architect is somebody who has experience and, by definition, somebody right out of college doesn’t have experience. So, is this the kind of thing that we can actually train in school or does somebody have to be in their career for 5, 10, 15 years before they’ve been steeped enough in all of this architectural infrastructural development and integration stuff to the point where they can be certified?”
Fortunately, though, young and not-so-young blood is being SOA-infused and –certified in institutions of higher learning as we speak. A few comments from my fellow panelists:
Nunn: …. Something The Open Group launched at the end of January this year was the Association of Open Group Enterprise Architects (AOGEA), which really is -- the analogy here is the one somebody used earlier with attorneys or CPAs -- to do for enterprise architects what the Bar Association, for example, would do for attorneys, all joking aside. I think one of the things that we’re trying to do is partner with various types of organization in creating this community and this professional association.
One of those groups is the academic community, so we are putting out feelers to various universities to explore the possibility of getting enterprise architecture on the curriculum. There is one university that we are aware of where there is actually a TOGAF module in some of their courses. Obviously, changing a curriculum is a multi-year project, or multi-year plan. It’s not going to happen overnight, but in the interim, one of the categories of membership for the association is students.
So, those who are on a course of some description inside the university or even working in a job and doing part-time study, can join the association, be part of the community, get the information that’s available there, be on the news groups, maybe take part in the local chapter, or whatever they want to do to start building up some experience….
Gardner: Now, it does seem that we have a climate of opportunity here. There’s the track for developers to move above that role and embrace more business understanding in domain expertise, and that would be a track. We’re looking at more universities preparing people for these types of roles. We’re probably going to find, again, variety within organizations in terms of business analysts or non-tech people coming into this role, because it requires influencing and consensus building, and so forth.”
And so on and so forth. You can read the transcript for the full discussion. Which brings me to the Mike Brady metaphor—you know, Mike Brady, the name of the father character in “The Brady Bunch,” played by Robert Reed in the TV series and Gary Cole in the movies—the only reason I mention him here is that he was an Architect…you know, the old kind…of actual—er, fictional--buildings….inhabited by actual—yeah, fictional—people. I distinctly recall Mike Brady’s profession being mentioned time and again in the series (yeah…I watched it religiously in my junior high days…during its original run). And actually factoring into at least one episode—when a client, a femme fatale cosmetics maven played by Abbe Lane, asked Mike Brady to design her HQ in the shape of a woman’s compact, complete with hinged upper floors that can be flipped “open” on command in the manner of a compact—obviously, this was absurd, and Mike, self-respecting-professional-architect-with integrity that he is told, had the guts to tell her to her face, and risk losing the job…which he didn’t, of course….he set her straight and all that…hokey sitcom, I know.
Anyway, I’m mentioning Mike Brady because he exuded Integrity as an Architect—in fact, Hollywood has featured Architect protagonists in a disproportionate number of feature films and TV shows over the years, and most of them were Alpha Dudes with Integrity—I’ve made a mental note of this—unlike Hollywood’s typical depiction of, say, lawyers, advertising professionals, used car salespeople, etc. Clearly, the term “Architect” carries great weight in our culture. It seems that everybody in IT aspires to be an Architect of one sort or another. So I’m not surprised to see these job titles--and associated training, education, certification, and other Architect-building efforts—proliferate like crazy.
Everybody craves that sort of prestige and respect. Who has the professional chops to earn the designation of SOA Architect? Who has the professional integrity to make it a respected position that adds value to organizations’ SOA initiatives? Who among us is already an SOA architect par excellence—in smarts, accomplishments, and backbone—but hasn’t yet been recognized as such?