*-First Development

Just yesterday I was having a conversation with a developer about ‘contract first’ development. The individual was heading down the path of creating a contract prior to writing the code, as he had been instructed. But as a .Net developer, he interpreted this request as creating a ‘.Net contract’, not a ‘WSDL contract’. Naturally, I let this person know that I was interested in a ‘WSDL First Contract’, not a ‘Microsoft First Contract’. And as you might expect, the developer told me how there was no need to go ‘WSDL First’ because if he went ‘Microsoft First’, he could then generate a WSDL. As if I hadn’t heard that one before…

And once again, I had the same-ole discussion about how in SOA we would be creating interfaces completely separate from implementation – often with different groups of people – in different parts of the world – leveraging different reusable message components that would be related back to services front-ending multiple implementation platforms. He got it. ‘Microsoft First’ won’t work in an enterprise setting.

This discussion prompted me to ask some of our consultants if they were having good results with ‘WSDL First’ and the responses were positive. However, one consultant communicated that he has been pushing this concept into the requirements gathering phase. He called it, ‘Spreadsheet First’. Most I.T. Business Analysts will not be comfortable with creating WSDL’s and we continue to have an ‘analysis impedance mismatch’ between ‘legacy, silo-oriented Use Cases’ and ‘client cases / service cases’. His solution was to use a simple spreadsheet to layout the operations, messages and constraints. He would then use the spreadsheet as input in design phase, where he’d bundle the operations into port types and services and translate the field types.

One of the things I really like about SOA is having the service as unit of work. A service is right-sized for requirements gathering and specification. It is also right-sized for ‘Test Driven SOA’, but we’ll save that for another day…

Is Ruby Ready for the Enterprise?

The team at MomentumSI asks the question, "Is Ruby Ready for the Enterprise?"

http://www.momentumsi.com/about/accessarchive.html

You're so Enterprise...

The discussion of 'enterprise grade' and 'web grade' has been on the mind of the blogging community. David Heinemeier Hansson, with the recent Ruby on Rails success on his resume, recently branded an EA, "Boy, is James McGovern enterprise or what!" - let's be clear, this was meant as an insult.

He goes on to say, "Thus, allow me to make this perfectly clear: I would be as happy as a clam never to write a single line of software that guys like James McGovern found worthy of The Enterprise."

Recently, I asked some EA's to comment on this line of thinking. Putting the immature insults aside, were there valid points to be taken away?

Here is what I heard:
1. First, we can't just lump RSS, REST, RoR into the same bucket - each technology must be evaluated independently.

2. RSS can be viewed as an overlay network and has already proven to scale to the needs of the largest enterprises in the world. However, groups like MS have identified shortcomings and made feature extensions. This pattern will likely continue.

3. REST, as the principle foundation of the Web, has proven that it too can scale - but the areas where it has proven to scale the best are related to the movement of unstructured HTML documents using a constrained set of verbs. Others will note the success of RESTian API's in leading Web companies like Amazon. Most EA's were quick to acknowledge that the WS-stack is fat and that the lack of ubiquitous deployment was creating a larger than usual demand for simple RESTian style development. The delay of Microsoft Vista didn't help. EA's remain concerned that the lack of published resolutions to the non-functional concerns (security, reliability, transactional integrity) for RESTian projects will lead to either one-off implementations across the global enterprise leading to a deferred mediation problem, or alternatively might lead to a set of RESTian specifications that closely resembled the WS-specs, as they both attempted to satisfy the same use cases. The conclusions was that RESTian principles will make significant waves in the enterprise because of the solid foundation and ability to add more 'enterprise crap' on it if they need to.

4. Ruby on Rails - Generally speaking most of the EA's I've spoken with understood the power to quickly create web apps with RoR. One was quick to note, "if time to market was my primary concern, we'd use Cold Fusion, rarely is that the case." It was clear that many EA's were uneasy talking about RoR; they lacked data and were turned off by the comments that David Heinemeier Hansson had made, suggesting that Ruby was definitely interesting but were unsure if the RoR team was aware of the political nature of the enterprise - and the need to satisfy unique requirements. Most EA's were interested in finding a place to do 'departmental RoR' and kicking the tires. They were also interested in the long term potential of Ruby, RoR aside.

---- Part II
In regard to the comment that Dare had made, "If you are building distributed applications for your business, you really need to ask yourself what is so complex about the problems that you have to solve that makes it require more complex solutions than those that are working on a global scale on the World Wide Web today." I tried to have a conversation with several architects on this subject and we immediately ran into a problem. We were trying to compare and contrast a typical enterprise application with one like Microsoft Live. Not knowing the MS Live architecture we attempted to 'best guess' what it might look like:

• An advanced presentation layer, probably with an advance portal mechanism
  
• Some kind of mechanism to facilitate internationalization
  
• A highly scalable 'logic layer'
  
• A responsive data store (cached, but probably not transactional)
  
• A traditional row of web servers / maybe Akamai thing thrown in
  
• Some sort of user authentication / access control mechanism
  
• A load balancing mechanism
  
• Some kind of federated token mechanism to other MS properties
  
• An outward facing API
  
• Some information was syndicated via RSS
  
• The bulk of the code was done is some OO language like Java or C#
  
• Modularity and encapsulation was encouraged; loose coupling when appropriate
  
• Some kind of systems management and monitoring
  
• Assuming that we are capturing any sensitive information, an on the wire encryption mechanism
  
• We guessed that many of the technologies that the team used were dictated to them: Let's just say they didn't use Java and BEA AquaLogic.
  
• We also guessed that some of the typical stuff didn't make their requirements list (regulatory & compliance issues, interfacing with CICS, TPF, etc., interfacing with batch systems, interfacing with CORBA or DCE, hot swapping business rules, guaranteed SLA's, ability to monitor state of a business process, etc.)
  

At the end of the day - we were scratching our heads. We DON'T know the MS Live architecture - but we've got a pretty good guess on what it looks like - and ya know what? According to our mocked up version, it looked like all of our 'Enterprise Crap'.

So, in response to Dare's question of what is so much more complex about 'enterprise' over 'web', our response was "not much, the usual compliance and legacy stuff". However, we now pose a new question to Dare:
What is so much more simple about your architecture than ours?

My Enterprise Makes Your Silly Product Look Like A Grain of Sand

Dare Obasanjo, a Microsoft engineer recently posted the following comment:

The funny thing about a lot of the people who claim to be 'Enterprise Architects' is that I've come to realize that they tend to seek complex solutions to relatively simple problems. How else do you explain the fact that web sites that serve millions of people a day and do billions of dollars in business a year like Amazon and Yahoo are using scripting languages like PHP and approaches based on REST to solve the problem of building distributed applications while you see these 'enterprise architect' telling us that you need complex WS-* technologies and expensive toolkits to build distributed applications for your business which has less issues to deal with than the Amazons and Yahoos of this world?

Dare goes on to say:

I was chatting with Dion Hinchcliffe at the Microsoft SPARK workshop this weekend and I asked him who the audience was for his blog on Web 2.0. He mentioned that he gets thousands of readers who are enterprise developers working for government agencies and businesses who see all the success that Web companies are having with simple technologies like RSS and RESTful web services while they have difficulty implementing SOAs in their enterprises for a smaller audience than these web sites. The lesson here is that all this complexity being pushed by so-called enterprise architects, software vendors and big 5 consulting companies is bullshit. If you are building distributed applications for your business, you really need to ask yourself what is so complex about the problems that you have to solve that makes it require more complex solutions than those that are working on a global scale on the World Wide Web today.

I guess that this gets to my point. Most people who have never seen a large enterprise architecture have no concept of what it is. I'm not trying to imply that Dare is one of them, but stating the RSS and REST are cures to enterprise grade problems seems a bit myopic. So, to Dare's point - why is it more complex to do 'enterprise grade' over 'web grade'? This is the million dollar (or perhaps billion dollar) question.

Of course I have my views, but what are yours? Send me your thoughts jschneider-at-momentumsi.com and I'll recompile for publishing. My gut tells me that there is a pretty good argument to be had here - if Dare is right, I want to be the first to advise my customers. If he's wrong, well - I want to advise my customer of that too!

The Web is the Application

I was playing with Google Finance:
http://www.google.com/finance?q=WEBM and realized that the what used to be a static html page was now a highly interactive application. Of course, I am referencing all of the AJAX functionality that has been added. In many of our current AJAX apps, the focus has been to convert classic applications like email, word processing and spreadsheets into Web 2.0 apps.

The conversion of 'traditional' web pages to interactive apps deserves special attention. This is the science of blending information based on context, degrees of separation and providing the ability to quickly pivot the view. It seems as though there is a point where a web page is no longer really a web page but rather an contextually bound application. The art of blending information, informational views, navigation and functionality will likely be a critical talent of the next gen application developer.

Redneck SOA

I just found an old post of mine (almost four years ago):

http://schneider.blogspot.com/2002_12_01_schneider_archive.html#90283350

An Enterprise View of Application Architecture

Just something to consider...

Client Service Computing

I'm starting to move away from the term "SOA" - I'm slowly starting to replace it with more specific terms. One is 'Client Service Computing', which focuses on a real simple use of clients to consume services (or composite services).



A second term that I've been using is "Service Network Computing" which focuses on the plumbing that makes hokey Web 2.0 applications capable of performing 'business critical' applications.

A View of Competing Interests and Concerns

One of the overarching themes of the Web 2.0 discussion we've had today focused on "Putting the User at the Center of the Universe". I wanted to make sure that we didn't leave off the other competing interests.



We always have to balance the needs of the business with the needs of the user. Our next generation architectures will be funded to enable next generation products, services, business models and value chains. And both User and Business will have architectural requirements which must be met. Perhaps taking a secondary seat is the needs of the developer. The hokey use of DHTML, AJAX, etc. perhaps is the most obvious indicator - we're jumping though hoops to meet the needs of users and business - IMHO, the way it should be until we get next-generation tooling.

Web 3.0 Maturity Model

I'm attending the Spark conference - a Microsoft sponsored event to discuss SOA, Software as a Service and Web 2.0.

The conversation has been a bit chaotic. It is clear that we are covering a lot of ground - perhaps too much ground. Architecting the future using terminology that is not baked isn't easy. All of the participants come from different backgrounds and have different views of what SOA is - what SaaS is - what Web 2.0 is. And no, we weren't able to find the silver bullet. I think we did make progress in finding some common ground about what is 'new' and 'different'.

The conversation has inspired a few thoughts around the aforementioned subjects. Again - no answers - perhaps more questions.

One of the discussion topics was Web 2.0 - although there was no conclusion on the tenets/philosophies of Web 2.0 a handful of attributes were repeated: User Centric, Self Service, Collaborative, Participative, Communal Organization, Lately Bound Composition, etc.

This led to yet another discussion about lack of 'mission critical' capabilities of the Web 2.0 and started the discussion of Web 3.0 - perhaps focusing more on the needs of the corporation. I put together the following illustration as a way to frame a discussion around the Web X.0:
What are the technical barriers?
What were the technical enablers?
What new capability did this enable the user or business?

Web Me Too, Oh...

I've had to take a good look in the mirror. It has not been easy. Today, I am confessing:

I am a "Web Me Too, Oh..." guy.

Yes, I failed to fill out the proper paperwork and declare myself an official Web 2.0 guy prior to the November 2005 deadline. Now I must wear that humiliating "me too" badge.

I've been told that I'm not allowed to skip directly to Web 3.0 due to some amendment that Tim O'Reilly put into law. Apparently, Web 3.0 will be released but only at a secret conference of uber geeks that write mean things about Microsoft and donate to EFF.

In the meantime - I too am attending SPARK. Let's get real... we've got a major shift going on in the presentation layer, collaboration, content management/distribution and self-service programming. The discussion has shifted from REST, WS-*, etc to client consumption models, combining multiple services, utilizing markdown languages and light weight scripting languages.

It is very clear to me that the Web 2.0 movement will drive the demand for SOA. Perhaps more importantly, Web 2.0 will mandate the technical requirements for SOA. The Web 2.0 manifesto is the requirements document for SOA 2.0.

More SOA Consolidation...

Forum Systems has acquired SOA security vendor, Kenai Systems.

Here is the updated SOA acquisition list...

Now, for a prediction - we'll see one more acquisition in February and two more in March. They'll be in three different spaces, one in each: "Run-time Monitor & Mediate", "Governance" and "Registry/Repository".

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.

---

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

---

YOU WILL EAT CARROTS!
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.

SOA Pilot Program

REGISTER HERE

---

IMPLEMENTING A SUCCESSFUL SOA PILOT PROGRAM... A WEBINAR ON FEBRUARY 2nd, 2006 at 2pm EST/11am PST

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.

---

REGISTER HERE

The Value of Reuse in SOA

The MomentumSI SOA Team recently published a brief on 'Reuse in SOA'.

See:
http://www.momentumsi.com/SOA_Reuse.html

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???

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!

Microsoft SOA Contest

The Great Microsoft WSDL Hunt


SHOW ME THE WSDL!!

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

Rules:

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.

SOA-WS and CORBA

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.

Differences:

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.

---

Thoughts...
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'.