Sometimes snow can be very beautiful, especially when you are looking at it from inside a warm room…
To start with a very Happy New Year to everyone reading this blog!
I guess it’s not too late to join the plethora of pundits prognosticating plentifully about the ultimate and penultimate portends of 2005… So here are some predictions about some trends to watch.
First of all, I’d like to declare this the year of the service. This will be the year that people start to really appreciate the power of the service abstraction to enable “agile” business goals. These include the ability to provide rapid, low cost integration, multi-channel access, and quicker IT response to changing business and regulatory environments.
I was looking for an article by my friend, Don Box, that gives the best description of the service paradigm that I know of. I haven’t found it yet, but I did find this great interview with him from the .NET Developers’ Journal. Definitely worth a read if you haven’t seen it before. The story of how services originated is in there, somewhere near the middle…as a better way to pass messages across disparate runtimes than either the DCOM or Java approaches provided, achieving real platform independence. And it’s proving to be true. We will see the market go past the early adopter stage in 2005.
Innovation in software is likely to move up to the services layer. The lower layers – operating system, middleware, and programming language – already have sufficient features and functionality and we are likely to only see refinements rather than significant enhancements there. The lower layers are in fact already commoditizing, which will definitely continue during 2005.
The debate over UML/MDA will continue. I had posted something relevant to this last year, and as far as I know Stefan did not yet provide the example he promised. My assertion turns out to be only a small part of a much larger assertion, as Jack Greenfield describes so well, that just because UML was well suited for use in object oriented analysis and design, that doesn’t necessarily mean that it’s well suited for anything else. Jack’s assertion, which is very clearly and eloquently supported by Sergey Dmitriev’s fascinating article, is that UML is not well suited to creating models – at least not models with sufficient semantic content for use in generating code.
Consequently, I would like to predict that domain specific languages (DSL) will gain quite a lot of traction in 2005. The ideas just seem right, and I agree that UML has probably run its course. Sure, it’s great for whiteboarding, as many of the DSL bloggers have pointed out, and it did significantly advance the industry from the days in which we had half a dozen or more design notations to contend with, but that doesn’t necessarily mean it’s good for anything else.
I am very pleased to see all the attention being given to industrializing or automating software development. This is one of the biggest challenges for the software industry since it remains far too expensive to develop new software, and the quality is far too unreliable. It remains a craft industry – this was the strange part about Grady Booch’s blog entry, and Jack Greenfield commented on it too – comparing Microsoft’s current “software factory” initiative to the Japanese software factories of the early 1990s in a way that seemed to imply that software is by nature a craft industry and cannot be automated or subject to more scientific approaches. In other words, today’s programmers cannot be replaced by machines. But I think this is inevitable, as has happened in so many other industries, and I applaud Microsoft’s efforts. The world’s economy – now so totally dependent upon computers — simply cannot sustain the current inefficiencies and high costs. Outsourcing is not the real answer, although it may be a part of the solution. This is a fascinating trend to watch.
Another prediction is that the controversy over Java Business Integration will heat up a bit and we will find out whether or not this initiative will succeed. With BEA and IBM dropping out, and Apache and JBoss joining, an interesting dynamic is starting to emerge between the established Java vendors, the open source projects, and ESB companies like ourselves, Sonic, and WebMethods.
Will JBI become as widely adopted and as significant as EJB, as some promise? Without BEA and IBM on board that has be a big question mark, unless it goes the open source route, which opens up another whole can of worms… Since the initial specification, created by the JSR 208 committee, is due out by JavaOne, we should know the answer in 2005.
I also like to look for evidence of software industry changes. It looks like IT is moving away from developing new systems in favor of getting more out of existing systems (this is of course related to the services trend). If that’s the case it signals a change in the investment model for software vendors also, since those “get more” projects don’t justify as much expense as the “develop new” projects do.
With vendor margins under pressure that means R&D spend is under pressure – innovation seems likely to continue to move toward the Web services layer. I don’t completely agree with Tim O’Reilly’s Web 2.0 vision, but I do think that the application-as-a-platform trend at Amazon.com, Ebay.com, Salesforce.com and others is going to continue.
Tim has correctly pointed out that the public availability of services over the Internet represents the beginning of a major shift in how the industry will build software applications. During 2004 the ERP/CRM vendors all announced plans to service-enable their platforms, no doubt in response to Salesforce.com. Oracle recently confirmed (see the end of page 1) that service enabling remains a future strategic direction for the PeopleSoft/Oracle Financials combination. But in the end enterprise applications will have to combine home-grown and hosted services to achieve all goals of IT – it will be the combination of internally developed services with hosted services that will give us the future. I expect this to become clearer in 2005.
And finally, I predict that 2005 will be the year in which the WS-BPEL community begins to fragment, since vendors do not seem to be implementing the whole spec, only the parts they like, and implementations vary from those who feel BPEL is an executable language and those who feel it’s just a kind of interchange language (i.e. export/import).
Well, I guess that’s enough for a snowy January day… Take care and stay warm.