Lustratus LiteBytes

Archive for October, 2007

Microsoft’s project Oslo is both interesting and ambitious as a concept and a project.

As a concept, Microsoft is recognising the need for formal modelling – in particular for SOA – and as a project Oslo promises to provide formal modelling capabilities across a range of Microsoft products over the next couple of years. Unfortunately, the announcement also seems to reflect Microsoft’s wish to live in a parallel universe of its own making.  This is unfortunate as such a parallel universe is fundamentally incompatible with SOA – which Oslo seeks to enable.

To focus for a moment on the positives: Oslo must be acknowledged as a major move from a vendor who up to now wouldn’t touch any sort of modelling with a 10 foot pole.  While I certainly don’t believe that model based approaches are perfect, standards such as UML when used appropriately and pragmatically can be very effective in the development process.  Given its previous position as sceptic, Microsoft is in a good position to deliver such a pragmatic and accessible solution and this appeared a first read to be its goal as quoted here:

In the past a very select group of users has used modeling. Microsoft is going to make modeling mainstream for the average developer.

said Martin. [Steven Martin, director of product management for Microsoft's Connected Systems Division]

To a great degree, Mr Martin is right:  Formal modelling tends to be used by only a minority and the learning curve and perception of complexity and cost put most off:  There is definitely an opportunity to make modelling more accessible to less technical and less modelling-aware developers.  However, rather than at least taking UML (the widely used and mature modelling standard) as its starting point, Microsoft has decided to go its own way and thus ignore much experience and knowledge of how to model systems built into this standard.

Furthermore while aiming to be more democratic in its approach, Microsoft also appears to wish to entwine the modelling activity into its own technology stack.  This will inevitably result in a Microsoft only model which in turn will allow its customers to build only Microsoft dominated (if not exclusive) versions of SOA.  Which will be great for that minority of Microsoft exclusive shops and of little use for the rest of the world.

As Oslo is still only at its earliest stage, perhaps Microsoft could reconsider its decision to ignore the standards and the heterogeneous world most of us live in …  please

Ronan

I was introduced today to yet another new term – “stratactical”, in a rather good ComputerWorld article.

The definition is given as follows:

Stratactical is the word the enterprise architects at San Mateo, Calif.-based Con-way Inc. created to describe their work. “We use it all the time,” says Maja Tibbling, lead enterprise architect at the freight transportation and logistics company. “Our team takes into account both the strategic and the tactical.

I confess I found the idea quite attractive – to reinforce the importance of building IT systems and related business and IT processes and procedures that take into account strategic goals while at the same time satisfying immediate needs. Indeed, I have long been an advocate of ‘incremental strategies’ where long-term vision and goals are set, and then day-to-day activities and tactical projects are put in place that at least do not exclude the longer term picture, and hopefully go another step in the desired direction.

However, I am not sure I can extend this to the idea of having individual architects who are charged with being ’stratactical’. This may sound like heresy, and I can imagine my good friends at IASA, the spiritual home of enterprise architects, having a fit over my assertion, but let me explain.

I absolutely think that architects can have the wherewithall to understand tactical and strategic issues. The question is whether it is practical to charge an architect with both duties. My own view is that the pressures brought to bear through tactical, often urgent, time-conscious, possibly localised projects is overpowering, and the danger is that no matter how well-meaning an architect might be, the need to design a solution fast is hard to withstand. Almost inevitably, short-term decisions will be taken that may actually go counter to the longer-term strategy.

Although confrontational, I prefer a split approach where there is a policing authority driven by architects charged with achieving the long-term benefits of the selected ‘grand design’ as well as other architects working to help tactical teams build solutions. Yes, it is irritating and time-consuming when the corporate architects raise an issue over some short-term solution, and indeed the agreed decision might be to ignore the long-term issues and go for the quick gain, but at least it will be a conscious decision achieved through some management-driven procedure. The alternative is to ask architects to make these sorts of calls in their own heads, with no ‘protection’ as can be afforded through the more formal approach – I think this is unfair on the poor architect.

So,my vote is for an architectural community that is ’stratactical’, but a separate, management-backed body of architects charged with keeping the vision alive to balance others who are trying to address the demands of the tactical project and its drivers.

Steve

I am often asked whether open source (OSS) SOA is a reality yet – whether it is ready for prime-time, as they say.

The answer, as is often the case, is ‘It depends’. There are many OSS projects in the marketplace around ESBs, Integration and SOA, but just having a project in place is a long way from having production-ready software. For a start, there are the questions of maintenance, support and even indemnification against possible future legal activities. The most useful projects are those that have an associated commercial company addressing these types of areas.

However, the other aspect to consider is that most opern source projects are started and driven by technically adept programmers, so they tend to be oriented towards programmer usage. In SOA, this may be acceptable, depending on requirements, but it may also be desirable to have a solution more oriented to business analysts. They key is to be clear on what you want, and on what is being offered.

For a longer discussion on this topic, Lustratus has just published a free assessment of one particular OSS integration vendor, MuleSource, and its open source offering Mule. This paper considers a number of these types of key questions over OSS SOA, but of course in the MuleSource context.

Steve

Ranadive, CEO of Tibco, has announced that Tibco board would of course consider offers.

And after the recent news about Business Objects and BEA, such offers may seen inevitable.  Jeff Schenider of MomentumSI for instance argues that we have entered a period of inevitable consolidation.  While I certainly think we are already in an era of big-4 and the rest, that does not necessarily mean that every ’small’ software company (and remember these are only small in comparison to the giants) must be bought.

The Reuter’s piece covering Ranadive’s statement comments that “Analysts have said suitors for Tibco could include IBM (NYSE: IBM), Hewlett-Packard (NYSE: HP), Sun Microsystems (NSDQ: JAVA), and EMC (NYSE: EMC).”

I personally wonder.  On the one hand you could ask why not?  Tibco has excellent top tier customers who use its long standing messaging products for core business processing.  It also has some of the best SOA products in its BusinessWorks portfolio – combining enterprise grade reliability with good tooling.  However, I think you need to look a little deeper about the two acquisitions which sparked this consolidation talk:

BusinessObjects is in what should to be the hot growth area over the coming years – business intelligence – and thus is perfect for the vendors who want to find a new thing to sell to their customer base or a new way to justify their existing product line (by adding a BI layer on top).  Business Objects should have been a target for IBM and Oracle as well as SAP.

BEA was generally believed to be a long term target for Oracle – BEA had after all used the application server wave to capture business from so many of Oracle’s enterprise customers.  Oracle first took quite a while to take application servers seriously and then took quite a while to become competitive.  Buying BEA finishes the job off quickly and gets back ownership of all those straying BEA customers.

With Tibco, there is no obvious buyer (as Oracle was with BEA) nor is there a neat fit into one of the majors (as BusinessObjects was with SAP).  Of the 4 listed by the “Analysts” quoted above, only IBM would make any sense.  And Oracle, except that it is busy trying to eat BEA.  Therefore, I don’t see Tibco being bought except unless it is Skyped (bought for over the odds to avoid somebody else buying it).

Ronan

This is one of the classics of Service Oriented Architecture discussions and has recently resurfaced.

Joe McKendrik over on his ZDnet blog rounds up some of the recent discussion. The heart of the issue is that SOA is not a product category because it is an architecture. Furthermore it is an architecture which requires significant focus around governance and organisation and therefore just selecting some products does not deliver SOA. Early on when SOA was close to synomious with Web Services, this was an important point to make: Just deploying a Web Services stack did not make what you did a SOA (giving rise to the delightful acronym JBOWS – Just a Bunch Of Web Services – to distinguish this approach from ‘true’ SOA).

However, from this entirely rational view grew the corollary that SOA can be implemented with anything. While theoretically this may be true, it can be taken to extremes: Clearly, the right product is bound to make it easier to implement SOA than the wrong product – even if you already own the wrong product. Also clear is the fact that you can buy important components of your SOA infrastructure from registries to management to ESBs. Furthermore, there is every reason to believe that software vendors will over time continue to move beyond ‘just’ providing infrastructure to providing larger chunks of SOA ‘out of the box’ – just as SAP et al do for ERP (as Jack van Hoof points out ).

Therefore today and in the future, SOA programmes must absolutely start at the architecture level and not simply select products. However, today and increasingly in the future it makes complete sense to use commercial (or Open source) software to ease the implementation:  SOA is othogonal to packaged software – not an alternative.

Ronan

Every now and then, we all hit that point when we want to stop everything and say enough is enough.

I guess I have just reached that point. I spend my time working with buyers, sellers and implementers of SOA, and just about every conversation is about applications. There is a myriad of tools and platforms that are focused on being able to turn existing code assets into SOA services, building composite service and constructing orchestrated flows…..but everything is discussed from the point of view of the application.

I guess what frustrates me is that when I talk to people about what they want their services to do, particularly when you get to composite services where functions are linked together, the answer is usually two-fold – I need to run the following applications or components, and I need to access the following data. When building an orchestration flow, for example, it is often very useful to be able to interrogate data to help determine the appropriate next step in the flow.

It seems to me that most SOA products don;t really consider this. At most, they allow database calls during flows, but this is hardly in the spirit of SOA. Surely, these calls should be allowed to any data source in the SOA network, whatever the data architecture or format. This would fit with the SOA theme about offering everything under a standard interface.

Come on guys – I know data might seem boring, but it is just as important as the applications themselves.

Steve

Guy Nirpaz commented on my post about Oracle’s potential BEA acquisition…

…stating that he believed that OSS should be on my list of the big 4 (IBM, Oracle, SAP and Microsoft) if you consider middleware in particular.  I would agree that middleware is certainly an area which OSS is playing an increasingly important role.

However, OSS does not necessarily represent the increase in choice you might expect as in many cases the big players either dominate or can dominate if they choose to (the investment in OSS by big players is excellently covered in a Harvard Business School working paper referred to here).  In those cases, there is a potential risk that the OSS becomes positioned as the entry level offering with the pay-per-license version containing the features required for serious use or used to reduce the level of choice available by putting pressure on smaller vendors.

For smaller backers of middleware OSS, historically it has proven difficult to create a sustainable and scalable business model.  However, I believe that is a market maturity issue rather than an underlying weakness in OSS approach.  Already, we are seeing the emergence of some interesting business strategies which seem capable of sustaining a growing business.  If one or more of these work out, then OSS enterprise middleware players may emerge (or existing vendors successfully transition to Open Source business) which will challenge the hegemony of the big 4.

Ronan

Oracle has finally done what so many rumours have pointed to for at least a few years:

made an offer to buy BEA.  I am sure that there will be much comment on the challenges of dealing with the total overlap between BEA’s core product – the WebLogic applications server – and Oracle’s application server (both in the top three by most measures of market size).  The move should also take the wind out of speculation that Oracle will make a spoiler bid for Business Objects.

The writing off of BEA as a business by some has been totally over-stated.  However, I think if this bid is successful it does marks the end of the J2EE era.  Not that I am suggesting that J2EE application servers are going to go away of course.  Rather, the world has moved on from what created that market in the late nineties.  At one end of the spectrum, the focus has moved back towards technology independent architectures with SOA (just as CORBA attempted to do in the pre-J2EE days – all be it by creating another set of technology).  At the other end, lighter weight approaches such as Spring have superceded the heavier and more complex EJB model (which to be fair has also moved with the times but probably too late).

It is also worth noting that the disappearance of the large enterprise focused ISVs continues – in one week we appear to be losing another two.  It is beginning to look like that the enterprise software market is heading for a strongly polarised world made up of a big-four (MS, Oracle, IBM and SAP) with a huge gap to the next division.

Ronan

Dan Foody of Actional gives an excellent real-world analogy for how not to apply SOA governance in his blog:

The government of his home province of Quebec kept upping the taxes on cigarettes (in order to discourage smoking of course) but eventually:

“Then a funny thing happened [when the taxes were increased yet again] … without warning, smokers started rebelling and they started buying cigarettes that had been smuggled over the border through indian reservations because they were much cheaper.

Within weeks it went from a few die hard smokers buying these smuggled cigarettes to double digit percentages of all smokers in the entire province doing it.  The taxes hit a flash point without warning,  and no amount of additional police work was getting the smuggling problem under control.”

The analogy that he draws is the following:  If your SOA governance policies are working, this does not mean that more policies and controls will make the situation better – it may cause a revolt among the developers.  I strongly agree:  SOA Governance must be as light as possible – which typically means that you should start too light and build up carefully rather than attempt to design a complete set of rules at the beginning and then prune back when the backlash occurs.

Furthermore, governance procedures must engage and involve the participants and not be simply handed down from central IT.  As Dan also points out, this means that governance should include carrots as well as sticks.  If this isn’t done and governance is exclusively a set of police enforced control mechanisms, at the first opportunity a project will be declared too important and urgent to follow ‘all those stupid policies’ and the whole of governance will fade away like so much smoke from a smuggled cigarette.

Ronan

The focus of debate on Open Source is too often focused on “its free” and sometimes overstated claims about software quality.

As everybody knows, the cost and risk associated with bringing anything into an enterprise go far beyond the license costs.  For OSS, a big problem is that by its nature it can bypass the controls imposed by procurement and the legal departments.  This can lead to a range of potential risks from IP infringement to plain old version control.  Of almost equal importance to the actual risk is the fact that the risk associated with OSS can be invisible  (as the OSS use will often not be tracked as licensed software would be) and therefore undermine the whole of IT risk management.

This article covers one approach to dealing with issue:  specialist software to analyse the Open Source software.  There are of course more straight forward alternatives:  Any vendor supplying OSS as part of a licensed product should be held to account to provide support and ‘handle’ the risk issues.  For ‘pure’ OSS, there are plenty of commercial organisations who will provide a degree of quality assurance and service guarantees around projects.  It may take away from the “Its free and I won’t need to talk to legal and prodcurement” but do we really want staff bringing software straight from the web into deployment?

Ronan