ABOUT | COPYRIGHT

Service Oriented, Process Centric, Model Driven Heresies

latest news

11.25.2007

Composite Software Construction minibook published

09.23.2007

WSDL 2.0 metamodel published

07.08.2007

WSPER's primer released for comments

Book

Blog roll

12/19/09 :: [BPM] IBM buys Lombardi, SO WHAT? [permalink]

Dr. Berne would probably be amused by the BPM field: all the BPM children want to behave well and explain how IBM (one of the parents) is going to deal with one of the rare grown ups in the field. They all go through excruciating details to explain how all the pieces of the puzzle fit: Sandy, Bruce, Judith, Scott... The Golden BlahBlah Award, for sure, goes to Tony Baer, unconditionally.

Some even felt it was time to crunch more numbers. You know what is the size of the BPM market? $3B. Yes, IDC has predicted that 2013 the size of the BPM market will be $3B. The problem is, that $3B prediction has been a rolling prediction since at least 2004. Miko, is there a formula to calculate the growth rate of a rolling target? I think it is exactly 0.2%.

So why did IBM buy Lombardi? The world is holding its breath, waiting for the answer. Is it because Frank Leymann needed to win its BPMN to BPEL argument? Maybe. WebSphere Business Modeler (which first appeared on the market in 1955) needed a face lift? Hum... how about, BlueWorks sucks?

Not sure, what is certain is that BPM is not going very well at all and instead of going through the morbid exercise of trying to see which piece fits with which and which widget will survive the acquisition, the BPM pundits like Sandy, Bruce or Scott would be better inspired reflecting on why BPM is so abysmal? Why BPM's target is 0.2%? No, these people will defend the indefensible: the fallacy that you can somehow refine little by little, one layer of metadata after another from the business analyst to the integration developer.

This phase of BPM is over, the acquisition of Lombardi signals that the last decade has been a complete waste, that pretty-picture-to-execution does not work, otherwise, I can guarantee you it would be the other way around, the BPM market would be about $200B and Lombardi would have bought IBM. BPM, as it was designed an preached by the pundits, the "experts" cannot stand on its own. Live with it. Middleware has won, of course, because ultimately, the value is in the execution not the notation, and you can't achieve execution without a strong service oriented, process centric, model driven programming model. Not that IBM and Oracle are there yet, but they'll get there, make no mistake (Microsoft shot itself in the foot in that space when it put the mighty CSD "in charge" of solving that problem).

The question today is not, which pieces will go where, the question is going to be how can you influence these vendors to the right thing? In the end, they care about doing the right thing. Make no mistake. They are just poorly advised: BPEL is not a technology that plays directly at the business process level and no you should not attempt to reduce BPMN "isomorphically" to BPEL, at home, in the lab, at the OMG or anywhere else.

Allow me to reiterate what I wrote in the "Seven Fallacies of Business Process Execution" article. The business, hence IT, hence IBM and Oracle, care about 4 things:

Build solutions rapidly with projects as small as possible (rely on many iterations)

Change solutions rapidly and support an iterative lean six sigma approach

Be able to visualize the business design in operation at the present time without complex “current-state” projects

Be able to gain operational intelligence from the current business design without complex measurement projects

In other words, Michael, the business cares about agility and visibility. Who said that the business cares about having a business-process-model-notation-to-execution engine? Who said you cannot meet these core requirements without a business-process-model-notation-to-execution engine? Ismael, Assaf, thank you for setting BPM on such a wonderful course, you guys deserve an industry award for such a service. Architecture and standards do matter, in case you have not noticed.

The business rarely cares when changes are implemented in two minutes or two days. Two days is a great first step ! The business doesn't really care if one person or two will be translating their business problem into a working solution. Who said the business wanted to eradicate IT? The problem you see is that in 2010, in the enterprise, you can't deploy anything of value in less than 3 months with a team smaller than 10 people -if you are lucky. This is a great improvement from the early 90s, where projects were commonly 2-3 years and 100 people, but it is not enough. We need more, especially on the visibility side.

So as long as the Bruces, Sandys and Scotts of the world will insist on the corny idea of "executable notation", as long as the the Michaels and the Franks of the world will tell you "we have a solution, slap a notation on BPEL, isomorphically map BPMN to BPEL", as long as that will happen, we will be in this vortex. Guys don't you think that trying for 10 years with the "best" minds of this world, PhDs, Professors, Hackers... is not the proof that it does not work? Don't you think that it is time to try something else? With the foundation that we have learned, of course. Don't throw away BPEL, don't throw away BPMN, just find a different articulation. How hard can that be? It's Win-Win all the way.

The vast irony of this story is that my 2002 articles are still referenced in BPMN 2.0. Somebody must like me very much to keep giving me this honor despite all that I write, but the only thing I care about is that their content be understood and that the articulation between BPMN and BPEL be designed per my recommendations.

The only path to move forward is to:

a) Give up on the pretty-picture-to-execution path for now, I don't know if it will be possible in the future, but give it up now, today, not tomorrow, don't create executable BPMN or a BPEL notation, don't, don't, don't.

b) Introduce the concept of business entities and business entity lifecycles both at the engine level and articulated with BPMN and design a service oriented, process centric, model driven programming model. BPEL at it's core is fine, someone might find something better one day, but let's start with it today.

Most of the theoretical work has been done by Ksenia Whaler at IBM Zurich Research Lab. The notation is here and it is good, the engine is built and humming. It is shovel ready.

12/14/09 :: [Other] Most Popular Content for 2009 [permalink]

2009 was a great year by many accounts, most of all, I am both happy and proud to have joined MomentumSI. I rarely have felt as good about my job. MomentumSI is a bunch of great people working on great projects with great customers. We specialize in SOA and Cloud, BPM and we do a bit of MDE.

In the mean time, ebpml is growing steadily, and here is a list of the most popular content:

12/11/09 :: [BPM] BPM: BPMN and BPEL [permalink]

Scott Francis answered my last post on his blog. I appreciate the dialog, thanks. He explains:

I think most BPMN folks feel that BPEL is neat stuff, it just has little to do with the business process per se because it is designed for a different use and audience.

Scott, we agree ! I, by no means, imply that BPEL has anything to do with "Business Process per se". It is indeed designed for a completely different use and audience. I have been fighting this idea since 2002 with people like Howard Smith or Assaf Arkin. I thought this debate was over until Michael and Frank reignited it. I am not surprised at what they say, it is unfortunate that some people in our industry seem to think that the more you say something, the more correct it becomes.

But I think you misunderstand where the “BPMN Camp” would draw the line around the process – indeed, those state changes would not be part of the “process” per se – triggering the state changes, but the actual management of the state changes will be via webservices, or other means. Those webservices are outside the BPMS for obvious encapsulation reasons.

I think this is where we start to diverge and this is where I stop supporting the BPMN community. This is where the articulation between BPMN and BPEL needs to happen. It is not enough to say the states are beyond the process, buried in the services. As Ksenia Whaler showed in her work processes must be compliant with the Business Entity Lifecycles they interact with. There is simply no way around it. Pretending that BELs are over the fence and processes can be designed in complete abstraction of the constraints the impose is pure fallacy. I apologize for the language, but there is simply no other word. This is documented, demonstrated and proven. It would be the same as saying that something is Turing complete without the concept of variable (storage).

It just seems to me to be that there’s a massive failure of communication.

I don't think so. I do think that the BPMN camp is massively going in the wrong direction. The BPMN camp is massively ignoring the completeness of "the" Business Process Metamodel and the underlying architecture. I do think that it is not until we all actively define the Business Process Metamodel that we will make progress. I do genuinely believe that the future of BPM can be bright(er) and this is all I am looking for.

you have so many vague buzzwords floating around that can be interpreted so many different ways

Yes, this is true, sadly true and you are very generous by saying "interpreted". It is not until we will all bring precision to this problem that we will eventually solve it.

I read a few of your articles and they seem to have a running theme of being brutally negative about everyone you’re quoting

Yes, I have met most of these people in person, sometime worked with them closely or in working groups. For 10 years the discussion has been impossible. Believe me, it has never been a problem of "interpretation". It has always been a problem of power and ego. Frank explained it correctly: "We built all these BPEL engines, you have no other choice than using them".

just because I don’t find BPEL useful as an implementation of BPMN, doesn’t mean that I think BPEL should be resigned to the 7th circle of Hell – it just means that it should be used for what it is good at – orchestrating webservice calls.

Scott, unfortunately you are part of the problem. You are just another "Mission Accomplished" guy. Congratulation on a job well done! You claim BPEL is not a good implementation of BPMN, hence use it for anything else, "don't bother me", "don't rock my little world". You assume that BPMN is complete, that BPMN accurately reflects the metamodel of Business Process Definition. So in my frame of reference you are not much better than Frank. You say "we have BPMN, I can do stuff with it, and I don't care about anything else".

I choose not to be sad, but rather to move forward creating value with BPM.

Everyone reacts as they wish to this stupid situation. We can all duck and claim a little corner of the BPM space, but what value does it provide to our industry? I worked at a bank until last year. There, two teams had been fired as they tried to introduce BPM and failed. When I say fired, I mean fired. When I talked about BPM in the context of SOA, my manager said, sorry, I won't be the 3rd team. Is that what you are so proud about? Is it just me? Did you read the last post from Rashid Khan? Just give me your estimate for the ratio of business processes implemented within a BPM engine, vs the ones that are hand coded: is it greater than 0.1%? Give me the number of packaged solutions (small or large) that implement a BPM engine to manage the processes they automate: could it be exactly zero? Personally I am extremely saddened by these statistics and the state of BPM and I can't just sell something that I think is foundationally wrong to my customers: "just to move forward" is not an option for me. Allow me to make an analogy to better illustrate my point. If you, Michael, Frank or Bruce were farmers you would be telling me that because you are able to feed yourself, family, friends and neighbors, world hunger is not your problem, even if you knew there were better ways to grow crops. I hope you would allow me to be saddened by such an approach.

BPM is complex, its taking longer to come to fruition.

Come on Scott, can you think of all the unrealized value for all business customers? can you even start to come up with a number just because a handful of people have an ego too big to create value? Just because they want to dominate a market that they are killing. Because it is complex we need the contribution of everyone, we don't need these stupid games that pundits like so much.

Whether you turn to SOA, BPM or MDE (which all require very different ways of growing crops), the same attitude prevails, from big and small vendors alike.

I say, enough is enough. You are either part of the fallacy or you are fighting it. After 10 years, there is no longer an "in between, just to move forward". BPM must make progress, we are currently nowhere in the path to progress. Sorry.

12/05/09 :: [BPM] BPM, the next decade [permalink]

No other debate better represents the rift between the business and the geeks as "BPMN vs BPEL". No other debate better represents how far away the geeks are from what they are supposed to deliver, no other debate better represents how little the geeks care about their customers.

I started to work on BPM at Sapient (a consulting company), in late 1997. Then as a young consultant, I became intrigued at the idea that people were hand coding business processes in C++ (and were failing to do so). I quickly moved on and built my first BPM engine with a small team at the end of 98 at NEC Labs in Boston. NEC killed that project in the spring of 1999 (not because it failed but because it did not want to enter that market) and continued that work at eXcelon (now Progress Software). I actually worked with Michael Rowley, back then, who thought UML Activity diagrams were "the" model for Business Process Definitions. When it did not work, he moved on to the State Machine diagram. When that did not work, he moved on to something else, but I lost sight. Needless to say that Michael does not really have a strong track record of figuring out the right semantics of Business Process Models, executable or otherwise. He is a great software engineer and we can see that through his work on OQL and SCA for instance, but BPM is different. I thought that Michael had finally made some progress this fall when he talked about BPEL outside the context of BPM (in this latest book on SCA):

Ignore, for the time being, the concept of business processes. If you were going to design a language from scratch that was designed for use with asynchronous web services, there is a good chance you would design something very similar to BPEL.

Yes, Michael, that's the right way to look at it. But, no, we are back to the BPMN vs BPEL debate.

What does Michael has in mind when he pushes BPEL (again)?

portability – primarily portability of skills but also portability of code and interoperability of tools.
Basically, [we] are looking for an ecosystem around the language.

Michael, who cares about portability and interoperability when you don't even have the beginning of a foundation that works? The business can't care less about interoperability and portability. The business cares about agility and visibility. The business does not care about an "ecosystem around the language".

Of course, another key figure of BPM stepped in this new iteration of the debate, Frank Leymann. Could somebody be more wrong for such a long time?

BPEL focuses on providing a language for specifying business processes and provides a precise operational semantics for executing processes specified in this language.

You can specify business processes with BPEL? for a start Frank, where are the users? Second, look at the metamodel of BPEL and tell me if your average business analyst can master ReapeatUntil, While or ForEach activities? How well will they handle variables and correlation sets? Handlers? As Michael used to tell me at eXcelon "this is Turing complete", that's all you need.

Frank does acknowledge that BPMN took the lead and hence there is a need for a solution to map BPMN to BPEL because:

Because of the wide-spread support of BPEL by middleware vendors the use of BPEL engines for BPMN execution is an obvious choice. To enable the execution of BPMN process models in BPEL engines, the transformation of BPMN process models to BPEL process models is needed.

But unfortunately:

But the metamodel underlying BPMN and the metamodel underlying BPEL are not identical; in fact they are quite different. Thus, the transformation is not straightforward and sometimes requires complex mappings resulting in a BPEL process model that look quite different from the original BPMN process model (quite a number of publications exist that dive deep into this).

So what does Frank (and Michael) propose? Two solutions:

a) standardize a visual representation for BPEL

b) make transforming BPMN process models to BPEL much easier... [i.e.] a subset of BPMN 2.0 that is naturally supported by BPEL

Not clear enough? Frank suggests to use:

A subset of BPMN 2.0 is “isomorphic” to BPEL

Yes, ladies and gentlemen, BPEL must rule. BPEL (and BPML), the "orchestration" language that single-handedly killed BPM, must rule. The geeks must win, the business analysts must become programmers. Why? Because all the "middleware" vendors built "orchestration" engines (BPEL based or not). Yeah, you heard it right, it does not matter if the vendors got it right or wrong, you must use their crappy products, simply because they built them. Frank, this is rock solid Nobel quality logic. I am therefore I think.

And of course, the salsa between BPMN and BPEL has to happen outside a rigorous Model Driven Engineering framework? Right. I nearly forgot, no relationship to SOA either... The reality is that the geeks like Michael, Frank and others like Assaf can't stand the idea that their corny views about Turing completeness cannot solve a problem that they think is procedural (and forever, they will think it is procedural).

So I repeat what I said a couple of weeks ago: it does not matter how much you pay for your ELA, it does not matter how much money these company make. These "Computing Scientists" will never listen to their customers. They will choose interoperability and portability over agility and visibility. They will always isomorphically map their stupid ideas and products to your needs. Let's give them a round of applause, after a decade, it is still the same people, doing the same thing and you guessed it, we will get the same results in 2020 (sight).

Note, that I did try to engage the "analyst" side as well. They are just as stubborn. Bruce Silver and Sandy Kemsley have refused the dialog, all they can think of is holding on to BPMN and shoot BPEL. This is unfortunate because the solution is quite simple. There is a real articulation between BPEL and BPMN that I have suggested here. This article has been one of the most successful articles of InfoQ with many readers praising the views that I developed. After writing this article, Marlon Dumas introduced me to the remarkable work of Ksenia (Ryndina) Whaler, from IBM Zurich Research Lab (yes IBM), which suggested a similar approach with a strong theoretical foundation. This approach, which at the core, uses the concept of Business Entity Lifecycles, has the merit of creating a very strong articulation (not mapping) between BPMN (the business process model notation) and BPEL (the implementation language of BELs). But, no that would be too easy. The BPMN people, like Bruce or Sandy, are upset about this approach because it introduces a new business concept, the business entity lifecycle, and the BPEL people are upset because BPEL is no longer the "business process execution language" but the BEL implementation language. BELs have the merit of reusing all the investments made by BPEL engine vendors and allow enough freedom to the BPMN people. But, no, that would be way too easy, a win-win situation would make way too much sense in a society that has lost any of its senses and is always looking for "the" winner smashing the loser.

After 10 years or so, we keep using the same arguments year after year after year. Everybody claims that he or she is right without ever looking at the flaws of their approaches. In the mean time, IT and the business are hurting, but these guys don't care. They actually can't care less.

So I would like to extend my thanks to the "BPM" people: Michael, Frank, Bruce and Sandy, not to forget Assaf and Ismael or John, let alone Dave, Conrad, Antoine, Cory and Fred, yes, thank you for a decade of incredible achievements. I am blown away by how strong BPM is. You can be absolutely proud of your achievements and I can only encourage you to continue the course on a job well done. Indeed, our industry has invented the perpetual motion at the speed of zero. Ten years from today, the same people will be talking about the same corny and stupid ideas they struggle with today and wonder why in 20 years nothing has happened. Thank you again.

11/20/09 :: [SOA,BPM,MDE] A Decade of SOA, BPM and MDE[permalink]

Last week, Microsoft made an announcement about Oslo:

Of the key things we observed over the last year was the real, tangible customer value in applying “Oslo” to working with SQL Server. Time after time we heard that “M” would make interacting with the database easier, provided we offered a good end to end experience with tools (VS) and frameworks (Entity Framework and Data Services) that developers use today. We heard that developers wanted to use the novel data navigation/editing approach offered by “Quadrant” to access their data in whatever SQL Server they wanted, not just the “Repository”. We heard that the notion of a “Repository” as something other than SQL Server was getting in the way of our conversations with customers.

I’ll let you compare to what Microsoft had said in the last 24 months, via Burley Kawazaki:

November 2007

We want to make Model-Driven-Development more successful than it has been. We want to make it mainstream by targeting CAD-like productivity improvements. We also want to help our customer lower the skill barriers: it is still too difficult to find skilled SOA developers, architects and quality analysts.

We want to send the model to the server not to the printer. MDD is suffering from two limitations. First, the model represents a point-in-time snap shot of the business logic, there are many gaps that people have to fill as they translate it into code. Second, people had only certain views into the model, there was no end-to-end view. Today, models are trapped in silos. As long as these silos exist modeling will remain at the periphery of application development. We need to create an end-to-end view supported by new tools, engines and repository. For instance, the concept of “code-behind” could decrease significantly with a shift to modern MDD techniques.

October 2008

Model-driven development is the missing ingredient that the industry has been looking for. Oslo will be the anchor for a new generation of app development that uses model-driven development, but takes it mainstream. Rather than having models being imported and exported and generating code, the model is the application and that breaks down the silos. We're creating a general purpose set of modeling tools, modeling language and repository that can bridge all the various types of models that describe an application and move models to the center of application development. Models then become the app. You send the model to the server, not the printer.

_____________

Anyone that knows me knows that I am a SOA, BPM and MDE geek. I created the “Service Oriented, Process Centric, Model Driven Programming Model” moniker 5 or 6 years ago. I have somehow pushed this vision since 1998 when I was working at NEC labs. Needless to say that it has not been easy: our industry loves reinventing the wheel and always circles back where it started. We have somehow discovered the perpetual movement at the speed of zero. I have no agenda other than I believe that we need to leave behind all these corny programming models genetically engineered to fail IT and create a new generation of programming models that are architecture independent.

The failure of Oslo to deliver to its promises is not just Microsoft’s failure, it is the failure of an entire industry unable to articulate a programming model that spans architecture stacks. In the last 10 years, all software vendors have failed to deliver “the missing ingredient that the industry has been looking for” and “[take] model-driven development… mainstream”. Yes, Burley, your vision was spot on, your execution is abysmal.

The failure of Oslo starts with the failure of standards and the little game that some individuals play all day at the expense of their company and the whole industry. These individuals made a career at producing incomprehensible and broken specifications, always on the lookout for killing somebody else’s spec, or for the opportunity to create a pompous and useless committee that will produce some insipid document and stick their little name in a press release.

The failure of Oslo is also the failure of precision thinking, the failure of not understanding the connection between SOA, BPM and MDE. Each software group come up with their petty concept du jour (usually between a couple of twits sent over their iPhone at their favorite coffee place), blow it up out of proportion with the help of analysts who monetize a lot more than they think, and then move on to the next. Our industry is littered with ghost frameworks, containers and tools quickly made irrelevant by the “next bubble” of pump and dump technologies. “Look ma, I can ship it, so it must be good enough for the customer”. How much “stuff” did the Microsoft, IBM, BEA, JBoss, Spring or Oracle middleware divisions cranked out in the last 10 years?

After a decade, the reality is that if you have been a customer of a large (or small) software vendor, you have most likely waited years to get something you needed yesterday and you had to build so much scaffolding in the meantime that when the “new” technology finally came, your only choice was not to use it because the cost of upgrading could never be justified.

So because they can’t think with enough precision, you have to hook stuff together (architect, they say): you no longer buy software, you buy “capabilities”, of course, that’s when the capabilities are available. Last spring I reminded the mighty Connected Systems Division that they still didn’t have a “WSDL-first” capability. Over the summer they seem to have engaged ThinkTecture to productize a proof-of-concept that was started and never finished back in 2007. Is that really professional for a company like Microsoft to approach such an essential capability that way? 10 years after the first draft of WSDL was written? Who is the product manager? Who in the mighty CSD can be that ignorant as to think that you can be successful at SOA without a WSDL-first approach? The reality is that it is symptomatic of our entire industry which lives in the lalaland of white papers, webinars and flashy presentations fueled by the monetization of its “analysts”. Yes, the software groups at all these companies spend a lot more time playing buzzword bingo and crafting stories than they spend thinking about the right thing to do, let alone doing it.

In 2009, a decade after the emergence of Model Driven Architecture (MDA), the industry, and Microsoft in particular, have been unable to build a precise Model Driven Engineering foundation. IBM might scream at this sentence, but that’s the sad reality. Scholars are still debating what to do, most people are using UML tools as an advanced version of PowerPoint and the OMG has no clue on where to go next trapped in vendor politics more concerned by their past investments than their future. Microsoft’s contribution has of course been abysmal in that space too: DSL Tools was a complete joke. Anyone that tried to use it, ended up in complete frustration and disbelief for any kind of Model Driven approach. And now, “Oslo” the modeling foundation that would “publish models to servers and not printers”, well “Oslo” has been folded back into SQL Server modeling tools.

The failure of Oslo is finally a failure of product management (I worked with a few product managers in my career, so I can speak from experience). I would argue that product management is quite simple. It relies on 3 pillars: innovation, customer research and competition analysis. Our industry more or less doesn’t do any of that. It does not matter how wealthy all these companies get, it does not matter how much you pay for your ELA, it does not matter how much profit they make, you pretty much get the same outcome. I have been to Microsoft’s SOA & BPM conference pretty much since its inception (the first edition gathered only a room full of people), I saw the evolution, or lack thereof, and the broken promises. Yet, no one at Microsoft asks the question why (even statistically) the mighty CSD would consistently fail at delivering what they set out to do, regardless of how critical it can be to their (high-paying) customers. I bet that if the mighty CSD was given the responsibility to deliver Notepad it would deliver it 2 years behind schedule and ship something that would look a lot more like calculator than notepad. It would then trumpet victory publishing blog posts and white papers explaining how with the latest CTP, combined with the future P&P SDK will enable you to convert ASCII codes keyed in the calculator into text. How can an industry, or a company for that matter, with so much money, with so much talent, fail so miserably at technologies so critical for the Enterprise?

The problem, you see, is that you can’t even ignore them altogether. As a customer, the Microsoft sales team will never leave you alone as you try to explain to them that “Store-and-Forward” is not what your company needs for SOA or that you needed Oslo to be what Burley told you it would be, not a SQL Modeler. They’ll never leave you alone as you explain to them that an ESB is not a pattern. Microsoft’s customers know all too well that the mighty CSD always delivers innovative, customer focused and competitive products. And when it doesn’t the P&P team adds some crutches, and when it doesn’t MCS adds a couple of Band-Aids. SOA, BPM, ESB, MDE? Yes, check, check, check, all has been delivered, just ask David Chappell.

So, with all that being said, allow me to rewrite Doug’s announcement, here is what it could have been, here is what the industry needed, here is what the mighty CSD did not deliver:

Of the key things we observed over the past couple of years was the real, tangible customer value in applying “Oslo” to working with Microsoft Middleware products. Time after time we heard that our customers needed far better tools to make interacting with our products easier. We understand the pain of our customers in their end to end experience with current SOA/BPM tools (or lack thereof) and frameworks that developers use today (which even us can’t even keep a count any longer). We heard that developers were tired of what we offered so far and wanted new efficient tools for SOA [read my lips, not just for SQL Server]. We heard our customers could not deliver the value expected from SOA and BPM without a true and comprehensive model-driven approach. This is why we delivered Oslo, a world class SOA and BPM platform, based on the latest Model Driven Engineering concepts.

I personally extend my thanks to the CSD for a decade of extraordinary achievements in SOA, BPM and MDE and their contributions to the abysmal state of our industry.

11/11/09 :: [MOP] Where oslo has gone? [permalink]

Doug Purdy is probably too young to remember the before the fall of the Berlin Wall and the after. Way back then, nobody wanted to sound like a USSR leader. In France, we even had our local Communist party (which was in direct contact with Moscow) which reminded us everyday how not to behave, what not to say. In the 70s or 80s, nobody would dare to use any Soviet rhetoric or participate in a Politburo. Fast-forward 20 years later, and our fearless leaders, well..., they don't fear that any longer. They even think we are all going to gobble up their propaganda. They make Hugo Chavez sound politically correct.

The Web has even given them the opportunity to control some media, just like in the good old days of the USSR. After all, propaganda, may only be a function of how much control one can have on its/his/her image. It does not matter if you control all media. Propaganda may also be a function of how many people work together to produce news, commentary and eventually knowledge. Maybe as humans we are totally unable to introspect ourselves and face our weaknesses without the help of others.

I would have smiled at Doug's post if it were not so characteristic of our society, at the dawn of the 21st century: when someone conquers power, from then on, all that he or she directs has to look clean, pristine, deterministic, intelligent, beautiful, loved... Our leaders probably spend more time crafting their stories than actually leading. Yes, you get the picture, that's exactly what was happening in the USSR, day in and day out, at all levels of society, but the lowest one. Actually, the whole leadership structure anneals into a giant Pavlovian propaganda machine capable of destroying entire countries and corporations. It seems these days that more and more of what we read, in many regions of the world, is just the same old Soviet propaganda.

I'll let you read Doug's post there is nothing worth commenting further. The writing was on the wall for months. Yet, it didn't have to be that way. Reading the comments from Doug's readers, you also get a sense of how much Doug's team listened to its potential customers or constituants... another characteristic of fearless 21st century leaders.

11/10/09 :: [MOP] Simplifying UML [permalink]

Jordi reports that the OMG has just released a draft proposal for simplifying UML. Like many others I don't have access to the document but here are a few comments.

UML has its roots in OO and it should decide once and for all if UML is OML or something else, such as PML (Power Point Modeling Language), GML (Garbage Modeling Language)...

It would make sense to simplify UML if it had a well defined purpose, but even OO no longer exist. I have argued for a long time that modern software architecture has long gone passed OO principles and POJO-Oriented Programming is just a convenient way to inject behavior within metadata. There is nothing Object Oriented about that.

OO is not well suited to model information either. DDD may artificially represent some aspect of an information model but it can't be used to create efficiently the representation of this information model in different contexts (message exchanges, UI bindings,...).

So, simplifying UML would first require that we understand why people use UML, it would take real courage from the fathers of UML to realize that their initial thoughts, though perfectly respectable and logical, has been overwhelmed by the advances of software engineering. It would take them courage to realize that OO is no longer the prominent programming paradigm, by far and unbeknownst to the vast majority of developers. It would take them courage to actually facilitate the development of architecture independent programming models, that are so critically needed in our industry. But no, I can guaranty you that none of that will happen (why a vendor would promote Architecture Independent Programming Models?). The OMG will make sure that the OO bubble remains as big as it can. I respect the OMG, I think their processes and the quality of their work is very high compared to many other standards but the right thing to do today is not to simplify UML, it is to overhaul UML.

You can be sure that won't happen: this is what Steve Cook , leader of the UML revision task force, explains as an introduction:

There was a lot of agreement that UML is too complicated and we need to find a way to simplify it for normal people

Of, course, based on the discussion I had with Doug Purdy and Keith Short last spring, the plan will be to absolutely kill the M3 layer, such that we can make sure that Architecture Independent Programming Models will never see the light. With Microsoft driving it, we can expect that Power Point and Visio will become the prevalent UML tools after that effort is complete.

Our industry is about to lose another 20 years of progress, sad.

11/6/09 :: [Other] The NO SQL Movement [permalink]

Our industry loves to kill its stars of the past. The latest post from Julian Browne provides a spectacular insight on how this relatively unique phenomenon occurs. Here it goes:

About four years ago I sat in a meeting that had finished early. We were chatting away and the subject turned, as it always does, to the lamentable state of IT....Wherever we had invested significant funds to improve and mature our infrastructure we were now spending significantly more and taking longer per-project even for minor changes...that day ... changed my mind about what a good architecture looks like. ... We'd uncovered a major cause of architectural rot and that there were things we could do to work around it, but not what the 'right' answer was. A bunch of people came to the same conclusions as we did, but did know what to do about it. And they went and built real things to address the problem. These people are the pioneers of the NoSQL Movement and they represent probably the most important change in architectural thought for ten years.... [last but not least] Actually many of the concepts aren't new.

You guessed it, this paragraph works for anything, SQL, SOA, Web Services, CORBA, EJBs, REST, whatever. This is how our industry supposedly moves forward.

Let's replay the pattern:

The way we do things sucks
We tried, X,Y and/or Z and it sucks even more
Somehow, somewhere, someone has a "ah ah" moment
He or she rounds up friends and family and creates a No X, or No Y or No Z movement
This nihilist movement is poised to become the most important breakthrough in the industry
But no worries... these concepts are not new, you are already familiar with them

For Julian, it is No SQL, for Stefan it is No WS, for some it is No EJBs, for me it is No CRUD & MVC,... we are all nihilists. No need to say that analysts and pundits LOVE this grand creation wheel. An infinite number of arguments can be derived from it, and of course, in the end we realize that nothing can really be annihilated. Some even call for a resurrection, with the expectation of creating a new circle of "innovation" and of course more importantly monetization.

Julian gives a great business example to illustrate what he is nihiling about. His business problem was that he needs to change its data model from one supplier per order to many per order. He complains:

The ORM in Rails is good, but not perfect. Although it simplifies our code and allows us to change that quickly it hasn't done anything about the data underneath. Even in the simple example above there's quite a bit of data restructuring and migration to do behind the scenes.

Yes, life sucks. We all wish we had push button technology or even a fancy natural language interface and somehow, automagically our systems of record would adapt to our ever changing mind.

Julian's solution? ... Documents.

Businesses are very used to dealing in documents. They like them because they can be passed around (workflow), annotated (audit trail) and are so flexible that they can cater for two instances of the same document type being treated entirely differently (prototype-based inheritance). If we could develop an alternative architecture that was document-based and not based on relational-tables we might very well have something.

Serendipitously, Julian explains:

We did develop a few good ideas, including what I now see was an inadvertent reinvention of REST

But of course, Julian. He actually even goes as far as explaining:

I'm a big fan of Domain Driven Design, which, if you remove all the practices and foofaraw, is all about creating highly expressive models, models that stretch from requirements to code without creating an impedance mismatch between the business and the developers.

In the end it's pretty clear that we live in a multi-dimensional space and optimizations in one dimension, even though interesting or even useful, have created this architectural vortex we are in. Yeap, "documents" are such an interesting idea, until you need to report on them or even create UIs that deal easily with variations. Nothing is impossible, yes new reporting engines could be created (Tilion was one of them back in 2000) and some dynamic UI framework can be designed, but what will be the next problem?

The only way to get out of this architectural vortex is to separate programming and operations models from architecture. MOP tackles the former while William El Kaim Cloud OS concept can tackle effectively the latter. The problem is not (or is less) architectural, the problem is about the way we harness software architecture. We don't seem to understand that an information system requires multiple execution environments, there is no way around it, but it does not mean that the programming and operations models have to be fragmented. As a matter of fact, turning off architectural elements to solve programming or operations problems is the worst way possible to make progress.

10/15/09 :: [SOA, REST] The BEST PROOF REST is a FRAUD EVER [permalink]

I have asked countless times the RESTafarians to show what they were doing with "REST". At last they show more than insipid URI syntaxes and we start seeing the silly things they do with REST. I could not believe my eyes and my ears. InfoQ published a QCon video from InnoQ's CTO Phillip Ghadir. I certainly encourage you to watch it. I suspected for a long time that Stefan was just a CORBA/JEE guy that didn't really got much understanding of SOA. What this presentation shows is is what the RESTafarians did in day in and day out when they were "doing SOA" and then complained it did not work. This is what they have been doing for 15 years with distributed objects (and think that REST is going to change any bit of it):

Phillip (and Stefan) show this picture and all they can find wrong with SOA is that they can't use OO, they can't model their solution with a collection of classes and generate a service interface (duh?). And what they complain about? the WSDL file is "too large" and guess what... OO types coming from the generated WSDL are not as interoperable as they expected (duh?). Have you heard of something as WSDL-first? do you even understand a thing about model-driven engineering? (hint java2wsdl is not MDE, i.e. MDE is not TDE otherwise we would have called it Transformation-Driven-Engineering)

What's the solution? Atom feeds. Yes, no more code generation, just put everything in a feed and voila. Phillip goes on to explain how he built the solution. You'll appreciate how empty REST is. I can safely predict that nobody will ever be able to build a full scale enterprise information system (such as ERP) in a 100% RESTful way.

When I think of how much BS Stefan et al have laid over our industry based on such a flawed view of SOA, I just want to throw up. I can't help to think about all these SOA projects destabilized by so much boloney. The CORBA guys, included Bill Burke or Steve Vinoski never understood Service Orientation, not a thing. Their mind is anchored for ever in OO and DO (Look ma, there is no naming service so it has to be RPC...). There is nothing about extensibility, versioning, bi-directional interfaces, asynchrony, orchestration and assemblies they can understand. Not that the SOA-RM, RA or SoaML crew understands anything either. What a loss.

This loss is that much dramatic that REST has invaded the Cloud. RESTful APIs will hamper the legitimate growth of the Cloud. How can our genius RESTafarian friends ever believe that such a stateful, asynchronous, event driven world could be a good fit for REST?

Phillip has the integrity to make a difference between RESTful integration as opposed to RESTful application (knowing well that RESTful applications are just a pipe dream). But, what have you gained? nothing, absolutely nothing. You have diverted scores of people in a rat hole making them believe that CRUD waz the new Cheese, contributing further to make IT as inefficient as it can possibly be. Even the Cloud - such a great idea - you successfully CRUDed it up.

Well done guys ! You can be proud of your scam.

The (other) REST is a fraud.

10/05/09 :: [Cloud] MomentumSI [permalink]

I am very happy to share that I have joined MomentumSI as a Director of Advisory Services, focusing on Cloud Computing. I have known Jeff since the early days of blogging and BPEL. Gosh, a magic 7 years ago. He offered me this position in June and I gladly accepted it. Jeff has assembled over the years a world class team of SOA and Cloud Computing experts and I am honored he thought I could be part of it too. The core of my work is focused on researching and defining Cloud migration strategies for the Enterprise. Of course I also contribute to different SOA/BPM projects, not to mention SOA training and mentoring.

You can keep track of some of my work here, and check this white paper: CFO Requirements for Cloud Computing.

09/27/09 :: [SOA] Boris on Service, Web and REST [permalink]

It is no secret, I really like the kinds of things Boris is writing about SOA. His book is a master piece. It is complete, accessible, based on a deep experience and contains zero fluff. And of course someone of his caliber could only have a measured position in the REST vs WS-* debate:

Both REST and WS have their place in real life implementations. The issue should be not which one is better, but rather how they can coexist and when is one more appropriate. The other important thing is to make sure that comparisons are based on merits, not beliefs, no matter how strong they are. There are many useful standards and patterns created by WS* and the issue is whether it makes sense to start over or to see how these patterns can be applied to REST.

Dilip Krishnan, another InfoQ editor, and RESTafarian at large, not surprisingly responded:

Can we finally agree that the word "service" is as, if not more important, then "Web"

What does this even mean? important for what and for who?

I say not surprisingly because RESTafarians have no clear position on "service", they just say REST is the right way to build a Service Oriented Architecture. Yet, REST has no concept of "service" anywhere, just resources and their shiny uniform interface, links and bookmarks. Indeed there are no services in REST. Just read the thesis.

But RESTafarians can't care less, if they don't understand or can't explain something, the solution must be in REST somewhere and they look for it, one hack at a time. It is interesting to see how the mind works, it makes you wonder how come mankind has made any amount of progress, ever since we set foot on this planet, and what progress could we have made if we didn't get stuck in the mode of "the solution must be in this book/thesis/theory somehow, I just have to find it". Well the reality is that the solution is often, if not always, outside the box. Just ask Newton, Einstein and the many less known scientists. In computer "science" we have a very small, actually, we don't even have a box, we just have a square: one axis is Turing-complete and the other one is OO, and everything a developer can be given to do his or her job has to fit on that square. You would surely fall off a cliff if you dared go outside.

But I digress, let's go back to "services". Even Bill, in this REST-* proposal is talking about creating a RESTful interface to non RESTful services. That certainly begs the question, how can a service be non RESTful since REST is all about SOA and replaces in its entirety WS-*.

Ganesh, in all his wisdom, has become a RESTafarian. It is interesting so see someone that understands SOA becoming a RESTafarians, at least you can have a much deeper discussion. He came up with the concept of REST as being Polymorphic CRUD:

IT folk in the enterprise understand both polymorphism and CRUD, so the combined term should make sense. I want to drive home the point that a verb itself is neither coarse- nor fine-grained, it's how each resource interprets it. Fine-grained resources will interpret the REST verbs as CRUD operations. But more coarse-grained resources can interpret the verbs as any arbitrary business operation.

I find also find interesting his use of the word polymorphism, because for me REST is just a better CORBA, i.e. object oriented but it is not service oriented. There is no better post that explains how small the square we are left to play with that Pete Lacey's post in 2006.

They want transactions, and reliability, [bidirectional interfaces, assemblies] and asynchronous messaging, and orchestration, and everything else.

So, Boris committed heresy (defined as proposing some unorthodox change to an established system of belief, especially a religion, that conflicts with the previously established opinion of scholars of that belief such as canon). He dared say that we should focus on Service not just the Web. Unfortunately, Dilip, Ganesh, Bill and so many others, I would like to repeat that there is no evidence today of any application being built in a RESTful way. There are APIs to CRUD data here and there, but the day you'll show me an ERP system built in a RESTful way, we'll talk again.

For me a Service is a software agent which :

performs a well defined unit of work, invoked by expressing intent, with minimal or no knowledge of the context in which this intent is expressed
is readily accessible by an arbitrary number of other software agents implemented in arbitrary technologies
can change the way it performs its unit of work or specify its intent without necessarily breaking the software agents that consume
the resources involved in the performance of the unit of work, i.e. a service, may participate in more than one service

This is what happens in life every day. We consume countless services by simply expressing intent (e.g. call someone), these services can scale without impacting me (a wireless carrier can add a subscriber without me noticing), and these services can change again without impacting me either (a wireless carrier can add a "favorite list of callers" without me noticing). An airplane can be involved in performing several services simultaneously (transporting people, parcels and letters).

Service orientation is about creating solutions from this type of software agents instead of tier-ing and integrating to achieve the same benefits that we realize in a service oriented society. Service orientation is way out of the square. It's not that hard, but it definitely requires some unorthodox change to an established system of belief. The irony is that the RESTafarians, including Roy, are representatives of this square based system of belief. They want no progress to be made what so ever. On the surface, REST could be easily mistaken for a Service Oriented technology. After all it supports 2) well, and has some aspect of 4) taken care of (It doesn't break anything because there is nothing to break). But that's the problem, there is nothing to break, there is no intent in REST, there is a million RPC-like conventions, mostly at the CRUD level. When Ganesh says that you just have to POST something to /applications, and that replaces submitApplication, where is the intent expressed? is POST an intent? can this application participate in different "services"? No, it is not an intent, because you have to file it yourself in the appropriate hierarchy /applications. This is the tight coupling SOA has worked so hard at trying to remove. Service orientation is about expressing an intent and have no particular reason to know what happens next.

The CORBA guys see all this as the promised land, they just pushed the problem of brittle interfaces to developers. Interfaces are the problem, just tell people they don't exist anymore, they have been CRUDed away. All you do in REST is "encode" all your application semantics. They can expand without breaking, but they can't change. REST is CRUD and CRUD is a tight a coupling as you can possibly imagine.

So yes, Dilip, Service is almost as important as the "Web".

09/12/09 :: [MDE] Metamodel Oriented Programming (RE)Explained[permalink]

I have tried to explain Metamodel Oriented Programming to a few people over the last few months and I felt that I was just getting some polite interest at best. So I'd like to try to explain it a bit more.

I have created this diagram to classify executable artifacts (interpreted or compiled):

The Anemic - Cogent axis could have just been called Declarative - Imperative. It refers to whether an artifact contains "implementation" elements. An example of implementation element is a method in an Object Oriented Class.

The Monadic - Polyadic axis simply reflects the number of concepts that make up the structure of the artifact. OO languages typically have one (major) concept: a class, so they are monadic. DSLs like HTML or SCA have several. For instance SCA has: Service, Component, Composite, Domain, Assembly, Wire, Event,...

HTML is interesting because it is probably the most successful DSL on earth. Lots of people are surprised when I call HTML a DSL. I am not sure I am wrong in doing so. Yet, HTML without Java Script (i.e. an anemic HTML) would be quite a bit less useful. I am not sure the Web would be what it is today without the cogency that JavaScript brings to HTML.

SCA is also interesting because it shows how you can augment all sorts of general purpose language with a DSL: SCA + Java + BPEL starts looking a lot like a Polyadic Cogent programming model. SCA alone though is completely anemic.

This figure calls for a missing category of languages: Polyadic Cogent programming languages. So that bears two questions:

1) what do they look like?
2) what are they good for?

What does a Polyadic Cogent Programming Language Look like?

First, it is polyadic, so pick your favorite (anemic) DSL, here is one with 3 concepts (the more the merier):

Now add some implementation elements to your DSL, just like in OO, a class has a method:

You can of course choose the multiplicity of the implementation element (0,1 or more). A (SOA) Service is interesting because it can have 0 or 1 implementation, depending of whether the Service Implementation is based on a BPEL orchestration or if each operation is implemented individually. Yet, the implementation elements (BPEL or otherwise) are all completely separate from the Service Definition (WSDL). If it is a good thing to have a separate contract definition, it also hides completely the programming model behind SOA, and that's bad. It has lead to all kinds of interpretations and frankly poor implementations, frustrations and clueless analysts talking about the death of SOA.

So at the metamodel level (M2), you just add an Implementation element, but what do write it at the metadata level (M1)?

First you need some processing instructions and basic types. There are two type here: your favorite Turing complete set and an orchestrated set. We should probably combine them both and add events to the mix and have just one standard processing set which could be personalized with your favorite syntax.

The second type of instructions is related to the lifecycle of the elements in DSL: A, B, C. When you say:

A a = new A();

you are simply starting the lifecycle of an instance. Similarly, a Class in an OO runtime has a simple lifecycle: Loaded, Unloaded. A service, in a service container has a couple more states: Loaded -> Started -> Stopped -> Unloaded. Please note that some of the states and transitions may be implicit (e.g. delete() or gc() ).

So just define the lifecycle of each of the elements of the DSL, assign a catchy name for each transition between states and voila, you have your Polyadic - Cogent programming language.

I don't know why the DSL people hate code (i.e. implementation elements), I don't know why the GPL people keep adding annotations or stitching code behind your DSL. These approaches simply don't make any sense.

Nothing is simpler and cleaner. You have complete control over what the language can do, you can even add constraints about which transition a particular implementation element is allowed to call. I can create very robust Polyadic Cogent languages in a couple of days using tools like xtext from openArchitectureWare.

What are these languages good for?

Well if you see the number of annotations floating around these days, Polyadic Cogent Languages should be able to clean up this in no time. At the end of the day an annotation is a just a DSL element and people want to use the syntax of their favorite language to add some implementation element to that particular DSL element. The problem with this approach is that we put a class wrapper around this DSL concept and we let developers loose do whatever they want with the class. This approach is wrong: we are introducing vast amounts of inefficiencies with that, for absolutely no gain at all. SCA's annotations in Java are a perfect example of this problem. Don't get me wrong I really like SCA, but wrapping services (with bi-directional interfaces), wires, composites and what not behind Java Classes is introducing levels of complexities that can easily explain why SCA is not used more. The more polyadic your DSL will be the messier it will be to use annotations.

The same thing is true of code behind (not to mention annotated code behind). Code behind is a bit more aligned with MOP as it is based on events (occurrence of a state), but there are no clear separation between the code associated to each metadata element (like a class - method relationship). The code is generally behind a metadata set and generally exhibits poor reusability and factoring.

Annotations and Code Behind approaches are introducing two dire side effects:

1) there is no clean separation between the metamodel level and the underlying container of the business logic (expressed solely from Metadata and Implementation elements)

2) they prevent the metamodel to span multiple tiers of the architecture

I cannot emphasize enough how bad this coupling between metamodel / container is. Architecture has been widely successful over the last 15-20 years. We have been able to create sophisticated distributed systems that bring tremendous value to their users. No question about that. The problem though has been stitching all these tiers together with lots of boiler plate code, often hand coded, always hard to change.

Today there is a great need to create architecture independent programming models:

This is exactly what a Polyadic-Cogent Programming Language can do, spanning n-tiers, from data to presentation.

Too many companies are stuck today with what they built over the last 10 years. The containers are going out of support and yet they can't change them because they wrote all the business logic within the containers, using their APIs.

In a Cloud world, it is even more critical to be able to create architecture independent programming models.

08/22/09 :: [SOA] SOA is Failing [permalink]

Apologies for not blogging, I am (really) swamped working on a SOA project...

As I was letting my main computer install some of the latest Vista security updates, while I looked for the the first time in 2 months at my google reader, and as you could guess, (Microsoft's) Dave Chappell's latest post caught my eye. Not sure why I missed his interview in 2008 but he basically explained then and now that "SOA is failing".

Dave and I have a long history. I related several times this incident in my previous posts but for the readers who don't know about it, I was sitting next to Dave at an Indigo (i.e. WCF) SDR (Software Design Review) back in 2004 or thereabout. At some point we engaged the conversation and I explained to Dave some of my views on how "orchestration" related to Service Orientation (i.e. as a Service Implementation technology and not (really) as a Service Orchestration technology). The difference is subtle and I explained many times my views on that question. At that point, Dave explained to me that I was wasting my career trying to say things that differed with what Microsoft was saying. He also spent a fair bit of time in the 2006-2007 timeframe explaining the Microsoft world why they should not look at SCA, in particular by rejecting the idea that an interoperable assembly mechanism had any value (thank you Dave, what an accomplishment !).

He did use these words "wasting your career". I guess he did not waste his.

Watching Dave's presentation is worth its dose of humor: "Object works as a design paradigm", "Reuse of business services does not work..., but... technical reuse, i.e .Net/JEE works", "ESB is just a bunch of vendors trying to sell you their good old integration gears", "Data access reuse works" ... and Dave goes on and on and on.

The astute reader would have probably made the connection that, indeed, the Connected System Division at Microsoft was failing so much that it had to put under the SQL Server division. What a demotion! I bet there are some partner architects that must feel a bit bitter about that. Ah...unless it is because "Data Access reuse works"? What do you think Dave?

How could a company that is unable to deliver a WSDL-first capability in its SOA tool set would understand anything about Service Orientation? I feel sad that Microsoft customers have to go through this kind of flawed arguments simply because Microsoft can't deliver something that can make them successful with Service Orientation::

Object works as a design paradigm: but of course Dave, this is why all enterprise application software is made up of Customer, Account, Product ... classes. We all know that. This is also why you add a couple of annotation to a "class" and voila, WCF spits out a service, and what a "service" that is.

ESB is just about integration: but of course Dave, and do you have the slightest idea about what loose coupling is and how WCF lets you achieve loose coupling? WCF is so loosely coupled that it can't even do WSDL-first or requires shared "stuff" between the consumers and the providers. Well done guys.

Reuse of business services does not work: but Dave, how can you implement a Business Service with WCF? have you even tried? can you show any example? Have you looked what they are doing with SCA? They even have events nowadays.

Data Access reuse works: but of course Dave, CRUD is a well know pattern that provides an infinite amount of reuse, actually you can reuse CRUD operations so much that every single consumer is going to implement the same logic, CRUDing around, and then when the data changes... ah badaboom, all client breaks.

What an accomplished career Dave !! I am jealous.

I'll never repeat it enough, SOA is unfamiliar, it does require that you scratch your head a bit, oh, not that much. What does not work is trying to do what you have been doing for 20 or 30 years with SOA technologies. It is not the SOA technologies that do not work, it is what you have been doing. Object Orientation does not work (with information) but loose coupling works, provided that you understand what it means. The reuse of business service works, provided that you understand how to build, version, govern and fund business services. Ah, and data access? no it does not work, exposing data access services to consumers is like pouring concrete over your enterprise applications, it looks smooth and slick until the day you need to change a few things.

Lots of things are changing if you want to build a service oriented architecture:

Governance not just Project management
Strategy and Goals not just Requirements
Selection not just Specification
Contract and Quality of Service not just Functionality
Policies not just Rules
Resources not just Data
Lifecycles not just implementations
Events not just messages
Inter-actions not just invocations
Assembly not just composition
Federative not just Monolithic
Forward versioning not just versioning
Certification not just Test
Publication not just Documentation
Provision not just Deploy
Threat not just Security
Accountability not just Organization
...

The key to reuse, Dave, because you seem to have no idea whatsoever about reuse, loose coupling and SOA: the key to reuse is forward versioning. What you have to understand Dave (sorry that's something that Microsoft is not saying) is that in SOA, what you reuse, is not an asset that was built last year, no, the old consumers of a service reuse a new version that was just built for a new consumer. Reuse is "forward" not "backward". As a consumer (and service provider) I prepare myself to allow the service to evolve without disruption. What a lack of imagination ! this is what happens in real life every day, as a consumer of physical services I rarely get impacted by changes in the services I consume (education, health, banking, insurance, groceries...). Life would be nightmare if we had to be notified of everything that is changing let alone do something about it. Reuse happens when versioning becomes seamless.