thenagin The SOA Mike Brady Metaphor

All:

Then:

http://briefingsdirect.blogspot.com/2007/06/briefingsdirect-soa-insights-analysts.html

Again:

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:

“Gardner: We're going to be discussing the role and concept of what’s becoming defined as the "SOA Architect." This is a different role, as we’re finding out, than the enterprise architect, but certainly seems to be part of an evolution of the role of architect within the enterprise and within IT in general. We’ve invited a representative from The Open Group, in this case Steve Nunn, to join us, because The Open Group has taken some steps to try to define the role of the SOA architect, has created some certification around that role, and is trying to get in front of this role in terms of what will be required in the marketplace. That is, to try to encourage more people to step up and understand this role and to certify themselves, so that the progress and maturity of SOA practices can continue and not face a human resources crunch.”

Clearly, this relates to the previous week’s discussion with Richard Soley of OMG/SOA Consortium, regarding SOA best practices, certification, and so forth. Here’s what The Open Group is doing in that regard, per Nunn:

“Nunn: …. 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.

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 Bell—the latter an “enterprise architect,” remember--stepped in and shifted the metaphor away from architecture and toward city planning (which, I suppose, is a form of architecture writ large):

“Gardner: [O]ne of the helpful concepts for me in understanding this was the notion of the "city planner" or "town planner" role. The analogy is that 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. Can you expand on that a little bit?

Bell: Actually, an enterprise architect from my perspective would have the view of the town planner. 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, "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.

Bell: Conforming to the standards so that they’ve got a consistent set of standards for exchanging information, those kinds of things.”

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: Enterprise architect (applications, processes, data, and governance—usage and control)
  

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 Bell responded to that comment of mine:

“Bell: And to be fair, I didn’t mean to imply that the SOA was limited to the plumbing. My intent was saying that 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.”

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.”

Bell seconded Neil’s comments, from the vantage of someone in the real-world Enterprise/IT/SOA architecture trenches:

“Bell: I think what we are going to have to do -- fortunately or unfortunately, however you look at it -- is end up training our own people. A lot of it goes back to what was just said about having to have an understanding of the business. You have to know the people in the business. You have to understand what the business of the business is. You have to have a lot of domain knowledge in order to create an effective SOA environment.

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:

“Bell: I’m also an adjunct faculty member at Towson State University, and this is an issue that we’re dealing with at the university level so that the university can provide the skills that the local businesses in the Baltimore area need. So, at the graduate school level, we are looking at what we offer in the way of architecture courses that take architecture from an enterprise or SOA perspective, so that we can enable our students who are finishing graduate school to be more and better prepared as they enter their new job market….

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?

Jim