Thursday, August 30, 2007

poems Haikus jotted during thenagin


Event clouds, tag clouds—

the buzz, the behaviors of

bots busy as gnats.


How deeply words fail

to impress the page upon

which the ink stains dry.


Jesus lies buried

in scripture, Christ’s cradle in

worms and conjecture.


Every position,

held, imposes its posture

on the long poser.


The world of dew is

done with struggle and awaits



We got married in

Madison. Born Michigan.

Not February.


I have a first name.

Others may or may not use

it—but there it is.


Poof! Overnight the

humidity vanished. The

air turned light and sweet.


Mall was remodeled

twice in a generation

in a modern style.


God’s massive missive

for the submissive mostly

scolds the transgressive.


A single moon makes

bright the evening over this

our only home world.


The projected I

really registered that tap

on our right shoulder.


In vineyards, time sweeps

green the constitutional

roll of Virginia.


Clerk punched the keys real

hard, hoping to hammer some

logic into it.


As the mantis its

own kind consumes, so the hands

of humans grapple.


The thought of free has

me picturing sunup on

a day without bread.


Before you drop, your

daydream collects the crystal

your nightdream shatters.


Red as a barn on

a farm, a form visited

just once in childhood.


Utter density—

another immensity

of the city steep.


Jet lag sets in, though

set in my place, in space, I’m

watching the world spin.


Straight as the ray of

steel that stays you through the days’

many distractions.


First thirty seconds,

a mumbled yeah explains the

next ninety minutes.


End: heaven or hell.

Cycle: birth, growth, death, repeat.

Exist: pure, in pain.


As load is lifted

the gravity cavity

becomes and then some.


Breathe unnoticed. Bob

like the lotus floats through noise—

with effortless poise.


Not wealth, but wellness—

the well of a will kept deep

pure and cool and calm.

thenagin The SOA Literal Non-Metaphor




This podcast, recorded Friday, April 6, 2007, featured Messrs. Gardner, Garone, McKendrick, Kobielus, Baer, and Biske.

Let me see. We discussed Software AG’s recently announced intention to acquire webMethods. We got into Web 2.0 and SOA (e.g., wikis’ potential role in SOA governance!). We delved into “SOA and the Hype Curve.” There’s hype in this space? Really? Some would say it’s all hype, but, of course, there’s plenty of substance and substrate—which is why we have a never-ending stream of SOA-related industry announcements to discuss.

If SOA were all surface and no depth, then the metaphors that I’ve used as the motif for this blogpost thread would be pure affectations. But SOA, like most uber-important architectural IT topics, demands metaphors, similes, analogies, and other figures/handles (note these tactile nouns) of thought/speech to help us grasp (note this tactile verb) the choreography/behavior (note these anthropomorphic nouns) of their underlying applications, patterns, models, and so forth. The most important aspects of SOA, like IT in general, are either above the threshold of everyday perception (e.g., complex networked integration patterns distributed and virtualized over local, wide, wireless, and other “areas”) or below that threshold (i.e., the invisible execution, flow, and behavior of software, storage, CPU, memory, and other components within each and every node). In this environment, metaphors aren’t literary devices—they’re planning, design, engineering, and management tools.

SOA, like IT in general, is the most multidimensionally plastic of all human innovations, absolutely demanding agile metaphors to press it into the proper shapes. To the extent that I quote Andy Warhol in my normal rounds, it’s to second his statement that plastic is the new bedrock reality of the tech-mediated universe: “Everybody’s plastic. I love plastic. I want to be plastic.”

In terms of what SOA’s literal, non-metaphorical substrate might be, I took what I feel is my best whack at it in September 2004, when I published the following column (“SOA and the death of platforms”) in Network World. I will now quote and second my then-self at length:

“Kobielus: As high-tech buzz phrases go, service-oriented architecture is vaguer than most. SOA isn't a technology, product, service or protocol. But it's been mentioned in many marketing pitches lately, promising greater developer productivity and standards-based interoperability if you buy this vendor's application platform or that one's visual-modeling tool. Over the past three months, Sun, Oracle, Microsoft and IBM all announced products or initiatives for implementing SOA in their respective environments.

SOA is a substantial and growing body of practical techniques for designing shareable, reusable, interoperable Web services. Just as important, the past few years have seen the emergence of a universal, standardized, SOA-enabling middleware fabric built on the Web Services Description Language (WSDL), Simple Object Access Protocol (SOAP) and Universal Description, Discovery and Integration.

SOA is a disruptive approach to building distributed services. Until now, we've developed new functionality on and within concepts such as platform, application and language. Each of these concepts has traditionally had a well-defined sphere of reference: The platform hosted the application, and the application was developed in a language. Now all that is changing, thanks to the emergence of SOA.

The first of the old computing concepts to wither away will be the platform. This term originally applied to operating systems, then included application servers that implement a particular development framework (Java 2 Platform Enterprise Edition or .Net) over one or more operating systems. But the growth of standards-based, distributed Web services has made it clear that fewer and fewer business processes will execute entirely within the confines of a J2EE 1.3 server or Windows Server 2003, or Linux, but will execute across them all. When all platforms share a common environment for describing, publishing and invoking services, the notion of self-contained platforms disintegrates in favor of SOA, which is essentially a platformless service cosmos.

Another casualty of this evolution is the notion of applications as discrete, functional components that execute on particular platforms. SOA is founded on the notion of virtualization. Under this paradigm, services describe abstract interfaces within standard, platform-independent metadata vocabularies such as WSDL. The underlying service functionality may be provided from components on any platform without needing to change the interface. Under SOA, the application dissolves into a service that may have no fixed implementation but simply bids for on-demand networked software and hardware resources.

Programming languages also are becoming something that fewer developers touch directly. Visual model-driven development and automated code generation are at the forefront of the SOA revolution. You're more likely these days to see a vendor boast of its ability to support visual modeling in Unified Modeling Language than development in Java, C# or any other declarative programming language. For complex, orchestrated, multiplatform Web services, visual modeling is the most effective approach for specifying, implementing and maintaining the end-to-end logic and rules on which the service depends.

SOA has spawned a range of terms to describe what developers actually develop. IT professionals increasingly define their creations in terms of services, models and patterns, rather than platforms, applications and languages. The notion of patterns will become critical to discussions of distributed services. A pattern is a generic approach - such as service proxying or service coordination - to architecting interactions in the infrastructure. Every pattern defines its own abstract Web services functional elements and SOAP-based interactions.

Welcome to the dizzying new world of SOA. Platforms are dissolving, new concepts are taking over, and Web services will become everywhere shareable and reusable."

SOA as “platformless service cosmos”? I’d forgot I’d said that. Metaphor, sort of, or at least a visual image that suggests universality without trying to map it to stars, galaxies, quasars, etc. It’s abstract but tactile and tensile in the manner of any good figure of speech.

Solid plastic, all the way through.

Oh, back now to the April 6, 2007 podcast. Any good thought handles re plasticity in the SOA universe, at the technology, market, product, and/or vendor level?

On the increasing irrelevance of single-vendor all-purpose closed-source SOA suites in this platformless service cosmos:

McKendrick: Well, as we discussed in a previous podcast, the whole notion of an SOA suite runs counter to the SOA philosophy. SOA is especially about loosely coupling, and it doesn’t matter where the applications or the system resides. SOA should be independent of all that, and the idea of an SOA suite runs counter to that thinking. Nevertheless, we see lot of companies glomming onto each other, a lot of gelling taking place. This Software AG-webMethods merger is an example. Progress Software has been very astute in assembling a collection of companies that deal with different aspects of SOA. They want to compete with Oracles, and we saw that just recently with JBoss.

Gardner: SOA Software?

McKendrick: Yeah, right. SOA Software and JBoss. Their goal, their intention is to compete against these bigger guys, while servicing the smaller business market, of course.

Gardner: More of an ecology approach to how to bulk up.

McKendrick: Yeah, we’re going to see more of these alliances, more of these acquisitions and mergers.”

On wikis as a potential enabler for loose collaborative SOA governance in a platformless service cosmos:

“Gardner: …. I want to go first to Jim Kobielus, because in some emails this week you had some interesting thoughts. We’ve seen a few companies say, "Let’s leverage Web 2.0." We’ve seen Intel come out and say, "We’re going to corral a number of 'open-source' Web 2.0 functions." We’ve seen Cisco get involved with Web 2.0. We’ve seen BEA just announce an embrace of Web 2.0. Even IBM is tinkering with this, I’m sure.

So, there is something there, but let’s focus on this collaborative aspect and particularly in terms of governance. Annrai O’Toole at Cape Clear mentioned this to me probably about nine months ago that he looked at governance and at Web 2.0 and thought, "Gee, maybe wikis would be a good concept for how people manage their services." They could say, "I think the policy should be this, and I’m going to use it in this way, and you can pick and choose."

It's sort of an open source, open collaboration approach to policy and use of services and their agreements. I suppose provisioning rules would come about. You said, Jim, this is kind of a scary concept, that wikis seem to be anti-governance and that it could be a collaboration with no structure. Tell us a little bit about why you’re concerned?

Kobielus: Well, when I think of governance, like everybody I think of the capital "G," like Government, but governance has a broader concern. You often think about crack-the-whip, controls, and setting controls on how people interact and how policies are created? When I think about wikis, I think of the exact opposite. There are no controls. It’s basically a shared space to which everybody can post, everybody can overwrite, and everybody can erase everybody else’s comments.

Gardner: The wisdom of the crowd, right?

Kobielus: Well, okay, that’s a religious faith. Wiki seems like the wild, wild West. It’s a free-for-all as collaboration. That’s great. It’s definitely got a very valid role in many environments, like open-source initiatives where they are very peer oriented. Everybody is an equal, even-steven, participant. There is a high emphasis on collaboration, design, reciprocity, and all of that. So, when I think about the whole SOA governance space, both design-time governance and run-time governance, I think of wiki as in the design-time governance side, where you have teams of designers or business analysts and IT people sitting around the virtual table, trying to hash out policies.

Gardner: Requirements?

Kobielus: Requirements, policies, data designs, data hierarchies like with their master data management environment. Quite often these are creative processes involving teams of smart people who sit around a virtual table and hash out the overall design approach. Wikis and the whole Web 2.0 repertoire of collaborative tools can be very valuable in this upfront design, modeling, simulation, and shoot-the-breeze aspects that are critically necessary for design time. But runtime SOA governance really depends on clear-cut policies, designs, data definitions, and so forth that have been handed down by the policy gurus, and now are governing ongoing operations without ambiguity.

In that case, you don’t necessarily want any Joe Blow to be able to overwrite the policies and the business rules that are guiding the ongoing monitoring, management control, or security of your SOA.

Gardner: Yes. You said that they needed adult supervision, but I didn’t think that this would be open to anybody. I thought this would be open to the people who have impact, the architects and the line-of-business people perhaps. You're not going to open this up to anybody. There would be a directory and an provisioning, so that only those most close would have access…..

Biske: I don’t know that you really want a wiki-style collaboration for governance. I tend to agree with Jim that you can’t just open it up to the masses, and even if you look at collaborative environments, whether it’s the large open-source projects, or something like Wikipedia, there's some hierarchy that eventually was put in place, where certain people were allowed to do commits or were designated as senior editors.

So, you always wind up with some form of governance structure around that. The area where I think wikis are going to be important in the SOA space is in the service management lifecycle or service development lifecycle. You got companies that have to move to a service-provider model, whether it’s internally to internal consumers or externally. I have talked a lot about this in my blog.

If we compare that to traditional product management, for a long time it was really just one-way communication. The product marketers went out and said, "Here’s our product. Here are its features. Go and use it." They pushed it out to the market place, and the only response they got back was did people buy the product or not.

Over time, they recognized the need for much more collaboration with their end consumers on how to evolve that product, whether it was the formation of customer advisory boards or even leveraging the Internet and some of the technologies to establish a community around those products. The same thing can apply when adopting SOA.

If I am providing a service out to the rest of the enterprise, I am going to be interested in what the consumers of that have to say. If I am not listening to them, not establishing that bi-directional communication, eventually they are going to go somewhere else or they are going to build it on their own and put that redundancy back into the organization, which is the opposite of what we are trying to achieve.

Gardner: Okay. So social networking has a value here, but you wouldn’t want it necessarily hardwired into the way in which the technology actually operates?

Biske: Exactly.

Gardner: Okay, I can buy that. Does anyone else have any thoughts on this notion of wikis and collaboration as applied to SOA governance?

Garone: I don’t really have a lot to add. The two guys who just talked gave a great view of this particular question, and I agree with virtually all of it. After a while, it becomes something that a few key contributors, people who actually have the power, control, and knowledge, would be part of. I waxed philosophical in my head and asked, "Well, is it then still a wiki or is it in fact a collaborative tool among a set of decision-makers who, through policies themselves, are able to make changes or not?"

Gardner: I think you're right. The key word here is collaboration. I believe that IBM is going to be coming out soon with something called Jazz, which is a collaborative application lifecycle management approach. We are seeing more collaboration across different aspects of the whole development-to-deployment environment and we are looking for the tools to do that. Web 2.0 is perhaps stepping up and saying, "We have some tools that can be used in that way." Perhaps, it's not just a matter of dropping a wiki into the process, but something a bit more tailored to an aspect, but somehow availing all the participants of each others' wisdom in the process.

Kobielus: It’s like an open source project. You have a broad range of contributors, but only a handful of committers who can actually commit changes to the underlying code base. So, you might have a wiki that has potentially 3,000 different contributors, but ultimately there might be a moderator or two whose job it is to periodically weed out the nonsense, and crack the wiki whip to make sure that what’s actually been posted reflects the wisdom of the crowd of 3,000 people and not necessarily the vandalism of the few who decide to just disrupt the process.

Garone: And that’s a governance model in itself.

Gardner: Yeah, that’s right. It’s governance, and it relates back to what we’ve discussed in trying to find analogies in geo-politics for technology governance. You want the best of both. You want a federated approach, where they get grassroots input, but you also need command and control. So, it’s Jefferson and it’s Hamilton, right?

Kobielus: It’s Aaron Burr occasionally too. You’re going to follow the pistols.”

On the growing role of wetware as the underlying implementation of SOA-accessible resources in a platformless service cosmos:

Kobielus: Web 2.0 is really HOA, Human Oriented Architecture. It is pretty much giving human beings the tools to share what’s in their minds, to share their creativity with the big wide world. SOA, Service Oriented Architecture, is about sharing and reusing all matter of resources in a standardized way. HOA, the Web 2.0, is the most critical resource, and the most inexhaustible energy supply is human ingenuity and creativity.

Gardner: That’s like Cosmic 2.0. Woah!

Kobielus: Yeah, I have been known to get cosmic. People who have read my blog realize that I am a total space cadet.

Baer: Jim, I'll give you the award this morning for coining the best buzz words, like "Cracking the wiki whip" and "Human Oriented Architecture."

On the financial substrate—mergers, acquisitions, revenues, profits, etc--that continues to drive and shape all the SOA plasticity in a platformless service cosmos:

McKendrick: One effect of the whole compliance scenario was that it gave vendors another hype factor. I'm going to try another buzz word. How about Hype-Oriented Architecture? HOA. Using Jim’s HOA for another purpose.

Kobielus: It’s better to have hype-oriented accounting.

McKendrick: Hype-oriented accounting? I think the whole compliance thing gave a boost to the IT industry in the early 2000s. What do we call this decade anyway, the 2000s?

Gardner: The oughts.

McKendrick: It gave the whole industry a boost at a time when things were kind of down with the IT recession. The whole compliance scenario helped business intelligence and the data-environment vendors who directly addressed the flow of financial information.

Gardner: I’d like to conduct an experiment. I think we should take an accountant out to lunch. Anyone who knows an accountant, take them out to lunch and tell them how great IT is and what SOA can do in terms of long-term efficiency and lower total costs. Bring in some of the other mega trends, such as software as a service, virtualization, and data master management. It behooves us all to educate the accounts on why IT is important, because I think they are suffering from a lack of understanding.

Better yet, take a chief financial officer out to lunch and then take the accountants out to lunch. This is the crowd we need to work on. We keep talking about trying to convince the CEO and the CIO, and I think we need to get right down into the bean counters' frontal lobes on SOA.”

Convincing the wetware that controls the money that shapes the contours of this exploding plastic inevitable universe.

Lunch is about as real as it gets.


thenagin The SOA Mike Brady Metaphor




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?


Wednesday, August 29, 2007

thenagin The SOA Burning Bush Metaphor




This was the week (Friday, March 9, 2007) we had Richard Soley, chairman and CEO of the Object Management Group (OMG) as our guest. As for the regulars, it was Gardner, Garone, McKendrick, Baer, and Kobielus. The primary topic that week was OMG’s creation of an “SOA Consortium.”

The focus of discussion was on how we generally—and OMG’s new “SOA Consortium” specifically--can best spread the gospel of SOA within companies. I heard the words “advocacy,” “evangelism,” and “best practices.” It was all about how CIOs can proselytize the SOA message down to IT and business groups, and how we all can learn to speak a common SOA language, bond more completely, and re-dedicate our working lives to this all-embracing business-renewing philosophy and so forth.

Am I crazy in reading a quasi-religious overtone into all this? Here’s OMG’s Soley on his group’s ever-morphing mission, which has recently begun to focus on a new crusade that involves ministering to the needs of SOA true believers. Read his actual words and tell me what you think:

“Soley: Sure, the Object Management Group is an 18-year-old consortium of software users and vendors, academics, and a growing number of government institutions focused on delivering standards to make interoperability and portability a reality. We were founded in 1989 focused on object technology, later grew into distributed object technology, and were best known for the first few years for our Common Object Request Broker Architecture (CORBA).

In 1997, we moved in two new directions; one being the adoption of a unified modeling language with the clever name, Unified Modeling Language (UML), and also into vertical markets -- originally healthcare, finance, telecommunications, and manufacturing, although we are now in about 25 different markets, everything from robotics to regulatory compliance.

In 2000, we actually leveraged that modeling technology and made it the base technology for all of the efforts that we have under way. So, we defined business models and software models, and, in some cases, even hardware models and process models.

The next big leap came in 2005, when we merged with Business Process Management Initiative (, so that now all of the modeling languages from meta modeling languages like Meta-Object Facility (MOF), to business modeling languages like Business Process Modeling Notation (BPMN), to software modeling languages like UML, and systems engineering languages like SysML are all in one place. That’s been our focus, but looked at from another dimension, what my staff is really good at is getting competitors to agree on things.

We have been doing that at OMG for 18 years with, at this time, between 500 and 600 member companies. We were approached by a group of 11 companies to create a community around SOA, an advocacy group, not a standards group, which is why it’s separate from OMG. We strongly believe that SOA isn’t a technology at all, but rather an approach to achieve business agility. It’s not a technology, but rather a business strategy…..

[I]t’s important to understand that this is not a standards organization. There are plenty of organizations focused on SOA standards and, in fact, OMG is one of them. Let’s get this straight upfront -- we are going to pronounce it SOA (So-wah) from now on, because, otherwise you can’t say, "SOA what?"

Our SOA group at OMG has been focused on modeling SOA, modeling for software assurance, and modeling for software producibility, and so forth….It’s an advocacy group. How do we help the CIO? And, we call this "Corner Office SOA." How do we help the CIO get the news across to the rest of the C-suite that this is not a technology but a business strategy, and a business strategy that can deliver agility and a better bottom line?

Second, "Ground Floor SOA." How do we help the enterprise architect, the domain architect, the data architect get the word across to his alter ego in the line of business that this is a business strategy and not a technology and it’s something he needs to pay attention to?”….

It’s important first of all to note the mix of users and vendors. We are currently running 3-to-1 end-users to vendors, and that’s because the focus is on this advocacy activity. It’s not on whose SOA infrastructure we should buy and "Our Web service is cool," or any of those questions. I am guessing that we are actually going to be more like 5-to-1 or 10-to-1 end-users to vendors eventually, but, as you can see, on Feb. 12 four vendors stepped up to the plate to fund it and get it off the ground. They were BEA, Cisco, IBM, and SAP. ….

You also saw, as you said, some very dedicated end-users who have ideas about how to get the idea across to the lines of business that this is not a technology play, but a business agility play. …. We expect that the SOA Consortium is going to weighted toward end-users, although there will be a couple of sponsors joining…..

[End users] are not building reference models. They are sharing case studies. For example, our enterprise architects and our community of practice is showing case studies of success stories and, more importantly, failure stories, best practices, what works, what doesn’t work? We have even had sessions on how to influence project managers and product managers in the line of business to understand business strategies in general, rather than think of us as “the guy who fixes my Treo.”

We received a lot of feedback from CIOs and CTOs during the [early] summits that said this is very important. We had a Fortune 100 CIO who came into the New York summit. This person is CIO of a multi-billion dollar travel organization, and the opening gambit that we heard was, “Look, this is just a technology play, and if one of my technology guys hadn’t told me I had to be here, I wouldn’t be here. I’ve already told the CEO that SOA is a technical thing, and we’ll take care of it.”

At the end of the summit, this particular CIO stayed an extra half hour and said, “The most important thing I learned is that I can now understand how I can position this as -- rather than a technology play -- a business agility play. That will support the efforts that I am making to make our business processes understood, to write them down in a way that’s reusable and discoverable, and in a way that I can make them more efficient. And, I am going to go back to the CEO and say it’s not a technology play.”

While on the call, I heard Soley’s mention of end users sharing SOA “failure stories,” and that sounded like a bit more true confession than most IT or business analysts are willing to own up to (full disclosure: it’s been many years since my last confession, and you know where I’m going). So I called him on it:

Kobielus: There’s definitely a value for an advocacy organization like this to spread best practices regarding SOA and SOA deployment and management. You mentioned that one of the functions of these – for lack of better term, dog and pony shows -- meetings in various cities is for the CIOs to share both the success stories and the failure stories regarding SOA deployment. How eager are CIOs to share their failures and their screw ups in implementing SOA?

Soley: You saw how carefully I didn’t mention even the gender of the CIO who made that comment in New York. I will admit there was one time we had to turn off the tape recorder, which we were using just to have notes so we can get the quotes right later on. They are willing to share. We find this at the level of CIOs and CTOs, as well as at the level of enterprise architects. They are willing to share failure studies, if they have the safety and security of knowing they are not going to be quoted, it’s not going to be on their performance reviews, and they know that others in the room are going to do the same.

Listening to one of these stories, actually it was in San Francisco, gave me an instant flash to my kids high school in Lexington, Mass. It blew me away the first time I saw this. There's an enormous board in one of the major cafeterias. It’s labeled "The Board of Rejection," and all the kids post their rejection letters up there, and I thought, "My God. I never could have done that 30 years ago, when I was graduating high school."

But kids write notes on them and say, "They don’t know what they missed," and "You’ll get accepted somewhere else." And, they really help each other out. I think they all understand that failure stories are just as important as success stories. In fact, more important, because it’s very difficult to justify cost savings. It’s far easier to justify increased revenue. So, they do it and I will admit that the enterprise architect level folks do it more readily.”

Ah, there’s the rub. IT professionals, like any other weak mortal, are willing to share their screw-ups if, as Soley stated, “they have the safety and security of knowing they are not going to be quoted, it’s not going to be on their performance reviews, and they know that others in the room are going to do the same.” You’ll confess because there’s a screen in the confessional, you’re not giving your name, and the priest is sworn to confidentiality (though, let’s not kid ourselves, Father Van recognizes your voice, Jimmy).

Of course, who’s to say what constitutes an SOA “failure” unless you can measure your performance against SOA commandments that have been carved in some relatively solid stone by some reasonably recognized lawgiver. That’s why I brought up the issue of OMG possibly “certifying” SOA practices that have been mapped against established holy writ, in the form of IT/business best-practices frameworks:

“Kobielus: I think the industry is looking at the SOA Consortium or OMG to be a third-party certifier -- maybe that’s overstating your mission -- of enterprises' success or lack thereof in implementing SOA. So, it’s the extent to which you are going to be mapping these SOA best practices back to such recognized frameworks as ITIL, Six Sigma, and so forth that would be essentially what the industry is looking for you guys to do -- to catalyze that kind of mapping.”

Soley’s response:

Soley: The SOA Consortium is looking to not only OMG, but other standards consortia, to deliver standards, mappings, and validation endorsement certifications where appropriate. In fact, it’s in the mission statement that the SOA Consortium is not a standards organization, but it will deliver requirements to standards organizations and where we were talking about modeling things, those requirements would be handed to OMG.

One of the 10 largest banks in the world sent an executive to one of our meetings, and this person said, that all they care about in terms of metrics of success are Lean and Six Sigma, so we're going to need to connect SOA to that world in order to be successful at that bank. I think that’s part of it, but there’s more than that. There are going to be metrics that are not yet in the stack when you fly through the ITIL, Six Sigma and Lean documents.

OMG, as it happens is moving into the direction of maturity models anyway. We are just starting work on a business-process maturity model. You may have read about it. It’s not a standard yet, but it was just starting. What were talking about is a maturity model for business process adoption that measures organizations and their ability to capture business processes. That’s very strongly related to SOA, but again, that’s a standard and belongs in OMG and not in the SOA Consortium.”

Oh…I just noticed that he used the word “summit” over and over to describe the events where the high CIO priests of SOA convene. See what I mean?

Anyway, I don’t want this to come off as too cynical, on my part. But, in my working life, I’ve been “certified” on Myers-Briggs, and Total Quality Management (TQM), and ISO 9000, and at least a few other daylong seminar disciplines instilled/installed in me by goateed parachute-in consultants. And none of those experiences made me feel like I derived anything of enduring value, in terms of wisdom or practical skills.

Of course, this time around, I’m definitely more of an SOA “high priest” than layperson. But SOA is such a heterodox paradigm, with we the faithful having such a wide range of belief and practice, that I can scarcely imagine what validity or value an “SOA certification” doctrine might have.

All I can think of are the sore behinds of the poor parishioners, seated on those wooden pews, listening to the SOA gospel being droned from on high, thinking their own thoughts, struggling to stay conscious.


Sunday, August 26, 2007

thenagin The SOA Hip-Hop Mixmaster Metaphor




This particular podcast, recorded on March 2 of this year, involved myself plus Messrs. Gardner, Garone, McKendrick, and Baer—and, accepting my request to participate for the first time, Dave Linthicum.

I invited Dave because, obviously, he’s a leading SOA industry analyst with plenty to say. But what prompted me to invite him at this particular juncture was a stimulating column he’d published in February on the topic of “mashup governance.” I was intrigued by the juxtaposition of anarchy (“mashup”) and control (“governance”) in that concept. I also liked the fact that “mashup”—a term from popular culture, in particular, from the world of sample-happy hip-hop music—is invading the world of SOA, highlighting the need to foster an x-factor of creativity, quirkiness, spontaneity, and fun in the crafting of reuse-happy composite services. Definitely had to have Dave on the call, and he’s been a semi-regular since (though he’s often tied up on Friday mornings with actual work, so it’s hard for him to set aside a late-in-the-week hour of probono jawboning—hard for the rest of us too, for that matter).

I’ll let him speak first, then me and the others. Dana started it off by asking Dave to explain how “mashup governance” ties into SOA and “Enterprise 2.0” (Jim now-note: I’m not endorsing that latter term—SOA is already nebulous enough—“Enterprise 2.0” takes SOA, mashes it up into the also-nebulous “Web 2.0,” and generates one of the most perfect semantic vacuums in today’s tech universe):

“Linthicum: …. That was a feature article, by the way, that InfoWorld sponsored, and it’s still up on their website. It basically talked about how mashups and SOA are coming together, since they are mashing up. As people are becoming very active in creating these ad-hoc applications within the enterprise, using their core systems as well as things like Google Maps and the Google APIs, some of the things that are being sent up by Yahoo!,, and all these other things that are mashable. There's a vacuum and a need to create a governance infrastructure to not only monitor-track, but also learn to use them as a legitimate resource within the enterprise. Right now, there doesn’t seem to be a lot of thinking or products in that space. The mashup seems to be very much like a Wild West, almost like rapid application development (RAD) was 15 years ago. As people are mashing these things up, the SOA guys, the enterprise architecture guys within these organizations are coming behind them and trying to figure out how to control it….[Y]ou really need a rudimentary notion of governance when you deal with any kind of application or service that works within the organization….[G]overnance is a management practice. It’s running around knocking people on their heads, if they are not using the correct operating systems, databases, those sorts of things. In the SOA world, as Joe McKendrick can tell you, it's about a technical infrastructure to monitor-control the use of services. Not only is it about control, but it is about productivity. I can find services. I can leverage services, and they are managed and controlled on my behalf. So, I know I am not using something that’s going to hurt me….The same thing needs to occur within the mashup environment. For mashing up, there are lots of services that we don’t control or that exist outside on the Internet. It's extremely important that we monitor these services in a governance environment, that we catalogue them, understand when they are changed, and have security systems around them, so they don’t end up hurting productivity or our existing IT infrastructure. We don’t want to take one step forward and two steps back.”

Now me, seconding everything that Dave and Dana had just said; adding a groaning new metaphor that I won’t extend here-now; mashing some 2-year-old Kobielus content into the mix {thanks, Dana, for linking to that article from your page, hence from here-now too); and then suggesting how we can enable a practical balance between creativity and governance in the SOA design-time:

“Kobielus: ….”[T]he whole notion of mashups is half-way to anarchy, as it were, creative anarchy. In other words, empowering end-users, subject-matter experts, or those who simply have a great idea. They typically slap together something from found resources, both internal and external, and provision it out so that others can use it -- the creative synthesis.

This implies that governance in the command-and-control sense of the term might strangle the loosey-goosey that laid the golden egg. So, there is that danger of over-structuring the design-time side of mashups to the point where it becomes yet another professional discipline that needs to be rigidly controlled. You want to encourage creativity, but you don’t want the mashers to color too far outside the lines.

Dave hit the important points here. When you look at mashup governance, you consider both the design-time governance and the run-time governance. Both are very important. In other words, if these mashups are business assets, then yes, there needs to be a degree of control, oversight, or monitoring. At the design-time level, how do you empower the end-users, the creative people, and those who are motivated to build these mashups without alienating them by saying, "Well, you've got to go to a three-week course, you've got to use these tools, and you've got to read this book and follow these exact procedures in order to mashup something that you want to do?" That would have clearly stifled creativity.

I did a special section on SOA for Network World back in late 2005. I talked to lots of best practice or use cases of SOA governance on design time, and the ones that I found most interesting were companies like Standard Life Assurance of Scotland. What they do is provide typical command-and-control governance on design time, but they also provide and disseminate through the development teams a standard SOA development framework, a set of tools and templates, that their developers are instructed to use. It's simply the broad framework within which they will then develop SOA applications.

What I am getting at here is that when you are dealing with the end users who build the mashups, you need to think in terms of, “Okay. Tell them in your organization that we want you to very much be creative in putting things together, but here is a tool, an environment, or enabling technology that you can use to quickly get up to speed and begin to do mashing up of various resources. We, the organization that employs you, want you, and strongly urge you, to use these particular tools if you wish your mashups to be used far and wide within the organization.

"If you wish to freelance it internally, go ahead, but doesn’t mean we are necessarily going to publish out those mashups so that anybody can see them. It means we are not necessarily going to support those mashups over time. So, you may build something really cool and stick it out there, but nobody will use it and ultimately it won’t be supported. Ultimately, it will be a failure, unless you use this general framework that we are providing."

Dana then suggested that we try not for force-fit existing SOA governance approaches to the new frontier of content-aggregating mashups under “Web 2.0” (yeah, I know, another x2.0 phrase in common currency, but this one has a bit more differentiated substance than “Enterprise 2.0,” so I can sorta live with it):

Gardner: I think we need to re-examine some of these definitions. I'm not sure what we are talking about with mashup governance is either "run time" or "design time." It strikes me as "aggregation time." Perhaps we don’t even need to use existing governance and/or even federate to existing governance. Perhaps it's something in the spirit of Web 2.0 and Enterprise 2.0, as simple as a wiki that everyone can see and contribute to, saying, “Here is how we are going to do our mashups for this particular process." Let’s say, it is a transportation process, "Here are the outside services that we think are worthwhile. Here are the APIs, and here is a quick tutorial on how to bring them into this UI." Wouldn’t that be sufficient?”

Steve Garone then swung the discussion back from mashup anarchy (the forbidding pole toward which Dana appeared to be mushing his SOA dogsled) toward the even icier antipodes of governance risk and compliance. Here’s Steve now, stating a set of concerns that are sure to warm the cockles of IP lawyers hearts everywhere:

“Garone: I am going to push back on that a little bit. What we are wrestling with here is achieving a balance between encouraging creativity and creating new and interesting functionality that can benefit business, and keeping things under control. The best way to look at that balance is to understand what the true risks are. The way I see it, there are several major areas. The first has to do with what I call external liability, meaning that if you, for example, publish a mashup to a customer base that has a piece of functionality you got off the web, and for some reason that has wrong information and does the customers some harm, who is responsible for that? How are you going to control whether that happens or not? The second has to do with what I call internal risk, which has to do with making available to the outside world information that is sensitive to your organization. In that case, a little more than what you described is going to be necessary, and can also leverage some of the governance infrastructure that people are building generally and relative to SOA…..[W]e all know that in this world anybody can sue for anything, and the reality is that if I go to a company’s website and use a function that incorporates something that they grabbed off the web, and it does me harm, the first place I am going to look is the site that I went to in the first place.”

After this cold dousing from Mr. Garone on our SOA mashup rave, Mr. McKendrick, being the professional analyst that he is, had to go and get all analytical and definitional on us all, asking what, precisely, distinguishes a “mashup” from more familiar SOA development constructs, such as “composite applications.” Take it from here Joe:

“McKendrick: …..[W]hat exactly is the difference between a mashup and a composite application that we have been addressing these past few years within the SOA sphere? The composite application is a service-level application or component that draws in data from various sources, usually internal to the organization, and presents that through a dashboard, a portal, or some type of an environment. It could be drawn from eight mainframes running across the organization. Obviously, the governance that we have been working so hard on in recent years to achieve in SOA is being applied very thoroughly to the idea of composite applications. Now, what is the difference between that and a mashup? Other than the fact that mashups may be introducing external sources of data, I really don’t see a difference. Therefore, it may be inconsistent to "let a thousand flowers bloom" on the mashup side and have these strict controls on the composite application as we have defined in recent years.”

Then Mr. Linthicum closed the loop very well, responding to Joe’s concern by stating that “mashup governance” is just another set of requirements that must be addressed under a comprehensive SOA governance approach—not through a stovepipe governance domain:

“Linthicum: The reality is that there is no difference. You are correct, Joe, and I point that out in the article as well. There are really two kinds of mashups out there: the visual mashups, which are what we are seeing today, where people are taking basically all of these interface APIs and using the notions of AJAX and other rich, dynamic clients, and then binding them together to form something that is new. The emerging mashups are non-visual. It's basically analogous, and is not exactly the same, as traditional composite applications that are -- if you can call them traditional -- in the SOA realm today. They have to be controlled, managed, governed, and developed in much the same way.”

But I then pushed back on this too-early consensus, arguing that--though we need a comprehensive governance environment for visual and non-visual mashup/composite applications--we also need to make sure that an enterprise’s governance environment clearly delineates which content/resources in which internal and external domains is available/kosher for end users (i.e., the primary “developers” in this new paradigm) to mashup:

"”Kobielus: There is a difference here. I agree with what Dave just said that mashups are not qualitatively different from composite apps, but there is a sort of difference in emphasis, in the sense that a mashup is regarded as being more of a user-centric paradigm. The end-user is empowered to mash these things up from found resources.

It relates to this notion that I am developing for a piece on user-centric identity as a theme in the identity management space. The whole Web 2.0 paradigm is user-centric -- users reaching out to each other and building communities, and sharing the files and so on. Mashing up stuff and then posting that all to their personal sites is very much a user-centric paradigm.

There's another observation I want to make. I agree that the intellectual property lawyers are starting to salivate by mashups invading their clients or encroaching on their clients’ rights. Actionable mashups are good from a litigator’s point of view. In terms of governance then, organizations need to define different mashup realms that they will allow. There might be intra-mashes within their Intranet -- "Hey, employee, you can mash up all manner of internal resources that we own to your heart’s delight. We will allow intra-mashes, even extra-mashes within the extranet, with our trusted partners. You can mash up some of their resources as well, whatever they choose to expose within the extranet. And then, in terms of inter-mash or Internet wide mashing, we’ll allow some of it. You can mash Google. You can mash the other stuff of the folks who are more than happy to let you mash. But, as an organization, your employer, we will monitor and block and keep you from mashing up stuff that conceivably we might be sued for."

“Intra-mash”? “Extra-mash”? “Inter-mash”? I just mashed those words together on the spur of the moment. No, they haven’t entered my everyday working vocabulary either. Anyway, Tony Baer came next, and had a cool linkage of what I just said to the notion of a “walled garden” for controlled-yet-spontaneous (yikes!) mashup within an enterprise environment:

“Baer: ….Composite apps, at least as I've understood the definition, came out of an SOA environment. That implies some structure there, whereas mashups essentially merged to Web 2.0 with the emergence of AJAX-style programming, which lets anybody do anything anywhere with this very loosely structured scripting language. There are practically no standards in terms of any type of vocabulary…..So, there is a bit of a "Wild West" atmosphere there. As somebody else said, you really need to take a two-tiered approach. On one hand, you don’t want to stifle the base of innovation, a kind of a skunk works approach. Having a walled garden there, where you're not going to be doing any damage to the outside but you are going to promote collaboration internally, probably makes some sense. On the other hand, even if the information did not originate from your site, if you're retransmitting it there is going to be some implication that you are endorsing it, at least by virtue of it coming under your logo or your website….

So, you need a tiered approach….You really need to exert control on the sources of information. Therefore, for the types of information that are exposed internally -- for example something from an internal financial statement -- you need to start applying some of the rules that you've already developed around internal databases. Different classes of users have a right to know and to see it and, in some cases, some read-write privileges.

You need to apply similar types of principles at the source of information. Therefore, if I have access to this, this means implicitly that I can then mash it up, but you have to really govern it at the original point of access to that information, at least with regard to internal information. With external information, it probably needs to go to the same type to clearance that you would exert for anything that goes out on the corporate website, the external website.”

Dana then had a brilliant observation on the need f or third-party high-quality Internet-mashable data sources that are generally trusted and reside in a litigation-free zone:

Gardner: …. I was thinking about the adage that nobody was fired for using IBM, which was a common saying not that long ago. What if we were to take that same mentality and apply it here -- that if you're going to do mashups, make sure they are Windows Live mashups, or Google mashup services for mashup; or maybe So, is there is an opportunity on the service provider side to come up with a trusted set of brands that the IT people and the loosey-goosey ad-hoc mashup developers could agree on to use widely? They could all rally around a particular set of de-facto industry standard services? That would be perhaps the balance we're looking for…..[T]he people who are providing the current set of internal services and/or traditional application functionality need to be thinking, "Shouldn’t I be out there on the wire with a trusted set?" We're already seeing Microsoft move in this direction with its Windows Live. We're seeing Google now putting packaging around business-level functionality for services. is building an ecology, not only of its own services, but creating the opportunity for many others to get involved -- you could call them SaaS ISV’s, I suppose. And I don’t think it’s beyond the realm of guesswork that Oracle and SAP might need to come up with similar levels of business application services that create what would be used as mashups that can be trusted to be used in conjunction with their more on-premises, traditional business applications.”

Dave then pointed out that there are already some SaaS-oriented third-party providers of business-oriented data that can—at a price—to leveraged to enrich, enhance, augment, mash, aggregate, and integrate into existing SOA apps. He mentions StrikeIron, whom both Baer and I have spoken with, and whom I agree is an important player in this growing space. But I’d also like to point out that the leading business intelligence (BI) vendor, Business Objects, has also committed publicly to this direction, under its “Information on Demand” strategy (see their press release from May 22 of this year). Now for what Dave said:

Linthicum: ….People are moving to use interface-based applications through software-as-a-service. All you have to do is look at the sales of to monitor how that thing is exploding. And, they are migrating over to leveraging services to basically mix-and-match things at a more granular level, instead of taking the whole application interface and leveraging those within your enterprise. This is what I call "outside-in" services. I wrote about that three years ago.

People are going to focus on that going forward, because it just makes sense from an economic standpoint that we leverage the best-of-breed services, which typically aren’t going to be built within our firewall. We don’t want to pay for those services to be built, but they're going to be built by the larger guys like, Google, and Microsoft. It's going to be a slow evolution over time, but I think we are going to hit that inflection point, where suddenly people see the value. It’s very much like we saw the value in the web in the early '90s -- that it really makes sense not only to distribute content that way, but distribute functional application behavior that way…..

You are going to see some aggregators out there. Right now, you’re seeing guys like StrikeIron, which is a small company, but they aggregate services. They are basically a brokerage house for services they control, validate, and make sure they are not malicious. Then, you rent the services from them, and they in turn pay the service provider for providing the service. I think Google is going to go for the same model.

Gardner: It’s about trust ultimately, right?

Linthicum: It’s about trust ultimately. If I were a consultant with an organization and my career was dependent on this thing being a success, I'd be more likely to trust StrikeIron and Google than some kind of a one-off player who has a single service which is maintained in someone’s garage.”

Then the conversation shifted abruptly to a then-just-recently announced corporate-level mashup: Oracle’s acquisition of rival BI, corporate performance management (CPM), and master data management (MDM) vendor Hyperion. What most distinguished this particular acquisition was Hyperion’s strong positioning in the financial CPM market, addressing the strategic planning, budgeting, consolidation, and reporting needs of CFOs. My prime concern then, and still, is the amount of functional overlap between Oracle’s and Hyperion’s products—making the decidedly non-hostile deal feel a bit like Siebel-acquisition-redux and PeopleSoft-acquisition-redux—in other words, merging, munging, and mashing a direct rival under the growing Oracle big top. What I said on that day, and still stand by:

Kobielus: It makes sense knowing Oracle. First of all, because [Oracle Chairman and CEO] Larry Ellison has been very willing in the past to grab huge amounts of market share by buying direct competitors like PeopleSoft, Siebel, and so forth, and managing multiple competing brands under the same umbrella -- and he is doing it here. A lot of the announcement from Oracle regarding this acquisition glossed over the fact that there are huge overlaps between Oracle’s existing product lines and Hyperion’s in pretty much every category, including the core area that Hyperion is best known for, which is financial analytics or Corporate Performance Management (CPM). Oracle itself provides CPM products for CFOs that do planning, budgeting, consolidation, the whole thing.

Hyperion is a big business intelligence (BI) vendor as well, and Oracle has just released an upgrade to its BI suite. You can go down the line. They compete in master data management (MDM) and data integration, and so forth. The thing that Oracle is buying here first and foremost is market share to keep on catapulting itself up into one of the unchallenged best-of-breed players in business intelligence, CPM and so forth. Oracle bought the number one player in that particular strategic niche, financial CPM , which is really the core of CPM -- the CFOs managing the money and the profitability.

It’s a great move for Oracle, and it definitely was an inevitable move. There will be continuing consolidation between the best-of-breed, pure-play data management players, such as Hyperion and a few others in this space, which are Business Objects and Cognos. They will increasingly be acquired by the leading SOA vendors. Look at the SOA vendors right now that don’t have strong BI or strong CPM, and look at the pure-plays that have those tools. The SOA vendors that definitely need to make some strategic fill-in acquisitions are IBM, Microsoft to a lesser degree, BEA definitely, and a few others, possibly webMethods. And, look at the leading candidates. In terms of CPM and BI and a comprehensive offering, they are down to three: Business Objects, Cognos, and SAS.”

Yes, there certainly will be more corporate mix-and-mashups in the SOA, BI, and CPM space—soon. Oh wait, there has been one noteworthy mashup since March: Software AG and webMethods.

Fall’s coming, I can just feel it, even through the late-August humidity.