Do you follow the trends?  While Java still holds a commanding lead in the general-purpose language, its important to note that specific-purpose languages (such as Ruby [read: domain-specific language) continue to grow in importance and relevancy, as shown below.

Why?  Because flexibility and customization still matter – a lot.  Read our take on the importance of DSLs for delivering RIAs and Web Services here and here and here!  And let us know what you think.

Speak with you soon.  DC

When you mention the word UML in software development circles you usually get a reaction.  These days that reaction is mostly very negative. 

I recently came across a post by Steven Kelly regarding the demise of UML.  Steven’s post is related to the release of a new book “Domain Specific Modeling: Enabling Full Code Generation” he co-authored with  Juha-Pekka.   The book is an excellent discussion of using Domain Specific Models (DSMs) to create Domain Specific Modeling Languages (DSMLs) to achieve an order of magnitude increase in software development productivity.  The book also does a very good job of highlighting why UML can never be used effectively to build software and in fact its use likely reduces software developer productivity over just writing the code.

This discussion of DSMs and DSMLs is very relevant to us at Skyway Software.  We have created a DSML for creating Rich Internet Applications and Web Services.  Our DSML - Skyway Visual Perspectives - is based in Eclipse and makes extensive use of the Eclipse Modeling Framework.  Skyway Visual Perspectives allows software developers to create RIAs and Web Services completely through modeling without writing a single line of code. 

Our customers have reported developer productivity gains of 5x and even 10x over traditional hand coding.  This is consistent with the findings reported in Steven Kelly’s book.   In addition,  software developers using Skyway can incorporate existing code, web services and data sources into their applications easily and seemlessly.    

DSMLs like Skyway will finally allow an order of magnitude increase in software developer productivity promised - but never delivered - by UML.

As with any software company, we innovate continuously. And as we prepare for our next major release, we also prepare launch plans. Seth Godin’s four charts reveal the likely outcomes of our (or anyone else’s) launch phase and acceptance phase, or simply put, the launch results. Results dont come easily and they are difficult to predict, even with sound planning and crisp execution. Why? Perhaps because we rely on customers to respond predictably. We want Chart A, yet we often get Chart B, or give up along Charts C or D, even though Chart C (and possibly Chart D) is quite desirable.

We know that markets and end users cant be (or shouldn’t be) controlled, but what if we could be more responsive? What if the software development was more controlled, perhaps even more responsive so that solution increments could be delivered quickly and accurately more often (ie, add additional dotted lines to each and any chart)? It can be.  Real working solutions, complete with data sources, business logic, and rich user-interfaces can be delivered with model-based tools and iterative delivery techniques.

Finally, business requirements match the software functionality actually delivered. Real business results are measured against design plans, budgets are verified, and schedules are realized. Expectations are met. And hope no longer needs to be a core business strategy.

Speak with you soon. DC

In a recent post on the Pragmatic Marketing blog, the Marketing-ProductDelivery coexistence question is partially answered. What’s the question?  It is: can Marketing and Product Development truly coexist?  The supplemental links from Tyner Blain and John Dodds also provide additional context to this very interesting question.  In my opinion, they must co-exist and they must be inextricably linked in order to be optimally effective–my deep-dive analysis of Marketing & Product Development will be fodder for a future post. 

For the purpose of this post, however, let’s acknowledge that a not-too-distant parallel exists elsewhere in the enterprise by comparing the relationship of the IT Department with End Users.  They must coexist to ensure each other’s survival.   We know that these groups don’t always align when it comes to delivering software on time, fully featured, and under budget, and it’s a problem that has remain largely unsolved.

And lately, I cant help but notice an obvious mismatched attempt at solving this problem by empowering the End Users with new tools to solve technology problems (can anyone say BPM?).  Isn’t the Business Unit too busy looking for revenue and market share?  Wouldnt it make more sense to define roles and implement management techniques (supplemented by tools and automation) to drive effective business results?  And perhaps allow IT to do, well, IT? 

But then again, I know a few product delivery guys who actually try to be marketers, too.

Speak with you soon.  DC

A very interesting SDTimes article (using SIIA data) appeared recently that highlights the value of developers, particularly when indexed against the rest of us.  It’s an important finding not only as an indicator of our overall quality of life, health of the union, and rank within the world, but also as a barometer for most of the software industry.  Developers are the lifeblood of the ISVs.  Marketers can’t raise awareness without products and can’t generate leads without solutions to customer pain points.  Sales can’t develop relationships without a product that completes the value-exchange equation. 

Enterprises buy software for many reasons, but it boils down to one core underpinning:  they desire innovations that deliver better experiences for their customers.  Enterprises want delighted customers.  When evaluating the full value-cost relationship, software applications deliver these customer delights more effectively than anything else available.  The best software innovations are the brainchilds of the best developers and good software ensures regulatory compliance, offers visibility, and even contributes to the forces behind Adam Smith’s invisible hand.

Where it will get particuarly interesting during the next 12 months is the battlefield of packaged applications vs. custom applications, large ISV vs. small ISV, proprietary vs. open source, modeling vs. coding, and Java vs. .Net.  But rest assured that the developers will be on the front lines and will be leading the charge to establish the next beach head.  The customers will be delighted.  Enterprises will benefit.  And so will the rest of us.

Speak with you soon. DC

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.