Skyway Software, the expert in simplifying software delivery, is listed as a key Composite Application vendor in Application Architecture, 2008, as published by Gartner in their annual Hype Cycle report. This Hype Cycle report covers a broad collection of Web 2.0, cloud computing, and service-oriented architecture technologies and methodologies and provides Gartner’s predictions for the most important technologies during the next 12 months based on several key technology characteristics, including maturity, adoption, and impact.      

According to Gartner, composite application techniques and methodologies will see mainstream adoption soon (many already are here, including Skyway Builder) and their business impact will be high.

“Our listing in Gartner’s Composite Applications category highlights our expertise in model-centric delivery of Rich Internet Application and Web Services,” says Sean Walsh, President and CEO of Skyway Software, “and our customers, including TDAmeritrade and Landesbank Baden-Wurttemburg, currently use Skyway Builder to develop, test, and deploy new applications – and to extend existing applications – more quickly and more accurately than ever before.”         

Once again, we are very pleased with Gartner’s ongoing recognition of Skyway Software.

Rather than comment too much, I suggest you read the BCG paper for yourself.  Suffice to say, though, I think we are on to something here with our model-based, iterative approach to fast, accurate software development.  And it seems like yet another top tier management consulting firm agrees.

Speak with you soon.  DC

It is always amusing when many stars align to make a point.  Maybe that Carl Jung guy was on to something.  The latest one of these pain points that has occurred to me is around ivory tower architecture teams.  When I talk about such a team, I am specifically referring to groups within an organization that plan the architectural direction for the company and yet are not involved in the day to day delivery of any major systems.  Several of the stars aligning for me to punctuate this problem are the blogs from David Linthicum around “Bad SOA Consulting” and a few meetings with just such ivory tower architects.  As David rightly points out, bad consulting and bad architecture is a bane of SOA.  I see the problem as an even broader stigma affecting all of corporate architecture, it is not just focused on SOA architecture.  Architecture is a critical part of building a successful IT shop, bad architecture can cripple an IT organization’s ability to deliver.

I always find such architecture teams that are not doing any real solution delivery quite amusing.  Only in IT do you really see such a crazy thing as non-practitioners dictating function.  In science, the equivalent of the architecture groups are in the lab, performing experiments, testing their hypothesis, proving out their ideas, and going through peer review before others pick up those ideas and start running with them.  Medicine is similar, lab trials and clinical trials precede actual implementation.  Can you imagine if the medical field functioned like IT?  They would draw a little blood, do a little lab work, then lay out a plan for a brain transplant.  Yet, somehow, IT has latched on to exactly this organizational structure.

Softballs are still part of the ivory tower.  If the architecture team is setting up trial apps and new green field apps and then dictating architecture, then they are part of the ivory tower problem.  Try applying some new architectural direction to a real solution if you do not understand the difference.  When you have the business owner breathing down your neck, end users changing their minds on what UI they like, multiple internal systems to interact with, developers struggling to learn a new style and trading partners to connect to – then and only then will you have a real idea of how an architectural decision will play out in the field.

The best architecture groups are not dedicated architecture teams that function in a lab and hypothesize - they are practitioner architects.  Groups where the architecture direction is set by an architecture team made up of architects that are assigned to real projects and making day to day decisions around taking systems live.  They are not cursory members of such system teams, they are critical players.  They still need to be architects, but they need to constantly be experiencing the pain of delivery.

Bad architectural decisions that are forced on the field are either going to collapse after wasting time and money, or the teams doing the delivery will ignore them all together.  Either way, the critical architectural decisions needed will not be made.  Ivory tower architecture teams are infinitely more likely to make bad decisions since they are not feeling the pain of delivery.  Sure, most architects come with a history in delivery.  But IT changes, business user expectations change, developers move on, all at an ever increasing rate.  Even with decades of experience, leaving the delivery cycle for a year and an architect will not be as effective or in touch as one consistently in the cycle.

In a recent post from Michael Krigsman, he describes a potential doomsday scenario about the new Boeing 787 Dreamliner.  Apparently, passengers with inflight Web access also receive the additional benefit of unfettered access to the plane’s navigation and communication systems!  Talk about a massive rework effort.  And I shudder to think at who will absorb the cost overrun.  Aerospace manufacturers rely on prototypes to avoid such massive errors, but obviously, they still occur.  And the real sad part of the story is that they have no fast way (probably) to correct this error.

In a parallel software development world, we are big proponents of prototypes, too, especially functional prototypes, to capture these types of design flaws early in the process.  Even so, errors still are identified late in the development cycle.  But with todays model-based code generators, such as Skyway Visual Workspace, these late cycle changes can be handled much more effectively.  Software applications are built according to industry standards and utilize data models, logic models, and Web models that can be redeployed simply and quickly to account for any type of design change.  Then at the click of a button, the models are deployed and the code generator develops the deployment scripts.  The immediate result? 

A new version.  Fast.  And accurate.  And a much different planning conversation than Boeing Managers probably are having these days.

 Speak with you soon.  DC