Smaoin agus Barail

The Biggest Problem with Technology

2012-01-17T16:07:00.000-05:00

The biggest problem with technology is complexity. A technology is only as valuable as its ability to be used to provide value (for a feasible, commensurate cost). When any technology is too complex it creates barriers to its use. Even if a technology that has great value to people and organizations, it will see little interest if it is too complex. Even if the value of the technology is commensurate with its complexity, the lack of use (aka adoption) will be apparent. There may be a general lack of interest to a technology, however if interest is high and adoption is low, there's a high probability that complexity is the cause. This can be summed up in a simple equation:

technology adoption is inversely proportional to its complexity

Much of the following comes from a discussion on complexity when working on a Semantic Web solution for a financial services client awhile back. This example illustrates a common pattern I've seen repeat itself in technology time and time again, and I expect this to continue:

One technology that fits this complexity equation is the Semantic Web. If you look at the initiatives such as standards, notations, reference implementations, technologies and even products, for the Semantic Web a few obvious observations may be made.

First, most of the "members" of the Semantic Web community are in Universities, working in R&D labs for commercial companies or governments or in high-tech fields such as bio-tech.

Second, much of the work is designed for and by individual researchers and users. If you survey the open source Semantic Web technology you'll notice very little work has been done to support multi-threading, concurrency or even performance at Web scale - that is an exercise for the user. Perhaps commercial products provide this, but they are too costly and their trial versions are insufficient time-wise if you have a day job and a life or capability-wise if you want to do something slightly complex.

Third, much of the work to date is theoretical, however there are some excellent examples of Semantic Web solutions. Unfortunately, these real examples are too complex and esoteric for mainstream extrapolation, but it does prove that given sufficient motivation one can make the Semantic Web real (but not really practical).

Which brings us back to the complexity equation. If you have the time and can hire or fund research to develop Semantic Web solutions, you can; most people can't, and most organizations that could, won't. Why? Because it is risky, the value isn't assured for the required investment and there are many commercially proven technologies with less risk and sufficient value to fund. Semantic Web is too complex, and therefore too risky or expensive, to warrant its use in general, mainstream, computing solutions.

But what if you want, need or could use what the Semantic Web promises?

Faced with the challenge, promise and opportunity of semantic technology, a Web community formed to address practical use of semantics. Not intentional initially, though, as they had a more practical need, semantics was an implicit byproduct of their efforts. They surveyed what they knew/know and what was already out there to use and reuse. Let's see: HTTP, HTML, XML, XHTML, tagging, RSS, Atom, AtomPub,.... Then in a brilliant move, instead of standards designed by committee over many months or years, they created agreed conventions where anyone in the community is able to participate, discuss and offer recommendations and ideas.

The conventions are extensible; allowing others to add and extend, and share them. Anyone can add this metadata to their existing information,extend it to meet their needs, embed it into their existing Web information or dynamically create and combine this information. If someone receives this information and is unable to parse some or all of this metadata, they can simply ignore it. How's that for practical? This is the essence of the lower case semantic web, and it really started with the distributed community known as microformats.org, often referred to as simply microformats.

Embedding and including meta-information in content to provide basic, but potentially very rich, meaning in content on the Web was a pragmatists dream. This pragmatic, practical approach to add structured semantics to Web content in a manner accessible to a wide range of Web practitioners at many levels, was at the opposite end compared to the approach of the formal Semantic Web.

While the big R&D shops, universities and others with deep pockets continued their theoretical modeling and implementation exercises of the Semantic Web in their Ivory Towers; bloggers, wikimasters, webmasters and other denizens of the Web began to structure, define, add and share meta information using the common tools at hand to create something new, practical and usable. Since microformats are made of very basic components of the Web (and Web 2.0), they are readily understood by many and varied denizens of the Web from PhDs to corporate developers to Junior High kids who can put them to use in whatever context they require.

In essence, the upper-case Semantic Web has found itself circumvented by the defacto conventions (still not standards) of the lower-case semantic web used by many. Again, simplicity has trumped complexity in the utilization of technology, in this case, semantic technology.

Even if the Semantic Web is better, richer, fuller, more rigorous, etc., than the semantic web, simplicity will usually win over complexity. In this context, winning is really widespread use. Widespread use infuses more content throughout the long tail of the Web with semantics through simple meta-information, which in turn leads to more meaning in Web content. With the increase in meaning in Web content, we have a richer set of meaning with which to work in the next round of Web content creation and distribution. This is recursive, as more semantic content leads to more meaning, which leads to more semantic content...

Have a look for yourself, microformats and Semantic Web and see which is best for your semantic needs.

Peace.

What's an alternative to SOA?

2012-01-06T17:22:00.001-05:00

Thought you'd never ask (maybe you didn't). This is not new, but hopefully this will encourage a few to look deeper into this option, especially those in enterprises with enterprise architecture teams. Using your favorite search site, have a look at Web-Oriented Architecture (WOA) or Resource-Oriented Architecture (ROA). I'll use WOA, but ROA is interchangeable for this post.

The good news about WOA is you probably have many of the technologies and infrastructure components, and know enough about the standards and technologies to get a WOA up and running fairly quickly. If you are an enterprise architect, you may not like the approach or may want to combine it with SOA, big, complex EA and any number of other things, but try to keep an open mind and keep things simple.

To keep things simple, define a small set of standards and technologies that will be used in your WOA. To get started, you will need a basic set of standards/technologies. For example, a good starting point would be:

HTTP/HTTPS
URI
JSON (and/or others)
REST

If needed, you can add RSS, XML, and other open standards, content types, etc., to define the fundamental set of enabling standards/technologies for your organization's WOA. The objective is to keep WOA-based solutions to a small set of common web standards, and resist any temptation for more complex approaches. Keep it simple. If there appears to be a situation that can't be addressed by your choice of standards, you should search for solutions, ask questions or hire an experienced web consultant (probably not a bad thing to do early in the process as he/she can help you define your WOA standards and technology options), etc., that is, the web (for the most part) has been built on these standards so whatever you need to do should be possible...if you can't figure out how, find someone that can or has!

Looking at the above list you have fundamental distributed service architecture capabilities:

HTTP/HTTPS - provides messaging and methods
URI - provides the resource identification (endpoint addressability)
JSON - provides a simple data representation
REST - provides the resource (instance, service) model

With these, you can define a very robust WOA. We have a way to send/receive messages, package messages, define messages, consume/respond to messages.

You'll also need to consider security. There are several options such as TLS (SSL), OAuth, OpenID, OpenLDAP, encryption, etc.; there are open source and commercial options...but essentially, you need authentication and authorization at a minimum, and you may want more such as accounting, auditing, encryption, etc.

The heart of a SOA is the Enterprise Service Bus (ESB). If you consider a SOA model, the ESB "sits in the middle" processing all (most/many...some subset if not all) message requests and responses; it may transform, parse, enrich, strip, burst, etc. processing the message. If you are using WSDL and the plethora of web standards that can be added to WSDL, you'll have a fairly large envelope to process which will take even more time. To process these messages (maintaining SLAs and QoS) would require significant infrastructure, that is scalable and fault tolerant and the end result is likely expensive. If you are using a commercial ESB...even more costs. Complexity and cost, what are the benefits, when will the benefits be realized?

The heart of a WOA is the web server. There are many options here, and you probably already have your own favorite set of web server technologies. That said, this may be a good time to have a look at more modern web servers (e.g., nginx). At the simplest level, a web server processes requests, ideally quickly and efficiently and can scale to a large number of users. In a WOA, requests can be processed locally (by / on the web server) or remotely, by another web tier that hosts/exposes REST endpoints. The REST service implementation is up to you, what it does and how it does it, is also up to you. That's really it.

In SOA, a collection of web services isn't sufficient as you need service infrastructure too. In a WOA, having a web server and REST services is about it. If you want SLA, QoS or other analytics, you can add those to your web server or your current infrastructure if you don't have them. SOA builds on the basic web infrastructure (adds more infrastructure); WOA is the basic web infrastructure. WOA is used by the Internet, it should meet your needs as well.

Everybody is doing it!

2012-01-06T17:13:00.000-05:00

Everybody is doing it...

Are they? How do you know? Just because it's popular doesn't mean everybody or even a majority are doing it. Even if everybody or even most are doing it doesn't mean it is right or always right for everything. And, if it's being done, how well is it being done? How do you know?

What are some things everybody is doing?

Service Oriented Architecture (SOA)

How's that working out for you? Are things better post-SOA than pre-SOA? Have you performed a cost / benefit analysis? Are things more efficient or cost effective? Are things more or less complex? Are you able to better respond to business requirements, faster time-to-market? Have your software, hardware, support, maintenance and labor costs increased due to the need to implement, maintain and support SOA? Has your availability improved / unplanned outages, SLAs and QoS improved? Can these be associated with your SOA initiative?

What large public web sites offer SOA (SOAP, WSDL) service endpoints vs. offer REST endpoints?

I'm not saying SOA is a bad idea, just saying it could be wrong for your business model or simply overly complex and expensive for your requirements or your organization.

One thing that should be obvious is to look at who is promoting any particular approach, model, technology etc. and consider why they are promoting it. It is likely they have something to gain from use of that which they are promoting. Yes, this includes me too.

One of my motivations, besides looking for consulting opportunities, is architectural simplification. Things have a tendency to get complex on their own, without having to start with a complex architectural approach. For my customers, I make assessments based on many factors to determine a recommended approach, solution and/or technology that will meet their requirements and expectations. Have two or more options with pros and cons is always a good idea.

Who is promoting the use of SOA? Is it your IT department C-level / SVP execs? Is it a consulting firm? Is it your own "Enterprise Architecture" team/personnel? Is it your software vendors? I find it is not often IT execs promoting SOA or EA unless they have been influenced by some other player. IT senior execs, other than tech/innovation focused CTO / Labs / R&D types, are predominately cost/efficiency/risk management focused...keeping costs under control, keeping business systems up and running and meeting their customer requirements in a timely/cost effective manner. Even if something promises to be better, new things introduce disruption, cost, uncertainty and risk. Even more so if these new things are complex.

SOA isn't bad or good, it fits or it doesn't which depends on your specific requirements and your capacity to support it.

So, keep an open mind, consider alternatives and options, and consider the motivations of those who are promoting SOA, EA, Clouds or anything else for that matter. Complexity is expensive, and once in place it is difficult/costly to remove. Be an informed, educated technology consumer. Just sayin'.

SSJS = Server Side JavaScript

2011-10-05T13:33:00.001-05:00

LiveScript was a very nice, general purpose programming language initially, however it was subsumed into the marketing hype of the day to be renamed and forced fit into a company's web browser product to manage the HTML DOM and we have the often/much maligned result: JavaScript.

I know many web developers, especially in enterprise settings, that barely tolerate JavaScript and others that "hate" it (their words not mine) and others that banned its' use or at least limited its' use for a myriad of reasons, mostly due to security. Web security is very convenient if you want to limit something...even if there is a kernel of truth to it...however that is mostly an implementation issue that should not reflect on the language itself, IMO.

FWIW/IMO, ECMAScript is maturing rather nicely. The JavaScript language has a great set of programming features some of which were created in one of my favorite languages that never-really-was-successful, Self. Dynamic, prototypes, functional, imperative, OO, ... very flexible. For more information on the language itself, I highly recommend Eloquent JavaScript.

V8, Google Chrome's JavaScript engine, has reinvigorated this space, though I'd like to see more interest from Mozilla on Rhino and SpiderMonkey...and see other players enter this space. By far, the most interesting and promising SSJS is provided by node.js. I'd like to hear about other options and/or experiences using node.js or SSJS, please share 'em if you got 'em!

No technology is perfect, and you have to determine which technology is the best fit for purpose for your solution. I have a core set of technologies that I use for what I tend to call "nextweb" or realtime web solutions, and SSJS is a foundational component...and so far node.js is the best option I've found for SSJS.

In the past, JavaScript has been limited by its' implementations and where it has been "forced fit", though the number of client-side JavaScript frameworks and SSJS indicate that these limitations are no longer valid. With a small core set of technologies, most with open source options, and open standards, the nextweb can be utilized today by any organization willing to capitalize on it...if only they can give up some of their reliance on enterprise "bloatware" for their web solutions.

SSJS, just think about it, and maybe, just do it!

2011-09-30T15:24:00.000-05:00

Wow! What a wild ride the last few years!Digging into my old web presence I found this blog. I haven't used it since 2008, and I'm surprised to see it is still here. Then, I was involved in Semantic Web solutions; since then, I refocused on realtime web solutions which are also amenable to the Cloud.

The last few years have been a wild ride technology-wise and I have an updated perspective on the web...nothing earth shattering or paradigm shifting if you already know this stuff...here is a high-level summary:

Microformats are a very good thing; the tactical, practical semantic web (lower case)
JavaScript is a wonderful programming language, in spite of it being forced into the HTML DOM
jQuery is an amazing and useful framework.
REST is all you need for distributed web architectures (sure, there are a few more foundational standards)
Realtime web is viable, but not well-known in terms of value and technologies to most mid-large size organizations who stick with their big name, high cost technology solution providers and bloatware.
Realtime web solutoins can be designed to use a small set of common standards and wide range of open source software.
Enterprise architecture - where's the value realization? For those who have embarked on enterprise architecture initiatives, have large teams of enterprise architects with all the necessary certifications (and/or consultants too) have you seen real ROI? Have you broken even? Are you even tracking this?
WOA > SOA
Artificial Intelligence and Knowledge Engineering provide implicit value but don't sell well if stated explicitly and directly. One needs to use more popular buzzwords and euphemisms.

Going forward, I will focus on my experience and findings regarding WOA and realtime web architectures, designs, technologies, web standards, as well as using the same for server-side with mobile and desktop clients (web, native); JavaScript and related frameworks, server-side JavaScript. Of course, I will continue to ask for information on enterprise architecture value realization and ROI.

Thanks for reading!
Siorc

Semantic Web Open Source Software Hole?

2008-07-28T13:52:00.007-05:00

If you have been working or playing with any of the open source software (OSS) efforts that implement the W3C standards, you may have noticed there is a major hole: thread safety and concurrency! Most of the OSS software is very good for learning, experimenting or creating single user solutions, but beyond that, you are out of luck.

That is, if you want to use semantic OSS libraries or code, you have to provide the multi-threading support. Impossible? No, of course not, but to do so, you have to provide a threadsafe / concurrent environment or get the OSS source code and rewrite it. Neither of these options are appealing. This is work, a means to an end, and its extra. If you want to provide an OSS-based semantic solution on a website where there is a possibility of two or more concurrent users ;) you will need to do some work.

Of course, buying a commercial product is an option if you can afford it, and are willing to work at the vendor's release pace and no access to source code, etc., that's fine...but then, you aren't using OSS now either.

If you are going to provide open source software for semantics, or just about anything else, and you want your software to become popular and enjoy widespread use in the "real world" - you need to provide thread safety, concurrency and even consider multi-user environments (e.g., like a web server!). If not, then your OSS will not likely see much use or notice.

I think the main reason for the slow uptake of semantic technology (and some other advanced technologies) on the web is not complexity, standards or usefulness of the concept, but rather the state (or rather the lack of state management / thread safety and concurrency) of Semantic Technology OSS and the cost of commercial semantic technology.

Its time many OSS projects recognize the realities of software for the web: multi-user environment support is a good place to start.

What do you think?

REBOL 3, where art thou?

2008-01-10T22:00:00.000-05:00

Nearly a year since I blogged about my anticipation of REBOL 3 and its imminent release, and I'm still waiting. Anyone else waiting too? The latest status update was last October. Now the reason things "appear" to be so quiet on REBOL 3 is simple. Since I'm not an active participant in the development of REBOL 3, I don't have access to the information flow. This cuts down the noise the actual, active developers need to deal with, and the promise of new, open AltME worlds once 3 is released all makes sense.

As I was waiting looking in from the outside, I took a quick look around the REBOL sites and found (from here) the alpha is available. (scroll to the bottom of the blog entry to get the link). Kudos to the REBOL 3 team! (and many thanks too!)

Sun's Lively Kernel - Old Tech Refresh

2008-01-04T16:45:00.000-05:00

Sun ( I used to work there for many years) has a Labs project called Lively Kernel which builds on old OO technology that is very advanced compared to much of what is out there today. The heritage is Self, Morphic and Squeak. Self is one of the best unknown languages ever....from Sun Labs who has taken this early 80's language and updated it a few times this century. Lively Kernel takes these advanced OO concepts and blends them with JavaScript for a very rich internet Web 2.0 solution.

Self is a prototype-based with traits language. Very different. Follow the Self link above for more info on the language and actually download it (if you don't have a Mac OS X or Solaris SPARC(tm) machine, oh well, but you can read about it. If you are a smalltalker or squeaker, it will be interesting for you!)

It is great to see these concepts refreshed for the Web, where hopefully many developers will find value for the mainstream.

Native Web Apps

2008-01-04T13:41:00.000-05:00

Here is an example of taking Web Apps native on the Mac. Its called Fluid. It uses a concept called Site Specific Browsers (SSBs) to run web apps as separate desktop apps. A bit of an inverse to what I was describing in my last blog entry. It requires Leopard which I have not had a chance to migrate to :( So at least I can take my Web apps native, now I need a tool or framework to make lightweight native apps that work like Web Apps!

Another interesting project that I have used in real life (and been following for a long time) is for Java (the .Net version is lagging), is Naked Objects. Your domain model objects (POJOs) are reflected to generate the UI which is user customizable. The Model (that contains behavior) is used to generate the View and Control. Works great for internal apps for knowledge workers that know their domain. You can easily switch from client app to web app. It has come a long way. Very RAD! A good framework to have in your Java toolbox.

Rich Internet Applications: They're Great! But Not Enough

2008-01-04T11:06:00.000-05:00

The Rush to the Web is really amazing. Google Apps, gadgets, Yahoo pipes, and a plethora of RIA (Rich Internet Apps) technologies are making great strides in making the Web experience as rich and powerful as native, local applications. This is great if you live in technology metro-centers where you always have a connection. Without a connection, you are out of luck. There are a few people out there making the Web experience work offline...which begs the question: If I'm working offline, why am I using Web apps? There are many good reasons to do this, for me the most important is seamless user experience: there is little visible difference from working online vs. offline other than the obvious lack of connection.

Still, there is the contrarian curmudgeon in me that says there is something amiss with this. And, as a P2P practitioner there is another model. Smart apps for the local machine / OS...or Java, etc., if you want cross platform. Why not use the power of the local application environment with all the look and feel comfort of the local OS not to mention the computing power of the local machine. I have a tough time making this case for Windows, but it certainly works for UNIX, Linux, BSD and most especially for the Mac. I mean, I paid top dollar for the Mac experience and now I'm limited to what I can run in Safari? Not enough, thanks.

My Macs, combined with a .Mac account provide what I need and want to use. What I want is an easy way (dev tool) to mash-up (and consume, process, apply logic, etc.) data from various sources across the Web and my local machine / machines on network (ala Bonjour) using an easy-to-create native UI toolset for Mac OS X.

The closest thing I've found to gather the data is RSSBus Desktop. Unfortunately, it is .Net centric. It also doesn't offer a native UI builder either, which is what I want...for the Mac.

A prime example of a rich local application that works connected or not is iTunes. Many Widgets in OS X work the same way. I can build my own special client-side apps using Xcode but that is more heavyweight ( a real programming IDE ) than what I want and need for simple apps. So, how do you build local client UI applications for Mac OS X without Xcode that can mashup data sources using a lightweight Web 2.0 toolset approach? If you know of any tools (preferably open source!) please let me know!

Web 2.0 web-based rich Internet applications hosted on remote servers are fine and valuable but I also want something richer and more native to my Mac that takes advantage of my investment in my local machines. I want it all!

Mashed up data (sounds like mashed potato)

2007-05-11T12:35:00.000-05:00

Data is a necessary piece of nearly every software solution (I'm sure we can all think of exceptions, but there is data there too). Web 2.0 via mashups makes data integration from various sources relatively easy. Applying the MVC pattern to Web 2.0 we have view and control provided by Flex, AJAX / JavaScript / wikis / feed readers / browser, etc. and the model JSON or just raw data in syndication format. The formal nuances of data, its structure and relations, etc. are not the focus of mashups but rather pulling out relevant information fragments from various sources into a new whole (aggregation, composition, integration, etc.) creates a new information model, that requires new controllers and new views (unless you can reuse those from elsewhere too, but by and large you are pulling in data, aggregating and defining a new format, contollers and views. That's it. So why do IT departments seem to make it soooooo difficult? Job security and FUD.

Web 2.0 is, and provides, RAD (Rapid Application Development) for the Web. (RAD came out of the client server era, and in many IT shops today the term or concept are never used due to negative connotations and associations of an historic nature). RAD was cool and good back in the day as it empowered less skilled application developers to be more productive...today Web 2.0 technologies allow both developers and non-developers to create powerful, compelling softwware solutions with minimal effort. Minimal effort means a faster time to market as well as lower entry costs, redo, scrap, do over, change all become more cost effective and viable (and faster too).

To see how effective web 2.0 can be for you here are few cool tools that I find valuable. Note, I am not affiliated with these companies, developers or communities in any formal business or even friendship manner; I simply like what they have to offer and I think you will too:

First, for any IT people reading this, you should go have a look at ActiveGrid. I blogged about AG before, and will do so again in the future. If I was in charge of a small IT shop (or a team in a large IT organization) that needed to provided higher value, reduced costs and enable greater agility, this is where I would start. I'd build and deploy new apps on AG, retool my IT employees and start a migration plan for existing applications. I'd also start with the open source version until I was nearly ready to go to production and would give careful consideration to a commercial license based on the information available to me. ActiveGrid would be a foundational technology platform upon which I would rebuild my IT infrastructure. Period, end of story.

These other products and technologies could be leveraged by IT too, but are more focused on business people that need to get business done rather than IT who are in the business of supporting business, i.e., they are more usable for non-IT business users.

RSSBus. Just go and have a look, they do a great job of splainin' (explaining) what they do. Basically, you take data from all kinds of sources, aggregate it and create new scripts to act on it, and you can do this recursivley; building up your own catalog of feeds and scripts and using those provided by others. Of course, you are encouraged to submit yours for use by others. Great way to pull all the data you need in one place with a very easy toolset. Kudos to the RSSBus team! I will have more to say about this technology in the future too.

You can combine RSSBus and ActiveGrid in many complimentary ways.

Another technology I wanted to mention is OpenKapow. They claim "mashups in minutes" and its very accurate and true.

There are also Yahoo Pipes and Google Gadgets.

There are some overlaps in these and complimentary combinations too. Please let me know if you are using any of these and where, or if you are using other Web 2.0 tools, I'd like to learn about what else is out there. These are the tools that I would look to use if I was in charge of IT direction at any company. I'm sure there are many others...what they all have in common is simplicity and utilization of core technologies available to everyone on the Web.

Now have a look at what some IT industry heavyweights are proposing for business application development: big, complex, costly and heavyweight solutions that are so last century. I noticed that many of the products of these large vendors are consistent with their own size and complexity, the bigger the vendor the more complex their solution strategy it seems. There is an easier, faster and cheaper way to provide technology solutions to business, its Web 2.0. So easy its almost magic ;)

Thanks for reading

The Complexity Proponents Run IT

2007-04-30T12:53:00.000-05:00

Its been a busy two months since last I blogged here. I've been working with several Fortune 100 companies as usual (yes well within the F 1000) and the complexity mantra was reinforced again. Why is it when faced with complexity the response is often more complexity? Complexity to fight complexity?! I confess that I don't get it, there may be some organizational psychology or sociology that can explain it, to me its just plain idiocy.

The challenges and problems facing large IT shops are difficult, varied and complex but not insurmountable, unless you don't have an organization equiped to handle it. Unfortunately, as is often the case, most organizations are not prepared to change their thoughts and approach. They will choose complexity. Adding more compexity to meet these issues is not the solution. Most IT solutions are needlessly complex, insufficient for their purpose, difficult to change, manage: overengineered. Instead of overengineering, design in cost effective change enablement and empower end users. (this will be a future blog topic I'm sure!)

There are simple approaches and technologiess that can help, but those aren't used. Instead, the enterprise IT tool of choice is SOA. Complex, standards bound, political, expensive...you name it, it is complexity to solve complexity. Now, I think SOA is good, valid approach however in the hands of the typical enterprise IT shop it quickly gets mired in politics and complexity. Heterogenous IT shops with their various factions, will dilute, fragment and fracture SOA to the point where it will fail to deliver. In practice, SOA's core simplicity is lost, and its complexity becomes the sustaining driver. Each iteration within the political and architectural circles of the enterprise makes the situation worse.

Meanwhile, there's Web 2.0 and simplicity available. It is so comparatively easy in fact, I think that is why it isn't going to be adopted by many IT shops. If its that easy, who needs all these cost-center employees then? IT departments want to simplify but they can't actually bring themselves to actually do it. If and when an IT shop actually does apply easy-to-use technologies successfully, they will be in a position to out manuevre their competition.

Where do you start? Get a Web 2.0 team, from outside, and have them perform a bake-off with your IT department using their tools and technologies. When the Web 2.0 team hits it out of the park, ask your IT department what their problems are, and listen for the excuses. None are valid, it is purely self serving, self protecting doubletalk. They used complexity to address complexity, and that approach failed outright, cost more and underdelivered or some other partial success story.

Is Web 2.0 perfect? Absolutely not, but its premise is based on simplicity and high value. Used with sound (not old school complexity) architectural principles and design aesthetics that focus on simplicity of form and function, Web 2.0 will be better, cheaper and faster than anything the compexity proponents can provide.

How well did your organization adapt to and adopt Web technology (aka Web 1.0)? How about CORBA and/or DCOM? OO? If you didn't get the value you expected from these, you will likely not get the value from SOA you anticipate. What to do?

Go Web 2.0, of course! You need the right team (beware, they could be complexity mavens in disguise!), that can effectivel leverage the tools and technologies that are available in a blend of art, science and engineering simplicity and economy.

Well, what's to worry? Your organization won't do it (no real incentive) and your competitors won't do it either, so you'll all use the status quo vendors and technologies, employ high-cost complex technologies and IT experts and complain or worse offshore to lower the costs (and increase complexity again). Remember:

"Insanity: doing the same thing over and over again and expecting different results."
- Albert Einstein

So, is your IT approach insane? If you are a large enterprise IT shop, the answer is probably Yes!

REBOL 3.0

2007-02-07T22:12:00.000-05:00

It looks like REBOL 3.0 will be here soon!

First, there is a high-level component architecture overview document here...

... a list of 2007 priorities here...

...and if you follow the link to the REBOL Developer Conference, the program states "Introducing REBOL 3.0" by Carl Sasserath.

Can we hope to see REBOL 3.0 released and available this summer? I can't wait!

Good for you, not for me

2007-02-07T10:22:00.000-05:00

Now I'm a big Steve Jobs and Apple fan, but I'm not a fan of something that appears to be hypocritical. I ceratainly don't like "Hollywood" and the rest of the entertainment industry at all, but that 's outside this topic.

Steve's recent open letter on music calling for copyright holder to eliminate DRM is interesting. So Steve, the record companies should eliminate DRM and allow music to be shared and copied however consumers wish? How about Apple doing that with Mac OS X Leopard, let consumers install your OS on any machine they want and as many machines as they want, or even share their copy of your OS with their friends and families? Sounds like "do as I say, not as I do".

I have a few Mac's, can I go and buy one copy of Leopard and install it on all of my Macs? I have a few Intel boxes running Linux, can I install Leopard on them too, using my one copy? I have friends and family that would also like to run Leopard, should I let them use my single copy that I paid for? Of course not, I'm not allowed to do that. Apple would see that as a breach of contract or violating their ownership rights or something of that sort, that is, it is not legal for me to do so. In fact, even if I purchase a separate copy for each machine I own, it is illegal for me to install Mac OS X on a non-Apple machine.

Tell us why should any digital content owner (movie studios, music labels and other publishers, etc.) allow someone to buy their content once and copy it anywhere and everywhere, to any / as may devices (e.g., computers, mp3 players, phones, PDAs, etc.) and share it with anyone they wish?

When Apple relaxes or eliminates its software digital rights, its licensing and usage requirements and constraints on its software (not just the OS), then they can take the "moral" high-ground position and ask others to do the same, not before.

So Steve, when do you plan to allow consumers unlimited copy and unlimited use digital rights for each single copy of Apple software that they purchase? When will consumers be allowed to install Mac OS X on non-Apple hardware?

Enterprise Open Source

2007-02-02T09:30:00.000-05:00

I've been collecting an ever growing list of open source offerings that have applicability to enterprise IT. I am convinced that with the right guidance, most enterprise IT shops can do at least ~80% of their IT with these open source offerings. While many of these fall short when compared to their commercial counterparts in terms of features, they still offer a viable alternative for IT organizations with the requisite in-house skills (real programmers; real software engineers).

Let me define "the right guidance". That is someone or some team that can see the value of the Web 2.0 approach to software creation and utilization. A former colleague of mine used to say. "a fool with a tool is still a fool" - if you don't "get" the premise of Web 2.0, if you don't "think" in terms of Web 2.0 or "believe" that Web 2.0 works, then why would it work? The peer-to-peer approach offered a similar opportunity, unfortunately the underlying technology model of p2p was mistaken for the high-profile illegal use of the technology to steal copyrighted content. I worked in p2p for a few years, and was dismayed by the number of people in IT that said, "P2P, isn't that illegal?" What!? (This is similar to the arguments against private gun ownership, "criminals use guns to commit crime, then we must ban guns" Duh!? No incarcerate the criminal is the answer to the actual problem. Remember, "Guns don't kill people, people kill people"!!!)

The feature set is one area, perhaps the most convenient argument open source opponents use; its right up there with the legal / licensing / indemnification "concerns". There are open source integrators that will build, certify and often indemnify an open source suite. So what is the real issue?

The real issue is that it will destroy the kingdom of IT, large numbers of top-heavy management, architects and adiministration overhead (not sys admins, they provide actual value to an organization). If you can find, download, learn, extend and deploy open source solutions to service your customers, employees, partners, execs...why not do it? Using open source will allow organizations to downsize their IT especially in the "deadweight" category. All the money saved can be used to hire real software engineeers and real programmers (there is a difference, which I may blog about eventually).

In applying open source, Web 2.0 solutions in the enterprise (Enterprise 2.0) you will need a few knowledgable business analysts, a small number of tech savvy managers that still have to write or test software themselves, software engineers, real programmers and system adminstrators. Essentially, that's it! For senior management: a CTO and small staff of software engineers that can assess technologies and trends. There are many tools emerging that will enable the end users to have more control over the software systems they use to perform their jobs, they won't need IT to do "requirements analysis" and "BUFD" with heavyweight technologies. Notice there is no CIO position, they are extinct.

If you have a typical, traditional enterprise IT shop of say 100 staff total, I would be surprised to learn that more than 30 actually did anything to create real value (real value: investigate technology, assess needs, write code, test code, admin runitme environments), let's say its 50 or 60 out of that 100 total. Eliminate 40 non-value producing positions, maybe create 5-10 new value producing positions (CTO and advisory staff) and provide better end user experience, cheaper and faster?! What's that worth? You flatten the IT orgainzation with fewer layers of political indirection, make IT more agile and more supportive of your organization's business objectives.

One caveat, having real software engineers and real programmers you will need to have technically competent, motivated leadership (CTO and staff) to harness and focus the creative energy. Clearly defined business objectives, ample time for creative exploration (10-20%) and effective n-ary collaboration and communication is all that is required. (That and good, fast, machines from any manufacturer they want, with big/multiple monitors, a break room with tv, pool (swimming or table!), pingpong, foozball, air hockey, and good coffee, tea, softdrinks etc.) You'll still save money right off the bat, and on an ongoing basis.

There is a better way to do Enterprise IT, for those willing to "risk" it. You can start small and evolve, it doesn't have to be a violent overthrow though the start small team will have many enemies circling like vultures, so executive management (CEO and staff, minus the CIO) will need to protect this team. Those organizations that follow this path will win competitively. Google, MySpace, YouTube are but a few examples of how to do it the Web 2.0 way. What's stopping you?

Take a REST from the SOA standards insanity

2007-01-29T17:14:00.000-05:00

Every day it seems, I become more RESTful. As I look out over the ever increasing morass that are the SOA / web service standards, emanating from a plethora of standards bodies, consortia and vendor alliances I often wonder, when the complexity mavens will cease complexity expansion. Unlike global warming, this complexity is man-made.

Having worked in and continue to work in SOA, EAI, JavaEE, CORBA and other distributed solutions and technologies for many years, thre is one thing these all have in common: All have suffered from design-by-political-committee aspects and/or complexity which limited their usage and market growth potential. What has the IT industry learned from these efforts?

Well, I learned and experienced and still live in this morass filled enterprise SOA world. Unlike some, after I learn and experience, I like to improve, I like to simplifiy what I have learned and experienced, so I thought: how may one make sense of all of these past attempts, from all these growing numbers of standards and technologies for web computing for business, government, science and more? How may one separate the necessary from the unnecessary? How can one do SOA in a simplified manner? What are the basic elements required to enable SOA, b2b, m2m, s2s, c2b, c2c, etc., in a scalable, fault-tolerant, manageable manner with dynamic discovery, production and consumption? What is a viable, basic, simple model? One doesn't have to look too hard to see examples of a simple successful model for SOA web services, but one needs to know the real / actual from the mere usurpers of the term who often live in marketing... the simplification? Web 2.0.

I won't provide definitions for SOA, Web 2.0, REST, etc., those are all over the web. What I want to do is look at where SOA/Web Services emerged and where REST / Web 2.0 emerged, just a comparison that I hope will show the utter futility of one approach that is destined for limited success like many of its enterprise predecessors until it collapses under its own weight and complexity vs. the simple, lightweight alternatives that are providing value now, at much lower cost of ownership, and continue to grow their value proposition exponentially! This is just a stream of thought. You will notice that I am a firmly convinced proponent of REST and Web 2.0 approaches, though I still work in a world dominated by SOA web services and the never-ending standards explosion, so here I vent:

Let's start by abstracting and describing the basic problem model. First, let's divide the web world into two roles: Consumers and Produers. Next we'll divide this world into two perspective or approach camps: Simple and Complex. For each role, either perspective or a combination, may be used. This combination is happening on rare occassions, invariably though the complexity takes over.

Consumers and Producers

The web world is divided into producers and consumers, though these roles may be, and are often, dynamic and reversible, depending on the context, i.e., a producer may also consume and a consumer may produce information in a given interaction. For example, when one uses a search engine one enters search criteria which is consumed by the search engine, which produces results to the requester (the original consumer) who consumes the response.The search engine consumed the request however the search engine may use the original search request and subsequent selections to do more than simply create a search response, it is, in effect, consuming the request which will assist its production / servicing of future requests. By providing value to consumers, the service provider also receives value from those who consume its services.

Producers produce content or information that some consumers may want to consume. So producers need to decide what they want to produce and how to let potential consumers find and consume what they produce. Producers typically produce information with a goal that their information be consumed so they must find a way for potential consumers to consume the information they produce.

As a producer, or service provider, I need to let potential consumers find me, to learn about what information I produce and what I require in order to produce the information. For example, if a producer offers to provide a stock quote, it should tell potential consumers that fact, as well as what consumers must do to get a quote and what that quote response will look like in form, content... Provide a valid stock symbol perhaps, a currency and maybe a stock exchange? What are the defaults and acceptable values? Does the Consumer get back a dollar amount? Are these delayed or real-time quotes? Are there charges or disclaimers, etc....

Consumers need to be able to find producers that produce the information that they are interested in consuming, understand the requirements for consuming a producer service, expectations and the terms and conditions of use, etc. and the format(s) for the request and response supported, required and offered by the producer.

So far this is simple, there are plenty of web sites that provide static and/or dynamic content, aggregator web sites, web services that provide content / information and mashups that combine and consume the products of multiple producers to provide a new whole...then the complexity can start in, if one is so disposed to allow it.

Sometimes the interactions between consumers and producers have formal definitions, possibly one or more alternatives. For example, a producer may provide a URI to which one may simply send an HTTP GET, or have a description that describes how to format an HTTP POST request or maybe it is an RSS or ATOM feed at this URI, maybe its more formalized....you may have a set of parameters and values, or an XML document described by XSD and/or where you need to authenticate via HTTPS or maybe its a SOAP endpoint whose address is defined using a WS-Addressing endpoint reference, whose operations and requirements are described in WSDL, according to WS-RF or WS-Transfer or both via WS-Resource Transfer (are you with me on the growing complexity?!) with a formalized SLA defined by some other standards, with transactions defined by other standards, with parameters and formats defined by several schemas and namespaces and resources and .... and.... and...Whew!

Now, I'm all for consistency and clearly defined descriptions, definitions, formats, etc. but at some point all this complexity adds up: adds cost, reduces performance, increases error potential, becomes more difficult to use, etc. all of which overshadows the whole reason why a consumer may have wanted to consume the producer's product in the first place....to get something of value done. That value may be profit, learning, etc., but it is useful work. If I have to put a dollar in and my ROI is twenty cents, why would I do that? That's like making charitable contributions to the Red Cross where much of what you donate goes to pay top executives, not to the people who actually need it, you know the one's you're making the donation to help!

So, why work so hard and get back less value than you put in? If you go down the standards-based SOA web service path...well, there you are and there goes your ROI!

If you want more consumers to consume your produced products, you need to provide access as easily and cheaply as possible... so that it is consumable by more consumers. it goes without saying that your information product must be accurate, correct, precise and valid! If your producer is not easy to use then someone else will provide a product that is better, cheaper, faster and/or easier and get used by more consumers....if a consumer needs a CS PhD to use your producer, to consume your content, well there are fewer CS PhD's out there than entrepreneurs, high school students, Moms, Dads, Little League teams, and small businesses and other types of information consumers...you need to make it easier for anyone/everyone...so 3 simple rules

Rule #1: Simple is Better than Comlex. Always.
Rule #2: Simple does not imply less rigor, just less work i.e., work smarter not harder.
Rule #3: If its getting more difficult or complex you are probably doing something wrong (or you have a CS degree and just can't help yourself. I have a CS degree and I often need to remind myself of these rules!)

Perspectives: Simplicity vs. Complexity

Survey the Web. Look at all the most successful information producer / consumer / mashups out there and see what they are using, what their technologies are, where the information they consume comes from and the form of the produced/consumed information. Now, look at what enterprise IT shops are doing, just do a search on jobs for “web services, SOA, architect, enterprise” or look at IT job posting for the Fortune 1000 companies...better yet go read some specs at oasis now put these specs to good use in a simple, easy to use (produce/consume) solution.

What you will find are the two basic camp mentioned before, that I call: 1) the simplicity camp and 2) the complexity camp.

First, I'll describe the complexity camp: Many in the complexity camp work in enterpriise IT. The complexity camp is exemplified by / are big companies with big IT budgets and staff that do much processing over the Web, both internally within their organization and externally with customers, partners and suppliers. They have a lot of legacy systems made up of all those prior technology efforts that linger on, seemingly forever...there is never time to do more than keep them on life support so they in turn continue to provide a source of complexity that grows over time. The complexity camp likes standards. It likes standards so much, that it wants lots of 'em. Closed, old, new, contradictory, overlapping, vague, constrainging and open standards. All these standards then require complex products that are used to create solutions using all these myriad standards. Many of these standards have alternatives from other standards bodies that do some of the same and some different things, so you need people on staff to help you navigate all the different standards, their status and their future direction and to provide coordination of all these standards, etc. Once you have that figured out, you'll need to add your own corporate, division and area standards and interpretations, maybe some SixSigma or other fifth element processes and procedures, and of course more staff to oversee this too. Next, you'll need to have some heavyweight tools to develop solutions using all these standards too. Yes, there are some open source tools and technologies you can use, but to be most efficient you'll probably need to buy some commercial tools too, and these will cost you time and money, maybe small money, maybe big money...it all depends...on what you want to do, and how, and why and how frequently, and other factors. Then of course, you'll need weeks of education to learn how to use those tools. Finally, you are prepared to develop your customer solution. What were those requirements again? So the complexity camp is often found in traditional, enterprise IT staffed with the alchemists of the BS in CS variety where: Complexity is enterprise IT's rationale of existence; just business as usual.

Ask any CEO or business executive if they would be interested in reducing the overhead, costs, size, etc. and/or improve the responsiveness, ROI and effectiveness of IT. Care to guess what their answer may be? And so many people in IT wonder why IT is being outsourced and off shored? Hello! Hello? Anybody home?

Like so many human organizations, that become self-fulfilling and self-sustaining, carrying on the work, form and vestiges of the past long after it ceases to be required... non-profits to cure incurable diseases, civil rights organizations that now advocate for preferential treatment rather than actual equality, etc., Not all, but many IT shops are like this too. Most enterprise CIO's and IT shops are like dinosaurs that haven't realized they are extinct! Case in point, what enterprise IT shop has had to deal with the growth rates and capaciaty expansion experienced by inventors / practitioners of Web 2.0 concepts such as Google, YouTube and MySpace? Few if any! Nor could their IT shops assimliate such growth / speed if they had to! They would collapse! Case Closed.

I make no attempt to hide where my sympathies are, just look at the reality of the Web today, who are the players, the movers, the shakers and the leaders? Web 2.0 companies! The Simplicity Camp is the only realistic, practical and pragmatic way to go if you want to provide viable solutions in a cost effective manner.

The Simplicity Camp

Tim O'Reily initially defined Web 2.0 and many others have adopted and expanded the concept, much is being written about it and more importantly, much is being done with it now, today!

Driven initially by constraints (money, time, other resources, etc.), the simplicity camp looked for alternative ways to approach the problem of web computing, doing more with less. Tried and true technologies of the Web such as HTTP, HTML then XML*, XHTML, etc., low/no cost such as open source software stacks such as LAMP, MAMP, SAMP or even WIMP, then more open source emerged that could assist the simplicity camp, simple more efficient technologies and approaches often based on the tried and true technologies of the Web: HTTP, URI, XML, Namespaces --> and a seminal dissertation by Roy Fielding ---> REST and with the advent of WEB 2.0 a new, more simple way was defined.

The emergence of complementary technologies such as RSS/Atom, Wiki's and AJAX, and producer services available from some big companies in a simple, consumable format i.e., one did not need to have a CS degree and arcane alchemic knowledge of SOA web services, i.e., SOAP, WSDL, UDDI, and more WS-* specs, standards in order to consume these offered services from Google, Amazon, Yahoo and many other well-known industry giants. In fact, more consumers consume information from producers using plain old HTTP GET/POST, REST and/or Web 2.0 than via the standards based, enterprise SOA Web Services. Recently, I heard Google was "sunsetting" = phasing out, its SOAP API for search in favor of an AJAX API (AJAX is a cornerstone Web 2.0 technology which has been so successful that commercial and open source vendors of web services based SOA products have added it to their products! Wonder what that really says?! )

While the standards morass around web services based SOA plods along meandering down its many political paths, the REST / Web 2.0 proponents are providing simple, elegant solutions that enable the web for all to consume, produce and more.

If you're in an entrprise IT department doing SOA and Web Services, and "Enterprise" and/or "Architect" is in your title, you need to have a look around outside your walled garden.

Which camp are you in?

Whither AI?

2006-12-06T15:21:00.000-05:00

I took a few classes on AI back in th '80s, and did some prolog, lisp, expert system, neural net and genetic algorithm work in the late '80's and I've been hooked ever since. (I also recently did work on mobile, intilligent, multi agent systems for which my employer submitted patent applications. But Agents are another blog topic!) Something about software that seems to reason, seems to "analyze and think", derive solutions, adapt, work with incomplete information, refine, etc., is intriguing. I had a professor that said the best form of enterprise computing was batch processing (at that time interative systems such as TSO, CMS and CICS were significantly more expensive than batch). When asked why, he said, "because there is little or no human interaction involved. and people, especially skilled people, are expensive." batch systems processed data unattended eliminating many human jobs (long before the term IT was commonplace, it was known as DP - data processing). Automation was a key objective in Data Processing. I spent many early years in my career automating and maintaining automation. You don't hear the terms automation or data processing mentioned much anymore, no less a key objective.

Unfortunately for automation proponents in the DP days, not everything would lend itself to automation with the technology of the day. Knowledge Workers - workers who had knowledge about the business - were skillled resources who were expensive to develop and to maintain. If only there was a way to automate the thought procesesses of these knowledge workers. This is one of the key business drivers that enabled the AI wave in the '80s.

Essentially, the processing power was not available at a price point to allow AI to deliver on its promise, so the AI bubble burst. I have an issue with the position that "AI failed to deliver on its promise", while it may not have lived up to all the marketing hype (what technology has?) it did deliver much promised value. I know because we dellivered working expert systems, GA, and neural net solutions, however with the "enterprise" thinking of the day ("bigger is better") solutions did not come cheap. Nor were they easy to implement due more to corporate politics than the AI technology of the day..

My first commercial expert system was developed using Borland's TurboProlog (Released during the reign of Philippe Kahn and it is now at PDC) which, I think, was $99 a copy at the time! Now if you had Prolog developers, or hired them, how is this not cost effective?! Noooooo, we had to buy a multi-million dollar expert system monstrocity that probably cost 7 figures to acquire and more to run (with mainframe components) annually, not to mention the runtime fees (anyone else remember runtime fees?!). It wwas also harder to use than writing solutions in TurboProlog. Gotta love those "pointy-headed" bosses and decision makers. That's when you realize some organizations just have too much money to burn. They could have spent a fraction of that using us "knowledge engineers" and TurboProlog to do expert systems. All of us had mainframe experience, we could have made it work with the mainframe or the VSAM files, IMS and DB2 systems - and for much less!

My first neural network application consisted of a bunch of ANSI standard C code shareware and a now-forgotten ANSI standard C compiler, which I used to create a POC. When we did RFPs to neural net vendors of the day, the price tag was $600k+ for development + runtime fees + transaction fees (anyone else remember runtime fees?!). I had a low-cost alternative using NeuralWare (thankfully, who is still going strong! great products IMHO!) for 2 developer seats, and code generation, training for 2, etc. which would have enabled us to do our own neural net solutions for a start-up price of about $20k. When I stated this, my "pointy-headed boss" at the time got angry at me and the fact that my total estimate was about $80k to do the solution in-house. The fact that I was able to demostrate success with shareware was not a welcomed fact either (the POC success was what lead to the RFP to vendors in the first place). It was possible to deliver cost effective AI solutions in 1989-1990, if you didn't have a pointy-headed boss! Why they paid us "Knowledge Engineers" to be Knowledge Engineers and to do knowledge engineering, yet actually "green-light" very little of what we did for production I may never know, but at least I had fun and learned much.

Fast forward to today: AI has really made a strong comeback and is being used in many solutions and many domains. You can find freeware, shareware, open source for just about any AI sub-genre. So if it is so available, where is it in the enterprise? Unfortunately, mainstream enterprise development has yet to make AI a visibible part of their solutions. Short of a few autonomic computing, operations management, BI, analytics and rules engines, very little AI is mainstream (Yes, outside of gaming I mean!). Now we also have the open standards, networks and low-cost compute power to really apply AI in a cost effective manner. Why we don't build intelligent software as a matter of course in enterprise development is another mystery. I think this is due, in part, to lack of awareness. If your CS program even had an AI course or concentration in the last 10 years would be something (I don't folllow current university curricula, so I could be mistaken).

Over the years, I have had the opportunity to mentor younger/junior programmers, designers and architects. The few that I considered to have the "right stuff" (and worth the time) would often ask advice which would often lead to the topic of AI. I encourage those who joined the IT ranks after ~1995 or already knew about Java before graduating, to look at all the old (and new!) books, papers, conference procedings. languages, tools, etc. on AI theory and practice. Many of these sources are freely available on the Web. Be aware, learn AI and apply it to enterprise solution development. The time for mainstream intelligent software is long overdue.

Let me know if you are doing or applying AI in an enterprise, commerciall setting...I'd love to hear about it and hopefully others would too! Whither AI? Everywhere.

REBOL, REBOL, Waiting for REBOL 3.0!

2006-12-05T22:58:00.000-05:00

If you haven't heard of, or tried, REBOL you should have a look. What it does, and how easily it works is just amazing. The size:power ratio is incredible. This is the way much business computing could/should be done. If you are a SMB (small to mid-size business), you should consider REBOL (large enterprises too, but then the beauracracy and politics would probably be problematic because REBOL can actually help your organization!).

I've been dabbling with REBOL for the last few years. Based on my experience with current and prior versions, the next version, 3.0, promises to be even more amazing. So, Carl I'm waiting patiently for version 3.0, please update the timeframe estimates!

I plan more blogs on REBOL in the future. It is a key tool in my personal toolbox. REBOL is different, innovative, simple, elegant and powerful: all things I like in a programming language, and it is more than a programming language.

Disclaimer: I don't work for REBOL Technologies nor have I been compensated to endorse or develop REBOL solutions. (I am interested in REBOL solution development opportunities. If you are a SMB and in need of enterprise software solutions, let me know.

Web 2.0: The new RAD

2006-12-05T18:33:00.000-05:00

Web 2.0 is a great concept. If you take what I consider to be the seminal, definitive and diffinitive definition of Web 2.0, a key aspect is the coupling of data and processing logic...an extension of object-oriented concept of encapsulated state and behavior.

Other interesting aspects of Web 2.0 are also similar to aspects of the RAD trend in the 1990's Client/Server era. Many of the Web 2.0 vendors are enabling a web version of RAD - a RAD for Web Applications (RAD4WA) or Rapid Web Application Development.

Even though they dropped support of the Mac version of their tool :( , when it comes to Web 2.0 application development I like ActiveGrid. One of the first things you'll notice about AG is that nearly every artifact is represented by some open standard; the rest are open scripting language artifacts or represented by an XSD. Developing a Web application integrating web services and databases is simple. straightforward and quick.

Another brilliant move by AG is their server model. I can only imagine the discusion that lead to their server design: we don't want a cluster model, we want a grid of low-cost, commodity processing nodes (LAMP stack servers) that will provide enterprise scalability, fault-tolerance, etc. The big vendors are spending huge amounts of money to develop grid / utility computing, what will we do? What does nearly everyone have, or at least have access too? Apache Web Server. We'll write a grid module for Apache. Absolutely brilliant: simple and elegant.

Finally, AG lets you use any/all of a myriad of scripting languages and/or plug-in your own. If you are interested in Web 2.0 or developing Web 2.0 applications AG is worth a look.

Back to RAD...
RAD worked well. We were able to offload processing from expensive mainframes onto low-cost PCs and Unix boxes (where the databases lived). For the most part, the RAD solutions were primariliy data presentation and data entry with input validation (sounds familiar to what most commercial web sites provide, no)?

RAD tools and solutions had their issues and limitations too. They worked well for a certain class of applications where the business logic was not overly complex; they didn't have separation of concerns (e.g., MVC) which was invented and lived nearly exclusively in the Smalltalk world, as did much of the design patterns back then. As complexity rose and maintenance cycles accrued they became very brittle and difficult to maintain. Not to mention they were proprietary.

During part of the RAD era, I worked for a Smalltalk vendor named Digitalk, Inc. Unlike most of the RAD tools of the time, our's was based on Smalltalk. The RAD tool was called PARTS - an instance based RAD programming tool. That is, you build your Smalltalk classes as usual and used PARTS to create instances of any of the classes in your image and knit them together into an application. You could even combine instances into a component (called a Part), that you could save in Parts catalogues and reuse in other applications. Very simple and powerful. PARTS, though standalone too, was part of Digitalk's Visual Smalltalk Enterprise - IMHO the best enterprise C/S RAD toolkit available at the time. What Digitalk VSE was to C/S RAD, I see striking similarities to what AG is to Web 2.0.

It remains to be seen if the Web 2.0 application development vendors can provide more than Rapid Web Application Development and deployment tools. I think some can, are and will. I've picked my winner, what say you?

Web 2.0 is RAD for the Web. I hope it goes better this time around!

Disclaimer: I used to work for Digitalk, Inc. and I have a fond nostalgia for their products. I do not work for ActiveGrid nor do I have any business relationship with them. But if you are hiring or planning for an ActiveGrid project, please let me know. We should talk!