Tuesday, January 31, 2006

The Sheep that Shit Coleslaw

'The Sheep that Shit Grass' was a popular meme in the P2P days. If I remember correctly, it was introduced by Cory Doctorow as an economic model whereby the consumption of a material (grass) and a function (digestion) led to a byproduct that was itself consumable (more grass). This model may be contrasted with the consumption-only model, whereby the output (User Interface) is only consumable by a human, not a machine.

In peer-oriented systems, a node is a considered a 'peer' when it is both a consumer AND a producer. In a network, it is advantageous to have nodes not only consume value from the network, but also produce value back to the network. The more producers on a network, the more valuable the network is for consumers.

Non-Recombinant Systems
Traditional applications were often designed whereby the ultimate consumer was hard-coded at design time, and that consumer would be a human - and the vehicle would be some kind of graphical rendering. This is most likely a tradition held over from mainframe and client/server days. Today, many systems continue to fall victim to the same design center. Architects continue to assume that the data or functions would never be needed by anyone but a human and that whatever tool they built would be the final tool for consumption. In essence, the designers failed to anticipate future consumption scenarios that may have been out of scope of the 'Use Cases' that they built their system for.

Recombinant Systems
When an application is designed so that its functions or data can be discovered and used, we say that the application is 'highly recombinant'. This means that the services that are offered can:
1. Easily be found (often on the screen that used them) and
2. Easily be called (the barrier to usage is low).

Applications that are highly recombinant offer the potential for reuse, or sharing. These applications do not assume to know the future uses of the functions or data. The fundamental notion is that the true uses of the functions/data will not be known until after the system is put into production.

Exposing Functions and Data
As we move into a service oriented world, we have the potential of serving up two interfaces: one for human consumption (the screen) and one for machine consumption (the service).

The key is to make sure that the people who use the systems can easily gain access to the services. As an example, it is common for Blogs to identify their feeds via the classic RSS image: . Just as easily, we can tag our more structured SOAP services with the WSDL image: . Publishing and advertising consumption scenarios must become second nature for organizations that wish to leverage the advantage of recombinant applications.

Architect - "You will eat carrots!"
User - "But I want coleslaw..."
Architect - "You will eat cabbage!"
User - "But I want coleslaw..."

Enterprises and SaaS vendors must not only acknowledge that we are moving into an era of recombinant platforms but they must also take the necessary steps to enable the mashups, remixes, composite applications or whatever you want to call them. The future of software is about the creation and utilization of building blocks. It is about letting our users play with their Lego's. It is about allowing them to make coleslaw from their carrots and cabbage. It is about productivity and creativity. We do it for a few reasons: it lowers new software development costs, significantly reduces maintenance expenses, while simultaneously gives the users what they wanted.

You can have your carrots and coleslaw too.

Saturday, January 28, 2006

SOA Pilot Program



As you work to extend IT capabilities utilizing SOA, a key for many organizations is a pilot program which enables the greater understanding and methodological deployment of Web services and SOA around a structured initiative. Join us as executives from MomentumSI and Actional will present best practices for selecting and implementing a successful SOA Pilot:

- Determining the Overall Goals of an SOA Initiative
- Criteria for a SOA Pilot
- Case Study of Successful Pilot Program
- Nexts Steps to an Enterprise SOA

This Presentation clearly identifies the axioms and best practices that underlie achieving SOA objectives...

WHO SHOULD ATTEND: IT Executives, Enterprise Architects, Business Line Manager and Project Managers who are using or planning to use Web services or creating an SOA! Webcast will start promptly on February 2nd at 2:00pm EST/11am PST.


Wednesday, January 25, 2006

Sunday, January 22, 2006

SOA Contest - Early Results

We have some early results on The Great Microsoft WSDL's Hunt. I've looked around myself and they're not as easy to find as you might think. I'm still encouraging any and everyone (including Microsoft employees) to send me the WSDL's!!

I also published the names of a few Microsoft products that likely have WSDL's.

Come on Microsoft - we're on year 5. Surely you've got more than 4 WSDL's???

Thursday, January 19, 2006

SOA Consolidation

The acquisition of Actional by Progress is yet another sign that the SOA space continues to mature. Consolidation is a necessary fact of all market places.

We've noticed that the 'acquisition trail' is becoming more and more complicated, so we've put together a cheat-sheet to help you out:

SOA Consolidation

And congratulations to the teams at Actional and Systinet!

Sunday, January 15, 2006

Microsoft SOA Contest

The Great Microsoft WSDL Hunt


MomentumSI is sponsoring a contest to see if anyone can locate the Microsoft WSDL's! Yes - anyone can win an SOA Tee Shirt, even Ray Ozzie!

All you have to do is:
  1. Find a supported WSDL from ANY current Microsoft product (hosted or shrink-wrap)
  2. Send me (jschneider at momentumsi.com) the name of the product and the WSDL as well as where you found it (URL, etc.)

  1. The product has to be from Microsoft, the most current version and supported
  2. You can send as many WSDL's as you want (but you'll only win once)
  3. Only the first person to send me the WSDL wins
  4. I only have about 100 tee shirts left - when I'm out of tee shirts the contest ends.
  5. Don't send anything confidential.

When "The Great Microsoft WSDL Hunt" is over, I'll publish the results.


IMHO - here are some of the major differences between SOA-WS and SOA-CORBA. Perhaps Steve V./Eric N./etc. would be kind enough to give their list.

  1. ALL major infrastructure vendors are supporting the Web services stack - do you remember when Microsoft threw CORBA under the bus?
  2. ALL major application vendors are moving their ERP/CRM/etc. products to a service-based platform; how many application vendors redesigned their products for CORBA?
  3. THE major desktop productivity suite, Microsoft Office, will be capable of locating, publishing and consuming web services; I don't remember office productivity doing much with CORBA...
  4. SOA-WS has put significant emphasis on long-running and asynchronous programming models, enabling B2B activity. Did CORBA do much in B2B?
  5. SOA-WS has put much more emphasis on network routing - enabling 'virtual services' and in-the-network transformations, mitigating the 'versioning problem'. These are lessons learned from the CORBA days...

I'll leave the discussion on IDL/IIOP/Common Facilities/etc. to the experts...

Legacy Architects and SOA

"Jeff - I've seen 5 paradigm changes - this one looks just like what we were doing 10 years ago with CORBA. I'm not sure why you expect anything different..."

I often find myself attending meetings with 'legacy architects'. You know the kind - the guys that love to remind you that 'nothing is new' - hence, we shouldn't expect any new results.

1. 'Legacy Architects' or 'Last Gen Architects', if you prefer, remain quite ignorant about SOA-WS.
2. In a paradigm shift, 'Pessimistic Architects' have a much higher likelihood of failure than 'Optimistic Architects'.

I don't mind ignorant architects - however I have a true disdain for perpetually ignorant architects - the kind who refuse to learn what they don't know. These people can kill an SOA program. Find them - remove them if you can, contain them if you can't.

Pessimistic architects are good; perpetually pessimistic architects are bad. If the people leading your SOA program don't believe in SOA - you are likely doomed. Understanding the limitations of a computing model doesn't take a great architect - quite frankly, any half-assed architect can find holes in any model. Great architects are the ones that mitigate holes and while getting the entire organization completely pumped up about making the transition. Great architects push the acceptance over the chasm - past critical mass. They will have plenty of arrows in their back - mostly shot from the bows of 'perpetually ignorant architects'.

Saturday, January 07, 2006

Web Service Architecture Tenets

When it comes to SOA, what do you believe in?
What are the goals? What are the rules?

These are tough questions that many people in the industry have attempted to answer. Some time back, Frank Martinez and I wrote our view:

Web Service Architecture Tenets

I'd love to hear your feedback.

Monday, January 02, 2006

My Favorite Prediction

I've read quite a few predictions for 2006 - and my favorite - by far - was penned by David Heinemeier Hansson. His prediction on enterprise software follows:

4. 'Enterprise' follows 'legacy' to the standard dictionary of insults favored by software creators and users. Enterprise software vendors' costs will continue to rise while the quality of their software continues to drop. There will be a revolt by the people who use the software (they want simple, slim, easy-to-use tools) against the people who buy the software (they want a fat feature list that's dressed to impress). This will cause Enterprise vendors to begin hemorrhaging customers to simpler, lower-cost solutions that do 80% of what their customers really need (the remaining 20% won't justify the 10x -100x cost of the higher priced enterprise software solutions). By the end of 2006 it will be written that Enterprise means bulky, expensive, dated, and golf.

What David identifies is the growing distinction between classes of applications in the enterprise. Many, if not most, applications in the enterprise DON'T NEED TO BE ENTERPRISE GRADE. The function that they perform - isn't that important, doesn't require .99999 up-time, DOD-grade security, etc.

But let's get serious - Dell isn't going to be running its order management system from some Web 2.0 SaaS startup - nor will e-Trade be hosting customer financial data in some "non-enterprise" way. People who don't do enterprise development don't understand enterprise development; there are a million blogs out there to prove this. An enterprise can lose more money in one day because of a system outage than the combined revenue of every SaaS / Web 2.0 company combined.

Before 'enterprise Java', the term 'enterprise' referred to the scope of the deployment - not the architecture. 'Mission Critical' was the term we used to indicate a high degree of architectural integrity. David (and many others) are continuing to restate the obvious: we need multiple levels of architecture: light, medium, heavy. We need architectural profiles for each level. Our enterprise architecture teams MUST NOT force one design center for all application classes.

Is there a place for RoR, Spring, RSS, etc. in the enterprise? You bet. Will light weight solutions eat away at their heavy-weight counterparts? Yep. Is the 'enterprise' grade solution going to mean "bulky, expensive and dated" in 2006? Well, yea - it has meant that for years!

Sunday, January 01, 2006

My 2006 Predictions

Here are my 2006 predictions:

1. Virtually no enterprise software companies will 'go public' in 2006.

2. U.S. based venture capital will continue a downward trend with enterprise software leading the pack.

3. An abnormally high number of small ISV's will fail to raise their next round of funding. However, their revenue will allow them to crawl forward forcing them to ask the 'startup euthanasia' question.

4. On average, large enterprise software companies market valuation will stagnate; small and medium sized companies will mostly go down except for brief periods of 'acquisition hype'.

5. The number of 'Software as a Service' providers increase substantially but find low revenue in 2006.

6. The competition between Big-5 and Big-I (Indian) consulting increases significantly setting up a 2007 consolidation scenario.

7. The Business Process Platform becomes the accepted standard as the foundation for enterprise software.

8. SOA continues as a major trend however more attention is focused on 'what to service orient' rather than 'how to service orient'.

9. Google continues to release new products in very short time frames. Microsoft takes notice but does not act.

10. Salesforce.com stock price drops by 50%.