Gartner AD Confrence Tracks

The Gartner Applicaiton Development confrence was devided into 4 primary tracks:

1. application life cycle for SOA
2. AD resource management
3. modernization and integration
4. AD governance and control

This is a pretty good deliniation of the industry if you accept the SOA pill. Specifically SOA presents new demands on application development both in how applications are developed and managed, how existing assets can be leveraged, new roles required, and environment challenges like SOX and ever increasing security threats.

First an ambient orb now a lava lamp

we may well need to implement this....

Gartner AD summit arrival - non technical

The confrence is in grapevine TX, right near Dallas.

As my wife is joining me on this trip we decided to fly into Austin and drive to Dallas. I lived in Austin for a whe, andwanted to sow her some of my old haunts.

We were unable to carve out much time for Austin, and rain dampened some of the experience, but I was able to show my wife enough she'll be eager to go back.

If you get to Austin:
Rudy's BBQ
Oasis on lake travis
6th street at night
4th street too
hills on north Austin (arboretum area).

I also will be looking for a chance to get back to San Antonio.

The drive from Austin to Dallas was smooth, although there was an accident requiring 2 medivac helicopters, which had I-35 shut dow both ways for a short strech.

The confrence is at a very nice, and huge resort and convention center; the Gaylord Texan.

Gartner application development summit

This week I'm attending the Gartner Application Development Summit, and Enterprise Architecture Summit.

In 2003 I attended the Gartner Application Integration and Web Services summit.

Over the next few days I'll be posting both current messages from my attendance, as well as changes from what I remember. I'll also give some personal experience and perspective.

Tit-For-Tat - Small Ad

Not as good as the big ad, but I appreciate the parody.

The Bus Stops here

Phil Wainewright has some excellent points here. The premise of an ESB is the real question isn't it?

If ESB is a package, and that package is designed to enable SOA and merely to be more standards compliant and less costly than traditional EAI then yes the emergence of WS-Relability and WS-ReliableMessaging will reduce the need for a packaged ESB.

However if you consider the ESB to be a SOA pattern, and ESB vendors offering an implementaiton of that pattern, then the ESB is just fullfilling its own promise. The promise behind a standards based pattern is that certain implementation aspects will be driven to be commodity, and vendors will need to innovate to differentiate their products as they recognise each layer of the ESB should be swapable for the best of breed providers solution.

Further, custom adapters will not go away anytime soon, there are a multitude of proprietary legacy systems that adapters are the only connectivity and EAI vendors are the niche players.

Additionally if you consider ESB as a pattern, then it is very acceptable to have a few implementations of that pattern and federate accross them (its part of the pattern). The standards provide the glue to integrate and federate an set of ESB's.

Continued standards development is key for driving the ever increasing value of SOA-enabled enterprise, and those enterprises at the bleeding edge are realizing the ROI to justify some level of errosion of competitive advantage in trade off for standards that enable further competitive advantage development.

So its not the end of the road for the service bus, the bus just got a new paint job.

Microsoft Position on ESB

Another point from the aforementioned paper is that ESB == EAI.

To some degree this is true, but ESB is actually the evolution of EAI concepts.

To say you are using EAI technologies does not imply SOA, nor does it imply standards based connectivity. It does imply advanced messaging capabilities, and brokered communications.

An ESB implies security, standards based connectivity, as well as service registry and service mapping. These are what differentiates an ESB from plain old EAI.

The current SOA and ESB movements don't claim to do anything new, but rather evolve best of breed architectures that have been used in the past, while reducing barriers to entry and common failure factors.