Fast Takes

Changes

2006-02-18T18:40:00.000-08:00

It has been a long time since I last posted. A combination of things, have caused this major case of blogger's block. Lack on interesting things to say or comment on, and working through some career decisions. Though I did have the chance to build a fairly extensive REST application interface that did illustrate (to me at least) the power and simplicity of REST. To design a well thought out REST application is hard, and is very dependant on defining the core resources and their granularity. Once they are defined the interfaces follow naturally.

However the changes mentioned in the title are not around a life changing conversion from upper case Web Services to lower case web services, I still believe they both still have their place and both could do with some improvements.

The changes are a little more extensive professional, after several years working in start-ups, I have made the change to work at a some what larger company. A few weeks ago I started working at Cisco Systems in the Application Orientated Networking (AON) group. It is challenging and exciting as we are working to make the network smarter and hence simplify how applications are developed.

Now that I am back working directly in the web services (both upper and lower case) and distributed computing space - I hope my blogger's block will be cured....

Search: Depth, breadth and trust

2005-06-22T08:14:00.000-07:00

This Yahoo Search vs. Google and Technorati: Link Counts and Analysis (by Jeremy Zawodny) prompted some thoughts about how search engines are going beyond a nice to have to a critical part of business and personal lives. With that comes a host of issues and makes that deciding on which search engine to use based on the number of pages it indexes and how fast it re-indexes them a secondary metric.

The most important metrics are going to become who can I trust most and who is less prone to manipulation either by inside advertisters or through extranal manipulation by sophisticated (and some not so sophisticated) linking schemes. How trust is propogated through a search engine is going to become the key differentiator (IMHO) over the next several years not the index size or refresh rate.

Tools and Artisans

2005-06-21T10:57:00.000-07:00

This from Doug Tidwell: "They're afraid that if they open up their business processes, their customers will realize just how little value they add" via Mark Baker.

My feeling is that many organizations confuse have cool tools/software with having people that know how to use the output effectively. The goal of business processes is to deliver information to decision makers. The difference between a great artisan and the rest of us is not the tools they use it is in their native and acquired skills. The same is true in any organization - great people succeed no matter what - good tools merely help make their life easier.

and to Doug's other point - no The Specials were the coolest ;-)

Interesting technique for predicating trends

2005-06-20T10:33:00.000-07:00

This from Tim O'Reilly via Tim Bray ongoing - The Java + Open Source Sweet Spot. When books were the primary vehicle for knowledge transfer I used to measure success/adoption by shelf inches at Stacy's (Great Technical bookstore in San Francisco). Tim O'Reilly now has a more scientific approach - and please increase the graph size, I need a magnifying glass to read the data.

However I am not sure this now tells the full story. I have noticed a substantial drop in my book buying habit, much to the relief of my wife who has had to navigate the piles around the house. It is not that I read less but rather the internet is more the source of up to date information rather than a book. I have mixed feelings about this, as I enjoy reading information from a book, especially sitting out on a warm sunny day. Laptops just do not cut it for reading outside or on the train etc. While the information junkie in me loves the immediacy of the internet and ability to research any problem quickly and easily. Hopefully tablet machines will get to the point where they are readable in all environments.

Podtech

2005-06-15T22:56:00.000-07:00

I did a podcast last week with John Furrier of PodTech - fun way of having a live discussion Podtech.net InfoTalk�?�� : A Podcasting Radio Show - "Fresh voices of Silicon Valley, Technology, and Media" He is looking for other CTOs for his series - so drop him a line.

Loosely coupled the simpler the better

2005-06-14T07:13:00.000-07:00

Matthew Adams makes a great clear case for not prescribing the end point technology. I would further interpret this as by keeping the definition of the end point to the minimum. Not prescribing the end point keeps the service loosely coupled, which is the objective yes?

Peer to peer or client server

2005-06-13T07:23:00.000-07:00

Reading a little on Ruby over the weekend I was struck by how artificial we have made that boundary between client and servers (Note: I have very limited knowledge of Ruby so excuse an inaccuracies). Ruby has a built in http server as part of the language. This seemed very sensible - most other language environments make http servers/interfaces a different part of the system.

This blurring of the lines between client and server seems to be the right direction. In this I would include AJAX both the client and server can send and receive events the only real difference is who is in control (machine or human) - does there need to any other difference's? It should be all about breaking down the barriers!

The power of the web

2005-06-06T08:10:00.000-07:00

The simple power of the web was brought home to me this week by my six year old. He had figured out Google Image search with a friend and proceeded to announce that Google was his new favorite toy. We spent all weekend helping him spell words to type into Google - he even helped his younger sister find Barbie pictures. It is so easy a six year old can use it - I wish all technology was that easy!

The amount of raw power in the hands of a six year old is something to consider. How will their brains develop when they have access to limitless information and what new skills will they need to develop to process it and determine fact from fiction?

Economics for inside and outside

2005-06-02T08:12:00.000-07:00

The drivers for using services and whether they should be inside the enterprise or outside the enterprise are partially rooted in the economics of fixed and variable costs. The fixed costs we all have are for our workstation, this cost has reduced dramatically from when it was a significant portion of an employees annual salary to the point where it is less than some monthly health insurance payments. Every employee now needs a workstation, an operating system, office software, and a communications suite - these are fixed costs ( this also includes in support and training). Whether you use Linux or Windows for large companies the costs are about the same as the biggest variable is usually support and training. A hard working CFO/CIO can shave maybe a few percent off these costs but in general they follow a fairly fix price model.

Enterprise software and services on the other hand have both potential for significant cost and for significant competitive advantage. The ability to turn these from fixed capital costs to variable utility model changes the way a company spends money. It shifts the capital expenses to the service provider and reduces large multi-year projects to simple connections. This has been touched on by Stefan Tilkov in The Same for Both Worlds and Tim Ewald looking at why inside and outside are different. I do not think they should be the fact they are largely different today is that the inside has not caught up with the fast evolution of the outside. The internet is much more loosely coupled than the enterprise and hence evolves faster. The goal of CIO's should be to move the internet model in house such that the enterprise becomes truly loosely coupled and can take advantage of services.

The other is the the wall between the enterprise and the internet is becoming increasingly porous and more irrelevant as services are delivered faster and better than enterprise software. It is no longer a competitive advantage to have enterprise software installed and managed internally it is both an unnecessary capital cost and an impediment to flexibility and moving the enterprise architecture to a variable cost model that tracks with the corporate performance.

Desktop software and services

2005-06-01T08:39:00.000-07:00

In Dictatorship of the Minorities Ulrich Drepper argues the point about the distractions caused b y porting to minority platforms. In some ways this mirrors my argument in Open Source - Software or services. However after thinking about the issue for a while I see there being two primary classes of software, software that runs on my desktop and services that run else where. The else where is becoming the major change agent as I do not (and should not) be concerned where the services are run providing they have an acceptable SLA (this includes security, latency, scalability, availability, etc.) for a reasonable cost.

While I am not sure the "dictatorship of the minorities" should or will be solved on the desktop it can certainly be solved by services as they only need to run on a single platform. Putting it another way - the value of desktop software (and I include server software in this group) is measured by the breadth of platform support and deployed seats, and how much it costs the owner of these seats to manage and support them while the value of services are measured by their SLA and it is someone elses problem to manage and support them.

Open source software has tremendous opportunity in the service model as there is no "Dictatorship of the Minorities" and the goals of writing great software can be supported by an economic model based on SLA not supporting software. In a recent article The Open Source Heretic Larry McVoy has a great quote:

"One problem with the services model is that it is based on the idea that you are giving customers crap--because if you give them software that works, what is the point of service?"

Infrastructure is necessary but does not differentiate a company, whether they run Linux or Windows will not materially impact there profitability as they need to have a certain amount of desktops and servers to run their business.

However using subscribing to and using innovative services wisely can transform a company in terms of significant cost reductions, dramatic increases in agility and the ability to quickly adopt innovative technologies that will differentiate them.

there.is.only.xul

2005-05-27T07:42:00.000-07:00

I have spent the last few days hacking a Firefox extension. While the platform is pretty cool and extensible the documentation is sparse to say the least. Even searching the web the amount of information is very sparse. This is proably an indication of the platform maturity.
However the number of extensions is however growing (a very good sign), so learning by readiing code demonstrates a key to the success of open source - building on the shoulders of giants.
With a little effort I was able to hack the webdeveloper extension and add a few new features that some of our design team needed. Many thanks to Chris Pederick for all his hard work and making his tools available.

It is really nice to be able to build on a full HTML/CSS rendering engine. I look forward to seeing a lot of great applications come from the platform. Once full EX4 support arrives with 1.1 it should be even better.

Open Source - Software or Services

2005-05-21T20:40:00.000-07:00

The acceleration of adoption and acceptance of open source by the mainstream is accelerating see: Investors to commercialize open source and IBM buys open-source Java outfit Gluecode. These are major chasm crossing events and should be celebrated, and congratulations to all involved. However I question that this is the best model economic model for all open source projects. In fact I will argue that if an open source application project is a technical success it inherently will undermine the current economic model, based around paying for support.

The current thesis is that users of open source software will pay for support, bug fixes, training, consulting and other soft services. The fallacy of this model is that open source software has moved into the mainstream because a vacuum exists. Existing software is not meeting the needs of the users of software. I am not an economist but my instincts tell me that the need for open source software such as Linux, Apache, mySQL. JBoss, etc is caused by economic forces not by any altruism within corporations. Successful open source projects succeed because they meet the market needs, have higher quality and are easier to use and maintain than closed solutions.

I would argue strongly that the most efficient companies in the next decade are those that minimize internal resources IT by maximizing the use of external services. This is a demonstrative trend - we have moved from internal data centers to shared data centers to managed applications within the last 8 years. The economics of shared resources are just too powerful to ignore except for the largest companies. Why does anyone want to hire a set of DBAs to manage a customer database when they can get it done for a few hundred dollars a month - and scales linearly by usage. Why does anyone want to buy install and manage a set of servers when they can have someone do it for a monthly fee - add, change, delete based on need not educated guesses but on actual usage. In other words the utility model is here and it is the economic model for the future enterprise - the most efficient enterprises are the ones that will manage it best.

The key differentiation that I make is between open source solutions and infrastructure. Infrastructure is operating systems and web servers etc. Solutions can be anything from an SFA application to an XSLT transformation engine. The model for the two is orthogonal - infra-structure has to be everywhere to power the grid ( like redhat and Apache) but applications like openCRX or XOOPS to pick a couple from SourceForge should not require deployment - they should just be usable. A recent posting from Tim Bray points out that half of IBM's income comes from consulting - the rest is from sales of hardware and software, with software being only about 1/6 of the total. To put it another way 25% of the cost is license fees the bulk of the costs 75% is from installing and getting it to work. No wonder there is so much shelfware around - a lot cheaper to leave it on the shelf. (Note: this is a somewhat simplistic argument but experience has shown me it is essentially correct).

Returning to open source - the drive for open source projects (IMHO) is to create software solutions that due to its open nature, benefits from continuous peer review and a Darwinian evolutionary process. The current approach to deriving economic benefit is inherently the antithesis of open source. The drive in an open source project is to make it more accessible and through peer review high quality - when these goals are achieved it becomes widely adopted. This inherently(and correctly) diminishes the value and need for support services. Putting it another way the most successful open source projects are those that are most accessible and have the fewest bugs and hence the least need for support. The current support model means for open source application projects to succeed economically they must deliver and continue to deliver software that requires support.

There is another way however that actually combines the best of both worlds and provides companies with a clear economic model for paying for services and enhances the ability of the open source community to deliver high quality software and if appropriate reap an economic benefit from their labors. For the majority of open source projects the model should be services not software. By services I mean applications that run on a managed grid that can be accessed by anyone. The applications are accessible as individual services or collections of services this attacks the largest area of costs that enterprises face.

This approach provides a few interesting benefits:

Drives developers to solve business problems rather than point solutions (how many POP services are listed in SourceForge?, why do we need so many - some is the Darwinian process at work. However the accessibility of all these projects is an issue.
Provides an economic model for developers (and potentially investors) to share in the benefits the work is delivering and motives the correct model - easily accessible bug free software has higher value for both the consumer i.e. I will pay higher for an easy to use robust service and open source developers want to deliver accessible highly secure and robust services.
The open source model still works - I can look at the code and submit fixes and accelerate the development as needed.
There is a reason to pay on going fees for the same high quality solution - the model is now about usage and the service level agreement (SLA). The higher the demands on the SLA the higher the potential fee. I believe this aligns the development and user community better than any other model.
The development effort is now focused on a single platform and not on how many platforms can I make it work on. It is focused on the solution not on how to deliver the solution onto multiple platforms.

This alignment of the economic model and the drives of the open source community is critical for the long term success of this model. Improving the quality and accessibility of applications while removing costs from the IT infrastructure is going to make enterprises more efficient and hence more profitable. Without this alignment the current wave of investments in open source projects will just be more VC roadkill as they are attacking small (25%) problem not the big (75%) problem. Instead of changing the model they are thinly disguised System Integrators that have experience in a specific set of technologies.

Dynamic Languages

2005-05-20T08:01:00.000-07:00

In Phil Windley's Technometria | The Continuing March of Dynamic Languages Phil suggests that Scheme is a great dynamic web systems. I have a fond spot for scheme as way back I worked on a system that used scheme as a dataflow language for creating analysis tools. It was based on some cool research a bunch of guys at MIT had done. It was extremely flexible and we could do anything with it. Coupled with XML I think it is a very interesting avenue to explore. I look forward to hearing more about Phil's adventures.

A small understatement from Stefan

2005-05-19T09:45:00.000-07:00

I just LOL when I read footnote [5] in Stefan's posting RPC-style Web Services. The only thing that compares to (and exceeds) the complexity of Corba is OLE2.

WSDL 2.0 - First impressions

2005-05-18T08:30:00.000-07:00

After reading Dave Orchard's Blog: WITW WSDL 2.0 HTTP Binding I downloaded some of the WSDL 2.0 specs to read on the train. I am pleasantly surprised as compared to WSDL 1.1 it appears much more accessible. Whether my positive impressions are due to too much reading of WSDL 1.1 not sure. Mark Baker as always has a very pithy comment that aside all the people involved should be congratulated for their hard work.
Congratulations aside, I question the idea of a "single SDL to bind them all". So I ask the question, why do we need a single SDL, when would I need to use both? It is certainly a nice idea but as technology evolves, different areas typical move at different rates and evolve in different ways. Linking them usually tends to be a bad idea.

Simplicity - Just ask why

2005-05-16T09:39:00.000-07:00

One of the most powerful questions I ask myself (especially) and others in reviews is why is something in a project. As engineers we have a tendency to like shiny new things, elegant abstraction etc.

As is pointed out in Quoderat � Blog Archive � Burden of Proof injecting simplicity is sometimes about just asking why something should be added or why is there a need for a layer of abstraction or why is there a need to make the solution completely generic. In many cases there are very good reasons to add abstraction etc.

We need to always challenge ourselves to see if we are solving a real problem - so just ask why.

46,213,000,000.00 things to fix

2005-05-12T09:05:00.000-07:00

This is classic ongoing � $46,213,000,000.00. Several years ago evaluating a J2EE servers I found this to be so true, downloading, installing and running test program for JBoss - under 10 minutes. While WebSphere the download was 14 times as big and getting running was days (i.e. call IGS). Is WebSphere so much more capable than JBoss - I doubt it and given IBM's recent purchase of GlueCode they might have seen some of the light.

Dissolving boundaries - inside and outside

2005-05-10T08:37:00.000-07:00

Phil Wainwright comments on dissolving boundaries Loosely Coupled | Dissolving boundaries | May 6th 2005 2:12pm. I think we need to make a clear differentiation between inside and outside boundaries.

Inside the enterprise the CIO has some degree of the framework between the silos and can manage the necessary change to define the fabric to achieve loosely coupled services architecture.

Outside the enterprise the CIO has little control (but has economic power) of the fabric. Here though is where there are compelling economic benefits for a CIO to use external services (see: Why Integration as a service?) or consider the economics of Salesforce versus Siebel. The long term winners here are going to be the providers of business services that destroy the previous economic models. The tools vendors need to change their POV from being the center of the universe (or single religion) and become enablers of wide scale service integration that provide dramatic economic benefits to the enterprise.

Resedel - Updated

2005-05-10T08:25:00.000-07:00

John Cowan's entry into service definition language Recycled Knowledge: Resedel. Looks good I think as I am better with Schema than RelaxNG. (Update - thanks to trang here is a XML-Schema version of Resedel resedel.xsd)

Biggest question is why translate HTTP-GET et al explicitly into CRUD - expose the URL verb, another layer of abstraction can be confusing.

Service Descriptions - Just the docs?

2005-05-09T08:28:00.000-07:00

Couple of interesting posts: Dare Obasanjo aka Carnage4Life - On Replacing WSDL with Something Simpler and Mark Baker- ongoing - SMEX-D.

Both make the point that having an interface language for services should not do very much. From my POV I want primarily a means of getting accurate documentation on the interface (and also providing it to consumers of services). For all its warts Javadoc was a great step forward as it provided a way for developers to provide documentation will minimal effort. Until Javadoc the best examples of standard docs that I had experienced had been man pages, and some Lisp environments.

For services to be propagated widely there is a need to provide documentation that is easily created and kept up to date. Perhaps this is the starting point for a service description?

the simplest thing that can possibly work

2005-05-05T15:02:00.000-07:00

Quoderat � Problem-first design - great POV and quote

Service Descriptions - There does not need to be j...

2005-05-05T07:49:00.000-07:00

There has been some really good analysis and thinking about service description languages recently by several smart people (Tim Bray:SMEX-D, Norm Walsh:NSDL, Mark Nottingham). Everyone of them makes some excellent suggestions and brings a unique POV. One of the challenges that everyone is assuming is that there needs to be only one service description language. I challenge this assumption and suggest that more than one is actually preferably.
The are a few reasons for wishing there should only be one service description language:

We have a mind set that is framed by the Web publish-find-bind triangle where we assume that magic happens by everyone automatically discovering services and magically binding to them to solve complex business problems. This implies that there is a many to many relationship between services - all services need (and can) talk to all other services. In the real world this is more like one to a few or few to a few - a slight over design.

There is the burning desire for protocol independence - between companies there is unlikely to be a placement for HTTP/SSL anytime in the future. As the enterprise architecture is slowly being decomposed into services provided by outside organizations I would suggest having a single transport is more important than have transport/protocol independence. If the transport information is cleanly separated from the message there should be no issue in replacing it with a different transport - a good example is EDI and AS/2
The complexity of integration is not in the communication of messages it is in the integration of the semantics after the message has been received. Currently we are doing several integrations a month with a wide range of systems. The message delivery is not the problem it is the semantic meaning of the messages and this is in a single well defined vertical.

Tool development has always been a good reason for having a single set of standards that all vendors build. The tools are complex because the service description is complex, and there is a lot of complexity introduced by RPC. If we focus on the message (where the real integration occurs) there are really good tools available, XMLBEANS for Java does a truly great job of providing a binding between XML and Java, similarly XSD for .NET and I am sure there are many others. These tools work on basic schema's and are generic tools - rather than specific more complex tools.

One of the really good aspects of the service description languages described by Tim Bray, Norm Walsh is that they use the same vocabulary as the transport i.e. HTTP -this makes it a lot easier to understand as it does not add another layer of verbal indirection. This reduces the learning curve and hopefully the ambiguity. Having several service description languages is not an issue if they are all in xml they can be transformed from one to another easily. As the transformation is a design time dependency and not runtime a runtime one there is no performance penalty. The major issue may be loss of meaning but there are only a limited set of MEP's so this should not be a long term issue.

The tendency today for web services is to add more features and hence the complexity is increasing. Shift the focus to how simple they can be and reduce complexity, lets see how easy it can really be.

The focus must be on the communication of information and not overly abstracting the service descriptions to a point where everyone just gives up and writes word documents.

Telescopes and views

2005-04-26T10:04:00.000-07:00

Jon Udell's essay "The wrong end of the telescope ?" raises some interesting issues and summarizes some thoughts from several sources.

They all go to illustrate how difficult it is to put a simple application into a browser page. A part of the problem is that the browser/http/web server combination was never designed to support the rich applications we are trying to shoe into it. Therefore the issue is not really different ends of the telescope but rather different telescopes. Programming the browser is very different from programming the server and they do not connect very well.

The problem lies in the marked impedance between the browser model and the server programming model. Server side programming is relatively easy - the tools are there and it is up to the practitioner's to use them correctly.

To match the server side interfaces with the client is hard when you go beyond a simple form. Entering the world of multi-page applications becomes challenging to say the least. We have invented all sorts of interesting work arounds/add-ons - cookies, frames, iframes, DHTML etc to try and make it possible to deliver rich applications. Some people have created neat frameworks to help such as this from cross-browser.com but in the end the complexity remains in connecting the back to the front.

A good indication of the overall complexity is the number of attempts to build easier to use frameworks - everyone has made an attempt at creating either a new scripting language, a new template framework, a new application stack, application builder and now rich clients. The
proliferation of these tools is a symptom of the problem- sophisticated web applications are too hard to build. The reason is, I believe, there is a impedance mismatch between the browser and the server - HTTP is not the issue.

Sometimes it feels like we are all using different telescopes to hunt for the most elusive thing of then all - the easy model of building, debugging and maintaining sophisticated and usable internet applications.

Building knowledge from parts

2005-05-03T07:53:00.000-07:00

Google has done a great job of decomposing knowledge and making it accessible but is it possible to build knowledge from parts in an automated fashion.

The first questions two ask are 1) Is it possible to build useful knowledge for components in an automated way - (Rooter a machine generated would tend to suggest otherwise:-)) 2) why would we want to do this.

For me the why is the information overload caused in large part by change. A tool to categorize and filter information intelligently would be a better Google. Navigating down to page 15 of a Google search to find a nugget is not very productive. Though compared to the alternative it is a major step forward. Being able to compare and contrast becomes even more interesting an intelligent Google Fight (thanks to Mark Baker for the pointer) may be an interesting starting point. Rather than distill knowledge provide the ability to contrast and compare POV - something our political process badly needs.

How about parallel news tickers showing pros and cons on a viewpoint to help decide on a course of action. How about an uncertainty measure - we all know the uncomfortable feeling of not having enough information to make a decision - does it help to quantify. We live in an imprecise world is it possible to measure/estimate the degree of ambiguity?

So search is great but it is just the start - we have parts now what are we going to build to create new knowledge and understanding?

EDI - Simple enough?

2005-04-19T07:51:00.000-07:00

A comment by Mark Baker around EDI got me thinking about the current amount of infrastructure we are building on top of the transport. Today millions of business messages are flowing formatted as EDI messages and thousands of business processes are built using the MEP defined by EDI documents.

So what is wrong with just using EDI. Probably a couple of things, at one point the cost of the initial transport hardware and communications infrastructure but this has been solved by the draft AS2 standard which is essentially EDI over http(s) which has reduced the costs dramatically. So much so Walmart has mandated it for all communications.

The amount of work that has gone into the MEP and the definition of the document elements is huge and extremely valuable IP. The only remaining piece is the actual format itself which is very �concise� as it was designed when bandwidth was expensive. The format itself is hard to work with compared with XML due mainly to the lack of tools. If every language had an open source EDI parser (or two) and a transformation tool like XSLT would everyone be using EDI today?

The mechanics of EDI at the MEP level provide a fairly complete set of business interactions but getting into the details of the message and extending the messages is very complex and requires very specific knowledge that is only applicable to EDI - no one has every used EDI as a format for config files or build scripts. XML on the other hand has become the universal data language, because it is so easy to manipulate and mold.

In some ways the discipline that EDI imposed has resulted in a loss of simplicity as instead of a set of well defined MEPs we now have a large number of standards that try and do the same but in fact do not focus on the MEP but rather on making the communication more complex. Where is the WS-850 rather than the generic WS-Metadata. Are we missing the point because it is to easy to avoid it?