Embarcadero rescues CodeGear
In our
most recent report, our new analyst
Bola Rotibi looks at Embarcadero's recent acquisition of CodeGear (the Borland subsidiary that it's been trying to offload for many months) - and asks: has Embarcadero made a smart move or a stupid one, and what does it mean for organisations looking at investing in development tools?
You can
download the report if you have access to our guest pass research: if you're not a member, it's easy - you can
register for free.
Labels: borland, codegear, development, embarcadero, MWD
A week of firsts
You might think having been a senior analyst for 8 years that I'd have seen most things. Well, this has definitely been a week of firsts for me.
My first ever
JavaOne conference; my first week in joining MWD as a principal analyst covering the application delivery and lifecycle management market (moving from 8 years at Ovum) and finally my first blog entry.
I accepted Sun's invitation to JavaOne this year because rumour has it that interest in the conference and support for Java is waning, and I wanted to see for myself just what was going on.
To be honest, I've never given much credence to such hyperbolic scaremongering, and what I've seen over the last couple of days merely backed that up. There's no doubt that Java's progress has been and continues to be marked with difficulties: controlling interests and agendas, delays, confusion, swerving focus and industry bickering. However, this is to be expected of a technology that has been successful and widely adopted.
Java is a mature technology that has many masters, spawned a number of lucrative revenue streams, opens many doors and is consumed in many different ways. The competitive alternative ?
Microsoft's .NET environment, although just as formidable, is beset with similar issues and one or two harder challenges.
That's the good news. The bad news is that Sun's role and involvement from technology, market and management perspectives alike has been opaque at best.
Sun has never been particularly clear about how it actually makes money from Java or indeed maximising the opportunities. This doesn't really look like changing in the future.
For all that, I have enjoyed these past few days at the conference and gained a good deal of valuable insight; some disturbing, some surprising, others anticipated. Rumours of the conference's lack of importance and influence are, in my view, premature, and I will share my thoughts with you in future postings.
Far from what I was expecting, there has been a general air of optimism at the conference.
In ending this blog post I find myself with two regrets:
Firstly, the sheer number of interesting and enticing presentations made it inevitable that I should miss more than I could attend. Those that I did get to which I found particularly compelling, and would certainly recommend anyone getting the presentation materials or podcasts / webcasts of the sessions, were:
"Sun Mobility General Session ? Java wherever you are" (the information delivered was certainly interesting and a good insight into JavaFX mobile development - and it's clear that Sun is after the same market as
Microsoft and
Adobe in this space); and
"Real World, Real Time, Instant Results: Make Information work for you" presented by
Jeff Henry of IBM (very interesting, insightful and for the most part non-partisan). I was booked on, but missed,
"Service-oriented Architecture and Java Technology: Level-setting standards, Architecture and code" delivered by Steve Jones and Duane Nickull. By all accounts this had some good insight and valuable information from guys with a lot of end user and real world interactions. The other sessions I wanted to attend but they clashed were
"The many moons of Eclipse" and
"Case Studies from the JavaFX technology world".
My second regret is not having attended JavaOne during the past eight years as a senior analyst, if only to have seen it in its heyday when Java was the exciting new kid on the technology block and firms were rushing and fighting to be part of the show.
Given the size of the big hall and the number of organisations exhibiting I would definitely say that whilst veterans of the show might argue that the volumes are not up with its peak years (early 2000s) the show still maintains enough of an influence to entice the great and the good in this market and plenty of start-ups and innovators.
JavaOne, in my opinion, is still an incredibly important and very necessary conference. My worry is that it becomes increasingly a mouthpiece for Sun rather than a standalone entity.
Over the coming weeks and months, I am going to be writing a lot more about the state of the development market and taking a closer look at the value of some of the underlying technologies and products. I welcome any comments and questions and look forward to readers getting in touch to further the debate.
Labels: development, Java, JavaFX, JavaOne, mobility, Sun
The lore of averages
I was chatting to a friend who's a top-notch Java developer over the weekend: we were shooting the breeze about Groovy, Rails, Spring, Hibernate and various other Things That Get People Excited (let's call them TTGPEs), and discussing how far they were likely to penetrate into your average IT shop. "Why do so many people insist on following the J2EE application model and associated patterns so slavishly," said my friend, "when they're so plainly not the right tool for the job in so many scenarios?"
"The thing that you never get from reading development books," I said - he'd just finished showing me a book on Groovy - "is how difficult it can be for your average IT shop to get on board with a new development technology, when you take commercial considerations into account. You can see from looking at code samples that language A is more compact or give you more productivity than language B. But what you can't see is the bigger picture of costs and risks."
I remembered a post of Steve Jones' I'd seen a couple of months back about
development as a discipline for the masses - and also
this one from Jeff Schneider about the value of SOA governance.
You see, the problem for your average IT shop in taking on TTGPEs is that even when they have been demonstrated to save time and/or money, there are two real barriers to adoption. Both barriers exist primarily because these shops have no option but to see development resources as a commodity.
First, within an average IT shop - think of one within a small utility provider or a local government - the business can't make a case for paying top whack to hire the very best developers. So, they have to shoot for the "mass market" of developers - hopefully capable and dependable, but not likely to be stellar performers. They also don't have a lot of time or money available for recruiting, so they tend to minimise the complexity of interviewing as far as possible - asking for "industry standard", well-recognised skills. Unless they can find TTGPE skills within that "mass market", they're not going to consider bringing those skills into the organisation. J2EE skills are now mass-market skills. Groovy skills aren't (yet).
Second, within such an IT shop, work tends to follow those same "industry standards", because the risk of doing TTGPEs is that if people leave or get sick, and new people have to be brought in, they have to be able to get new resources up-and-running quickly. If new staff have to spend weeks or months trying to re-engineer glamorous but unknown technology before they can continue a project, that's a huge, ugly cost.
Regardless of whether J2EE is increasingly being revealed to be more like a VW crossed with a tractor than a Ferrari, then, the truth is that most people have little choice, for now, but to stick with it and make the best of things.
Labels: 4GL redux, development, governance, industry
New On The Radar report: Erudine
Those of you with an interest in model-driven development and legacy system renewal might want to take a look at
our latest On The Radar report, which focuses on Erudine.
Erudine is a 55-person company headquartered in the UK whose core technology uses case-based reasoning techniques to provide a highly abstract software development environment and associated runtime engine. It should be of interest to you if you are dependent on data- and rules-intensive legacy applications, such as billing and scheduling, where the resources (both technology and personnel) required for ongoing maintenance and development are scarce.
Labels: development, Erudine, legacy migration, MWD
The SOA tool pyramid
I've had a bit of a graphic spurt (as it were) and so here's another blog post based around a diagram.
I was talking to a journalist a couple of weeks back about the kinds of functionality that customers need to look for when looking for tooling for SOA initiatives, and which vendors provide which groups of functionality. It's not always easy to explain this kind of thing over the phone, so I thought I'd have a go at describing the main areas of functionality as a pyramid. Something like this:
In our assessments of SOA tool vendors' capabilities (see
here for an example) we highlight nine separate areas of functionality, but this is a simpler picture that just focuses on four:
- Service enablement - this is functionality that helps you take existing IT assets (applications, databases, etc) and create service interfaces based on the capabilities they offer. A lot of vendors provide facilities in this area because in truth most of them started out as integration tools vendors.
- Orchestration and composition - this is functionality that helps you aggregate services and create "composite services" or "processes". Most vendors offer some capability along these lines, and most involve the ill-named "BPEL" in some way (but that's another story). The reason is the same as the reason above: many of the SOA tooling vendors had "pre-SOA" offerings which allowed you to aggregate and orchestrate resources from existing applications and systems.
- Lifecycle management - this is all about supporting development, integration and operations teams in linking their efforts to ensure that the consumer service experience is high-quality and consistent under potentially unpredictable circumstances. Typically the foundation of this capability is some kind of registry/repository, but ideally tools go further than this - firstly by helping to automate team workflows for implementing quality controls at design time; and secondly by helping to translate design intentions relating to operational SLAs into runtime policies which are tied into the infrastructure. Some vendors are starting to offer capabilities in this area, through acquisition (HP/Mercury/Systinet, webMethods/Infravio, BEA/Flashline (kind of)); OEM/resale agreements (Oracle/Systinet, BEA/Systinet) or in-house development (IBM, Sun).
- Service development - this is about the ability to design services "from scratch", or to design services where any existing applications/systems offer functionality which only partially fulfils a requirement. Ideally this starts "contract first" - first of all documenting what the service needs to do and the commitments the provider should make to service consumers; and only then refining that spec into a working service implementation and interface.
Most SOA tools vendors suck at this last bit, frankly. I think that TIBCO is starting to do provide some interesting supporting facilities for this broad area with
ActiveMatrix, and as vendors start to implement
SCA/SDO in their tools the situation might get better across the board. In the meantime if you've heard of a vendor targeting SOA specifically that really provides solid tools to help with this kind of contract first" development approach, I'd love to know.
Labels: BPEL, contracts, development, SCA, SOA, tools
